Google ADK Security: Agent Development Kit Guardrails, Tool Confirmation and the ADK 2.0 Upgrade
ADK 2.0 went GA for Python on May 19, 2026 and replaced the agent executor with a graph engine. Google documents that custom overrides of the old run methods are now silently ignored, and the human approval feature does not work on the two session services most production teams use.
Direct answer
Google Agent Development Kit is a well built open-source framework with a candid safety guide, and it is not insecure. It gives you the right primitives: before-tool callbacks that see "the requested tool and parameters", security plugins that apply "to every agent that uses the runner", a Gemini Flash Lite judge, a Model Armor plugin, sandboxed code execution and VPC Service Controls. Three documented facts matter to a security owner. Tool confirmation is opt-in per tool. Google lists DatabaseSessionService and VertexAiSessionService as "not supported by this feature". And after the ADK 2.0 upgrade, custom overrides such as _run_async_impl() are bypassed by the graph engine, so checks written there stop running without an error. Agentshield adds one policy point outside the application that keeps enforcing through all of that.
Try it live
Watch Agentshield block an attack in real time.
Pick a scenario and drive the inspection lane yourself. No signup needed.
Run a request
Runs the live engine on your text. Nothing is stored, no account needed.
Inspection lane
INSPECTINGPolicy trace
High-risk action held for approval
Audit trail
- § · → → →
The risk
A platform team built three ADK agents in 2025, put an authorization check inside a custom BaseAgent subclass, and passed a security review. In June they bump google-adk to 2.0 because the Workflow Runtime is what they were waiting for. The tests pass, because the tests check that the agent answers. Nobody notices that the check inside _run_async_impl() no longer runs, because Google designed the new engine to bypass that override, and a bypassed method does not throw. Separately, the refund tool that was supposed to ask a human first has quietly never asked in production, because production sessions live in VertexAiSessionService and tool confirmation does not support it.
How Agentshield handles it
Keep the ADK controls. Google is right that the first line of defense is a tool that exposes only the action you want, validated against context the model cannot change, and nothing here replaces a well written callback. What Agentshield adds is the layer that does not live inside your agent code: route tool and model traffic from your ADK services on Agent Runtime, Cloud Run or GKE through one policy point, declare per-agent tool and data scopes once, and the same policy holds across Python, TypeScript, Go and Java agents and across the 1.x to 2.0 upgrade. High-risk actions pause for a named approver with an expiry that does not depend on which session service you picked, untrusted tool output is inspected before the next step acts on it, and every allowed and denied action lands in an immutable audit trail tied to the agent identity.
The controls
The controls that secure every tool call your Google ADK agents make, before and after the ADK 2.0 upgrade.
What changed in ADK 2.0, and which security code it silently skips
ADK 2.0 is the biggest change to Google's agent framework since launch. The old hierarchical agent executor is gone and a graph-based Workflow Runtime takes its place, with agents, tools and functions evaluated as nodes that support routing, fan-out, loops, retry, nested workflows and human-in-the-loop pauses. For most teams that is a real improvement. For a security owner it is a migration, and migrations are where controls go missing.
| Language | ADK 2.0 status | Breaking change that matters |
|---|---|---|
| Python | GA on May 19, 2026 | Custom overrides of 1.x abstract methods such as _run_async_impl() or generate_content() are bypassed by the graph engine. Events need new node_info and output fields |
| Go | GA on June 30, 2026 | The module path moves from google.golang.org/adk to google.golang.org/adk/v2, and session.NewEvent now takes a context.Context first |
| TypeScript | GA on August 21, 2026 | InvocationContext.agent becomes optional, four new Event fields appear, and SequentialAgent, ParallelAgent and LoopAgent now log deprecation warnings |
| Java and Kotlin | Supported, Kotlin newer | Check the release notes for your version before assuming parity with Python |
The sentence in Google's migration notes that deserves a security review is this one: "The Workflow Graph engine completely bypasses these legacy overrides." Google goes on to say that when developers inject custom telemetry or state management through method overrides, "those calls are silently ignored" in ADK 2.0. The recommended replacement is the BeforeAgentCallback and AfterAgentCallback interfaces.
Telemetry and state management are the examples Google gives, but in practice plenty of 1.x teams put authorization there too, because a custom BaseAgent subclass was the obvious place to say "this agent may only act for users in this tenant". If that check lived in an override, it does not run after the upgrade, and nothing fails loudly. Grep your codebase for _run_async_impl and generate_content before you bump the version, and treat every hit as a control to re-home, not a line to delete.
There is a second, subtler trap in the same notes. Google warns that "Catching BaseException inadvertently traps NodeInterruptedError, which breaks the framework's ability to pause the workflow for Human-in-the-Loop (HITL) input." A broad exception handler that someone added years ago for resilience can quietly disable the approval pause you are relying on. The rule Google gives is short: never catch BaseException unless you re-raise it.
We have now seen this pattern three times this year. Microsoft's Agent Framework migration dropped the attribute that used to mark which methods a model could call, and the OpenAI Agent Builder shutdown turned guardrail nodes into hand-written code. Each time the framework change is reasonable and each time the security control is what falls through the gap.
Is Google ADK secure? What it enforces and what it leaves to you
Yes, and the ADK safety guide is one of the better documents in this category, because it lists the risks plainly: ambiguous agent instructions, prompt injection and jailbreak attempts, indirect prompt injections via tool use, misalignment and goal corruption, unsafe actions, leaking PII and data exfiltration. The useful question is not whether controls exist. It is who writes each one, how far it reaches, and whether it survives the next upgrade.
| Control | What ADK gives you | The documented limit | Who writes it |
|---|---|---|---|
| Before-tool callback | "The Before Tool Callback function can be used to add pre-validation of calls." It sees the agent state, the requested tool and the parameters | It runs inside your process and covers the agents you attach it to. A service that forgets to register it is unprotected | Your developer, per agent |
| Security plugins | "A security plugin can be configured once and applied to every agent that uses the runner." Google ships a Gemini-as-a-judge plugin and a Model Armor plugin as samples | Scope is one runner. Several services mean several runners, each configured separately | Your platform team |
| Tool confirmation | Set require_confirmation on a tool, or call ToolContext.request_confirmation with a hint and a payload, from Python 1.14.0 | Off unless you opt in per tool. Google lists DatabaseSessionService and VertexAiSessionService as "not supported by this feature" | Your developer, per tool |
| Agent-auth and user-auth | Tools act either as the agent's own identity, "e.g., a service account", or as the controlling user | Choosing the mode is on you. A shared service account across agents makes per-agent revocation impossible | Your developer and IAM owner |
| Sandboxed code execution | Google says "Sandboxing must be used to prevent model-generated code to compromise the local environment" and recommends hermetic environments with no network | Covers generated code, not ordinary tool calls that write to a database or send an email | Your platform team |
| VPC-SC perimeters | API calls stay inside the perimeter, "reducing the chance of data exfiltration" | Google's own words: "Identity and perimeters only provide coarse controls around agent actions" | Your cloud security team |
Read the last row twice. It is the most honest sentence in the guide and it is the reason the rest of the list exists. A perimeter decides where traffic can go. It does not decide whether this refund, for this customer, for this amount, should happen right now. That decision has to be made at the moment of the tool call, which is exactly what per-agent tool permissions are for.
Google's zero-trust reference architecture, published on the Google Developers Blog on August 17, 2026, pushes in the same direction: sign every database mutation with a hardware-backed per-agent key, run generated code in a gVisor sandbox "with zero network egress", and proxy model inputs and outputs "through deterministic validation rules". It is a good design. It is also a reference implementation on GitHub, which means your team builds and operates it.
The tool confirmation gap in production session services
This is the finding we would put in front of any team running ADK agents that can spend money or change records. ADK's tool confirmation is the framework's human-in-the-loop primitive. Mark a tool with require_confirmation and the agent pauses, asks, and only proceeds on a yes. It works well in development.
The confirmation documentation carries a "Known limitations" section with two lines: "DatabaseSessionService is not supported by this feature" and "VertexAiSessionService is not supported by this feature." Those are the two session services a team reaches for when sessions have to survive a restart or run on Google's managed Agent Runtime. InMemorySessionService, the one that does work, loses everything when the process stops, which is fine on a laptop and not a plan for production.
| Where your sessions live | Tool confirmation | What that means in practice |
|---|---|---|
| InMemorySessionService | Supported | Works in local dev and tests. Sessions and pending approvals vanish on restart |
| DatabaseSessionService | Listed as not supported | The durable self-hosted option. Approval has to be built another way |
| VertexAiSessionService | Listed as not supported | The managed option on Google Cloud. Approval has to be built another way |
None of this is a bug report. Google documents the limitation openly, and the ADK 2.0 Workflow Runtime adds its own human-in-the-loop pauses that some teams will use instead. The risk is organizational: a design review signs off on "refunds need human confirmation", a developer sets the flag, it works in the demo, and production runs on a session service where that path is unsupported. Check which session service each agent uses, and if it is one of the two above, confirm how approvals are actually enforced before the next audit asks.
An approval that has to reach a named person, persist through a restart, expire if nobody answers, and leave a record of who said yes is a control plane feature, not a flag. That is what approval gates for AI agents means in practice, and it is independent of which session backend you chose.
When Google ADK controls are enough, and when to add a control plane
Most ADK deployments do not need a separate security product, and we would rather say so than sell you one. If you are running on the Gemini Enterprise Agent Platform, Model Armor and Agent Identity already cover a lot, and a single well written plugin covers the rest for a single runner.
| Your situation | What we would tell you to do |
|---|---|
| One ADK agent, one team, tools that only read | Buy nothing. A before-tool callback and the Model Armor plugin are enough |
| Still on ADK 1.x with checks in _run_async_impl overrides | Buy nothing yet. Move those checks into BeforeAgentCallback before you upgrade, then upgrade |
| All agents on Gemini Enterprise Agent Platform, one Google Cloud project, one security team | Start with Model Armor, Agent Identity and IAM access policies. That may be the whole answer |
| Engineering-led team that wants to own its policy engine | Look at Google's zero-trust reference design or Microsoft's MIT licensed Agent Governance Toolkit, which also integrates with Google ADK |
| Internal agents, low risk, nobody asking for evidence | Buy nothing. Revisit when an agent first touches customer data or money |
| A write tool needs human approval and sessions live in VertexAiSessionService or DatabaseSessionService | This is the case we are built for. Approval enforced outside the session service, with a named approver and an expiry |
| ADK agents in several languages plus agents on other frameworks, one policy expected to cover all of them | Talk to us. One policy point outside the application, applied without redeploying each agent |
| An auditor will ask what each agent was allowed to do, not only what it did | Talk to us. Traces answer the second question well and the first one not at all |
Five of those eight rows tell you to buy nothing from us. That is the only honest way to write a page like this. If you run several agents that hand work to each other, the extra risks of multi-agent systems apply on top of everything above, and giving each agent its own identity, separate from the humans who deploy it, is the prerequisite for any of these controls to mean something.
FAQ
Common questions about google adk security.
Is Google ADK secure?
Yes, it is a well designed open-source framework with a candid safety guide. It provides before-tool callbacks, security plugins, a Gemini judge plugin, a Model Armor plugin, sandboxed code execution and VPC Service Controls. Security is shared: ADK supplies the hooks, and your team decides which agents use them, which tools need confirmation, and how approvals and audit records survive in production.
Does Google ADK have guardrails?
Yes. ADK guardrails are built from callbacks and plugins. A before-tool callback can validate the requested tool and parameters, and a security plugin applies to every agent that uses the same runner. Google publishes sample plugins that use Gemini Flash Lite as a judge and that call the Model Armor API to screen prompts, tool input and output, and responses.
Does Google ADK support human in the loop?
Yes, through tool confirmation. Set require_confirmation on a tool or call ToolContext.request_confirmation, available from Python ADK 1.14.0. It is opt-in per tool, and the documentation lists DatabaseSessionService and VertexAiSessionService as not supported by this feature. ADK 2.0 also adds human-in-the-loop pauses inside the graph-based Workflow Runtime.
What changed in ADK 2.0?
ADK 2.0 replaced the hierarchical agent executor with a graph-based Workflow Runtime supporting routing, fan-out, loops, retry, nested workflows and human-in-the-loop pauses. Python went GA on May 19, 2026, Go on June 30 and TypeScript on August 21. Custom overrides of 1.x methods such as _run_async_impl() are bypassed, and Google recommends BeforeAgentCallback and AfterAgentCallback instead.
Will my ADK 1.x security checks still run after upgrading to ADK 2.0?
Not if they live in overrides of 1.x abstract methods such as _run_async_impl() or generate_content(). Google states that the Workflow Graph engine completely bypasses these legacy overrides and that such calls are silently ignored. Move any authorization or validation logic into BeforeAgentCallback or a plugin before upgrading, and test that it actually fires.
What is the difference between agent-auth and user-auth in ADK?
With agent-auth, a tool reaches external systems using the agent's own identity, such as a service account. With user-auth, the tool acts as the controlling user. Agent-auth is simpler to operate, and user-auth limits the agent to what that person could already do. Either way, avoid one shared service account across agents, because it makes per-agent revocation impossible.
Does Model Armor protect Google ADK agents?
It screens content. Google provides a sample ADK plugin that queries the Model Armor API to check prompts and responses for safety violations, and Model Armor is a configuration option on Agent Platform gateways. It inspects text for injection, jailbreaks and sensitive data. It does not decide whether a particular tool call, such as a refund or a delete, should be allowed.
Where can Google ADK agents be deployed?
Google documents three targets: Agent Runtime, the managed runtime on the Gemini Enterprise Agent Platform, plus Cloud Run and Google Kubernetes Engine. ADK itself is open source and also runs anywhere Python, TypeScript, Go, Java or Kotlin runs. The security controls available differ by target, so check which ones apply where each agent actually runs.
Do I need an AI agent security product with Google ADK?
Not for a single agent owned by one team. A before-tool callback, the Model Armor plugin and confirmation on write tools cover that. You need a separate control point when one policy must span several agents or frameworks, when approvals must work on a durable session service, or when an auditor asks what each agent was permitted to do.
More use cases