Google ADK Security: A Production Guide

Last updated: November 6, 2026

How do you secure agents built with Google ADK in production? Patch the framework first, then switch on the controls it gives you. NVD recorded six Google ADK vulnerabilities in 2026, the latest on October 28, and ADK Python is now at version 2.13.0. Upgrade to 2.7.0 or later, then add tool filters, approval gates and scoped identities.

TL;DR: Key Takeaways

• NVD published 6 ADK vulnerabilities between April 13 and October 28, 2026, with CVSS 4.0 scores from 5.3 to 10.0 (NVD, 2026).
• The worst, CVE-2026-79696, scored 10.0 and let an unauthenticated attacker run code through adk web in versions 2.0.0 to 2.6.0 (NVD, 2026).
• ADK Python 2.7.0, released August 13, 2026, fixes 5 of the 6 CVEs, and the Java one needs 1.13.0 (PyPI, 2026).
• ADK groups its defenses into 5 layers: identity, guardrails, sandboxed code, evaluation and tracing, and network controls (Google ADK documentation, 2026).
• Tool confirmation adds human approval, yet 1 CVE let attackers forge those approvals before ADK Python 2.5.0 (NVD, 2026).
• OWASP ranks Excessive Agency third in its 2026 LLM list, up from sixth, because tool access turns bad output into action (our OWASP LLM Top 10 2026 guide).

At a glance: the security layers in one table

Quick Answer

Is google adk secure enough for production?

ADK can run in production, but security depends on your patch level and your configuration. The framework gives you building blocks: agent or user auth, callbacks, plugins, tool confirmation, sandboxed code execution and MCP tool filters. You still need to patch, keep development servers away from shared networks, scope permissions and add runtime controls around tools and data.

How we compared

On November 6, 2026, we read the NVD records for six ADK CVEs, the PyPI release history for google-adk, and the ADK documentation on safety, tool confirmation, MCP tools and ADK 2.0. We also read the MCP Security Best Practices dated 2026-07-28, the A2A specification and OWASP's 2026 lists. We did not test ADK ourselves.

What is Google ADK and where does the risk sit?

Google ADK is an open-source framework for building, debugging and deploying AI agents. According to Google ADK documentation (2026), it supports Python, TypeScript, Go, Java and Kotlin and works with Gemini and many other models. The risk sits wherever an agent reads untrusted text or calls a tool.

ADK 2.0 reached general availability for Python on May 19, 2026, for Go on June 30 and for TypeScript on August 21. It adds graph-based workflows, where agents, tools and functions run as nodes in a graph. That helps security, because you can fix parts of the path in code. It also adds more nodes, tools and state to protect.

The documentation is candid about the threat model. It lists vague instructions, model hallucination, jailbreaks and prompt injections from adversarial users as sources of risk. It also names indirect prompt injection through tool use. Our indirect prompt injection guide explains why that last path is the hardest to close.

ADK groups the resulting risks into misalignment and goal corruption, harmful content generation, and unsafe actions. Unsafe actions include commands that damage systems, unauthorized purchases, leaks of personal data and data exfiltration.

The 2026 ADK CVEs: what to patch first

Six ADK vulnerabilities reached NVD in 2026, from April 13 to October 28, and five are rated high or critical. Three of the Python flaws need no authentication. Upgrade ADK Python to 2.7.0 or later and ADK Java to 1.13.0 or later, then redeploy every affected local and production instance.

The two newest records are from late October. According to NVD (2026), CVE-2026-115522 exists because FileArtifactService accepted an app name but left it out of the on-disk path. Two applications that shared a root directory and a user ID could therefore touch each other's artifacts. Version 2.6.0 fixed writes but kept a legacy fallback for reads and deletes.

CVE-2026-107858, published on October 23, hits the Java development server. NVD (2026) states that the /run_live WebSocket accepted any origin by default and that the REST API returned a wildcard CORS header. A page the developer visited could therefore drive the local agent. CISA's SSVC data in NVD rates exploitation as proof of concept for both October records.

CVE-2026-79696 is the most severe. It needed pytest installed next to adk web, which is common on developer machines, and a crafted test session replay was enough to run code without credentials. CVE-2026-4810 and CVE-2026-79707 are older unauthenticated flaws in the server and the builder endpoint. NVD says the first also needed a redeploy of production, not only a local upgrade.

CVE-2026-18236 attacks a safety feature. NVD (2026) found that ADK did not check whether the confirmed tool belonged to the executing agent or whether it needed confirmation at all. It also did not match confirmation arguments against the original call. An attacker who could inject session events could forge an approval.

Three lessons follow. Development surfaces such as adk web, the builder and ADK Web for Java were reachable without authentication. Binding to localhost is not enough, because CVE-2026-107858 works through the developer's own browser. And a single upgrade to ADK Python 2.7.0 or later closes five of the six records.

Guardrails: callbacks, plugins and in-tool policy

ADK offers three places to enforce rules on model and tool calls: in the tool, in a callback or in a plugin. ADK documentation (2026) states that callbacks suit agent-specific checks and plugins suit policies shared across agents. In-tool guardrails are the most deterministic, because the model cannot change them.

In-tool guardrails. A tool receives two inputs: arguments set by the model and a tool context set by the developer. ADK's example is a query tool that reads a policy from that context. The policy allows SELECT statements only, on a fixed list of tables. Whatever the model writes, the tool refuses anything else.

Before-tool callbacks. When you cannot change the tool, a before_tool_callback can validate the call. It sees the agent's state, the requested tool and its arguments. ADK's sample blocks a call when the user ID in the arguments does not match the session user. The docs warn that it fails when the needed facts are not in the parameters.

Plugins. ADK recommends plugins for policies that apply to every agent. You register a plugin once at the runner level, and it covers every agent that uses that runner. The documentation describes three examples.

That last row deserves attention. ADK's docs say Gemini's configurable content filters cover four harm categories and are off by default. Non-configurable filters still block some content, such as child sexual abuse material and personal data. If your agent faces the public, set those thresholds on purpose.

A judge model also needs care. A second model that screens inputs can itself be targeted by prompt injection. Treat it as one layer, and keep deterministic checks for actions that move money, data or code. Our comparison of AI gateways and guardrails covers where each control fits.

Tool confirmation and human approval

Tool confirmation lets an ADK tool pause and wait for a person or a supervising system before it runs. According to the ADK documentation (2026), you can ask for a simple yes or no, or for structured data. It is the built-in way to add human approval to risky actions such as payments.

Boolean confirmation. In Python, Go and Java, you wrap a tool with FunctionTool and set require_confirmation. In Kotlin, you set a flag on the tool annotation. TypeScript needs the logic inside the tool's execute function. You can also pass a function, so only amounts above a threshold need approval.

Advanced confirmation. The tool calls request_confirmation with a hint and a payload. The hint explains the request, and the payload defines the expected answer. ADK's example lets a manager approve fewer days off than an employee asked for. Execution pauses until the answer arrives.

Remote confirmation. Without a user interface, a confirmation can arrive through the ADK API server. The caller sends a function response named adk_request_confirmation with a matching ID. That makes the approval channel part of your attack surface.

Three caveats matter in production. The ADK docs label tool confirmation experimental, and they state that DatabaseSessionService and VertexAiSessionService do not support it. Check your session service before you rely on confirmation as a control.

The second caveat is CVE-2026-18236. Before the fix, a forged confirmation in session history could approve a tool the agent did not own. Patch first, then keep sensitive approvals outside the agent's own session where you can. Our guide to excessive agency explains why approval alone is not enough.

The third comes from the ADK 2.0 migration notes. A broad except block inside a tool hides failures from the framework, and catching BaseException traps the interrupt that pauses a workflow for human input. Let exceptions propagate, so approval pauses keep working.

Securing MCP toolsets and A2A agents in Google ADK

MCP and A2A connect an ADK agent to code and agents you did not write, which makes them the widest trust boundary. In ADK, McpToolset connects to MCP servers over stdio, server-sent events or streamable HTTP. A2A lets ADK agents call, or be called by, agents built with other frameworks.

Filter MCP tools. ADK's MCP troubleshooting checklist says to always supply tool_filter in McpToolset. The filter lists the only tools the model can see. A filesystem server might expose many tools, but a reader agent only needs list_directory and read_file.

Set timeouts and handle credentials. The same checklist recommends an explicit timeout on stdio connections, such as five seconds, to stop hanging subprocesses. For remote servers, McpToolset takes an auth_scheme and an auth_credential. Keep those credentials in a secret store, not in agent code.

Follow the MCP rules. According to MCP Security Best Practices (2026-07-28), confused deputy attacks, token passthrough and local server compromise are key risks. The guidance states that MCP servers must not accept tokens that were not explicitly issued for them. It also warns that insecure local servers can be reached through DNS rebinding. Our MCP prompt injection guide shows how tool descriptions and results carry hidden instructions.

Treat A2A agents as untrusted. According to the A2A Protocol Specification (1.0.0), agents publish an Agent Card that describes their skills and authentication requirements. A card tells you how to connect, not whether to trust the answer. Validate what a remote agent returns, as you would any tool output.

Multi-agent setups bring their own failure modes. Agents can hand tasks back and forth until budgets run out. Our post on the A2A loop covers how to cap those exchanges.

Identity, sandboxing and network controls

The last line of defense in ADK is what the agent can reach, not what it decides. ADK's documentation describes agent identity, sandboxed code execution and network perimeters as coarse but deterministic limits. They work no matter what the model outputs, which makes them the base layer for every production agent.

Agent-auth or user auth. With agent-auth, a tool acts as the agent's service account. ADK's docs note that this suits agents where all users share the same access. With user auth, the tool uses the user's OAuth token, so the agent can only do what that user could. The docs warn that OAuth scopes are often broader than the agent needs.

Sandboxed code execution. ADK treats code execution as a special tool with extra risk. You can use server-side sandboxed execution or a code interpreter extension. If you build your own, the docs recommend hermetic environments, with no network connections and a full data cleanup between runs.

Network perimeters. Running an agent inside a VPC Service Controls perimeter keeps API calls on resources inside that perimeter. ADK's docs call identity and perimeters coarse controls. Tool guardrails fill the gaps.

Escape output in your UI. ADK warns that model output shown in a browser must be escaped. Otherwise, an indirect prompt injection could plant an image tag that sends session content to another site.

Security and governance: framework controls need a runtime layer

ADK's controls live inside each agent's code, so coverage depends on every team getting every setting right. A missed tool filter, an unpatched adk web or an unchecked approval channel is enough. Governance means checking those settings across all agents and adding controls that do not depend on any single codebase.

OWASP's 2026 lists give a way to audit that. According to OWASP (2026), Excessive Agency is now LLM03, because tool-using agents run commands and call APIs unchecked. The OWASP Top 10 for Agentic Applications 2026 adds ASI02 for tool misuse and ASI03 for identity and privilege abuse. The table maps ADK controls to those entries, as our reading and not OWASP's own mapping.

A security team still needs proof that every agent uses these controls. That is why many teams add a gateway between agents and the tools and models they call. A gateway sees traffic from every framework, so one ADK agent with a weak callback does not become the only line of defense. Our guide to the agentic AI security control plane explains the pattern.

NeuralTrust treats agent security as a runtime problem across frameworks. Its Agent Gateway (TrustGate) is one gateway for models, MCP servers and A2A agents, with per-user tool access and an audit record of every call. It offers 200+ pre-built MCP servers and deploys as SaaS, hybrid cloud or on-premises. It is part of the Runtime Security Mesh, alongside Agent Runtime Security (TrustGuard), Agent Posture Management (TrustLens) and AI Red Teaming (TrustTest).

Which should you choose?

Start with the control that closes your largest exposure today. If you run an ADK version from before the 2026 fixes, patching comes first. After that, pick controls by what your agents touch. Data access calls for identity and filters, while payments and writes call for approval.

Conclusion

Google ADK gives you real security building blocks, but none of them protect an agent by default. Upgrade ADK Python to 2.7.0 or later, move ADK Java to 1.13.0 and keep development servers off shared networks. Then add in-tool policy, callbacks or plugins and tool filters on every MCP toolset. Use tool confirmation for risky actions, scope identities tightly and sandbox generated code. Finally, verify these settings across every google adk agent.

Secure Google ADK Agents in Production with NeuralTrust

Put an Agent Gateway in front of every model, MCP server and A2A agent your ADK agents use, and keep a record of every call.

Related Comparisons

• OWASP Top 10 for LLM applications 2026
• Best MCP gateways
• The agentic AI security control plane
• NeuralTrust vs Google

FAQs about Google ADK

1. Is Google ADK open source?

Yes. The ADK documentation describes it as an open-source agent development framework. It is available in Python, TypeScript, Go, Java and Kotlin, and installs in Python with pip install google-adk. You can run it on your own infrastructure or deploy it to Google Cloud services such as Cloud Run and GKE.

2. Is Google ADK production ready?

Google positions ADK for production agents, and ADK 2.0 reached general availability for Python on May 19, 2026. Production readiness for your use case depends on configuration. You need a patched version, authenticated endpoints, scoped identities and guardrails on sensitive tools. Some features, such as tool confirmation, are still labelled experimental in the documentation.

3. Which ADK vulnerabilities should I patch first?

Start with CVE-2026-79696, which scored 10.0 and allowed unauthenticated code execution through adk web in versions 2.0.0 to 2.6.0. Then check CVE-2026-4810, CVE-2026-79707, CVE-2026-18236 and the two October records. Upgrading ADK Python to 2.7.0 or later closes five of the six, and ADK Java needs 1.13.0.

4. What is the difference between ADK callbacks and plugins?

Callbacks attach to one agent and suit checks specific to that agent, such as matching a user ID. Plugins register once at the runner level and apply to every agent that uses that runner. ADK's documentation recommends plugins for security policies that should cover a whole application.

5. How do I limit which MCP tools an ADK agent can use?

Pass a tool_filter list to McpToolset. ADK's MCP checklist says to always supply one, so the model only sees the tools the task needs. Add an explicit timeout for stdio servers and keep remote credentials in a secret store. Review third-party tool descriptions, because they can carry hidden instructions.

6. Does ADK support human-in-the-loop approval?

Yes, through tool confirmation. A tool can ask for a yes or no answer or for a structured payload before it runs. The feature is experimental, and the documentation says it does not support DatabaseSessionService or VertexAiSessionService. Upgrade past CVE-2026-18236, which allowed forged confirmations, before you depend on it.

7. Can Google ADK use models other than Gemini?

Yes. The ADK documentation says it works with almost any generative AI model and offers adapters for other providers and locally running models. Gemini's built-in content filters only apply to Gemini models. If you use another model, plan your own content screening through callbacks, plugins or a gateway.

About the Author

Roger Howroyd is Head of Global SEO and AI at NeuralTrust, where he leads the company's search strategy across SEO, AEO, GEO, and LLM optimization. He specializes in AI-powered search, content strategy, and SEM. Connect on LinkedIn.

NeuralTrust is the leading platform for securing and scaling AI agents. Named a Pioneer in the Gartner Emerging Market Quadrant for AI Application Security 2026, recognized across four Gartner Hype Cycle reports in 2026, and featured in the Gartner Market Guide for Guardian Agents 2026, the Gartner Market Guide for AI Gateways 2025 and the KuppingerCole Leadership Compass for Generative AI Defense 2025. Headquartered in Barcelona with offices in London and New York. ISO 27001 certified.

Sources

Accessed November 6, 2026.

1. Google, "Safety and Security for AI Agents," Agent Development Kit documentation, accessed November 6, 2026.
2. Google, "Get action confirmation for ADK Tools," Agent Development Kit documentation, accessed November 6, 2026.
3. Google, "MCP tools" and "Welcome to ADK 2.0," Agent Development Kit documentation, accessed November 6, 2026.
4. NIST National Vulnerability Database, records for CVE-2026-115522, CVE-2026-107858, CVE-2026-79696, CVE-2026-79707, CVE-2026-18236 and CVE-2026-4810, published between April 13 and October 28, 2026.
5. Python Package Index, "google-adk" release history, accessed November 6, 2026.
6. Model Context Protocol, "Security Best Practices", version 2026-07-28.
7. A2A Project, "Agent2Agent (A2A) Protocol Specification", version 1.0.0, accessed November 6, 2026.
8. OWASP Gen AI Security Project, "OWASP Top 10 for LLM Applications 2026," August 2026.
9. OWASP Gen AI Security Project, "OWASP Top 10 for Agentic Applications for 2026", December 9, 2025.