Hands-On with the Agent Development Kit (ADK): A Security Triage PoC

TLDR
This article covers a hands-on exploration of the Agent Development Kit (ADK). An open-source AI agent framework integrated with Gemini and Google.
- Created a Proof-of-Concept (PoC) for security alert triage using ADK.
- Tested ADK’s multi-agent delegation with a coordinator and specialist agents (IP/domain lookups).
- Focused on framework capabilities, not application security for this initial test.
- ADK promising for structured, multi-agent workflows.
Google’s been steadily shipping some impressive models lately, and when they open-sourced their Agent Development Kit (ADK) at Cloud NEXT 2025, I figured it was worth diving in, especially for something relevant to security operations.
Agent Frameworks
There’s growing momentum around agent frameworks like LangGraph, CrewAI, AutoGen, and Mastra, each bringing different strengths to multi-agent design and orchestration. I wanted to see how Google’s approach compares in practice.
My goal was to build a basic Proof-of-Concept (PoC): could I use ADK to simulate the automation of initial lookup of IP addresses and domains found in typical security alerts? A simple task, but one that would help me understand the framework’s capabilities and limitations.
First, What is ADK?
From the documentation, ADK is pitched as an open-source Python framework from Google aimed at simplifying the development of agents and multi-agent systems. It’s designed for flexibility, working closely with Gemini models but also supporting others through LiteLLM, and includes features for tool use, evaluation, and deployment.
My ADK Experiment: A Basic Triage Agent Team
I decided to try the multi-agent approach ADK encourages. Instead of one agent doing everything, I set up a small team:
- The Coordinator (
triage_coordinator_agent
): This agent received the incoming alert text (e.g., “Alert: Suspicious connection from 8.8.8.8”). Its main job was to figure out if it contained an IP or a domain. - The IP Specialist (
ip_intel_agent
): A sub-agent designed only to handle IP lookups. I gave it a mock Python function (lookup_ip_reputation
) as its tool. - The Domain Specialist (
domain_intel_agent
): Similar to the IP agent, but focused only on domains, using a mocklookup_domain_reputation
tool.
How it Works: Simple Delegation
The core mechanism I tested was delegation. I configured the Coordinator agent with instructions like, “If you see an IP, delegate to ip_intel_agent
. If it’s a domain, delegate to domain_intel_agent
…”
triage_coordinator_agent = Agent(
name="triage_coordinator_agent",
model=DEFAULT_AGENT_MODEL,
description="Coordinator delegating IP/domain lookups.",
instruction="""
Analyze the input and take the following action:
- If it contains an IP address, delegate to 'ip_intel_agent'.
- If it contains a domain name, delegate to 'domain_intel_agent'.
- If neither is present, respond by stating that only IP/domain lookups are handled.
"""
tools=[], # Coordinator only delegates
sub_agents=[ip_intel_agent, domain_intel_agent], # Link sub-agents
)
When the Coordinator receives a query containing “8.8.8.8”, its underlying LLM interprets the instruction and sees that the ip_intel_agent
’s description (“Handles IP address reputation lookups…”) is the best match.
# --- IP Intel Sub-Agent ---
ip_intel_agent = Agent(
model=DEFAULT_AGENT_MODEL,
name="ip_intel_agent",
instruction="Use 'lookup_ip_reputation' tool for IP addresses. Report findings directly.",
description="Handles IP address reputation lookups using 'lookup_ip_reputation'.", # Crucial for delegation
tools=[lookup_ip_reputation],
)
ADK then handles routing the task to the IP specialist, which runs its mock tool and returns the result.
def lookup_ip_reputation(ip_address: str) -> dict:
"""Retrieves *mock* reputation information for a given IP address."""
print(
f"--- Tool: lookup_ip_reputation called for IP: {ip_address} ---"
) # For visibility in logs
mock_db = {
"8.8.8.8": {
"status": "clean",
"details": "Google DNS Server",
"source": "MockDB",
},
# Other entries omitted for brevity
}
The process works the same way for domains. If the query was generic, the Coordinator handled it directly based on its instructions. I used Gemini 2.0 Flash and have also tested with the open source (local) Gemma3 via Ollama with ollama pull gemma3
Running the Tests
I used the adk web
command provided with the toolkit to spin up a local test UI. The GUI is great for visualising the agent flow and looks good for troubleshooting purposes.
Queries containing IPs correctly invoked the IP tool (via the IP agent), and domain queries invoked the domain tool (via the domain agent), showing the delegation worked as planned.
Let’s test a couple of IP addresses.
- This first test returned “IP address 8.8.8.8 is a Google DNS Server and has a clean reputation according to MockDB.”
- This next test returned “IP address 45.33.32.156 is associated with scanning activity (scan.nmap.org) and has a malicious status according to MockDB.”
First Impressions
First impressions are solid. ADK makes it pretty easy to set up structured, multi-agent workflows. Defining agents and tools in Python felt intuitive, and the adk web
command was a handy way to test things locally.
Naturally, this PoC is very basic and I have no plans on expanding on this particular idea but it served a purpose in showing how ADK works and what it can do.
Next Steps, Evaluation Framework
ADK offers an evaluation framework designed for systematically testing agents against predefined datasets and scenarios. It looks like these evaluations can be run programmatically using AgentEvaluator.evaluate()
(useful for CI/CD), via the adk eval
command-line tool, or even through the web UI. I plan to look into this further in a future blog post.
Conclusion
This was a quick look at Google’s ADK through the lens of a simple security automation task. The framework shows a lot of promise for building agentic systems, and with Google’s generative AI models already proving their strength, I’m keen to see how ADK evolves and what developers will build with it.
With the recent introduction of the Agent2Agent (A2A) protocol, Google is also laying the groundwork for a more connected agent ecosystem, enabling agents to collaborate more effectively across platforms.