Google ADK Zero-Trust AI Agents Security Guide

The short answer

Google’s August 17, 2026 guidance for building zero-trust AI agents with the Agent Development Kit (ADK) makes a practical point: a system prompt is not a security boundary once an agent can write to a database, call internal APIs, or execute generated code. The model should be treated as an untrusted decision-maker inside a larger system that enforces identity, isolation, authorization, and auditability.

The recommended architecture has three independent controls:

1. Cryptographic write identity so a database can verify which agent authorized a mutation.
2. Kernel-level isolation for generated code, with no network egress and strict resource limits.
3. Deterministic semantic gateways that validate inputs, tool calls, outputs, and business rules outside the model.

This is consistent with the independent OWASP AI Agent Security Cheat Sheet, which recommends least-privilege tools, explicit approval for high-impact actions, input and output validation, memory integrity, monitoring, and adversarial testing. The important engineering lesson is not to copy a cloud architecture line by line. It is to make every high-impact action pass through controls that remain effective when the model is confused, manipulated, or upgraded.

Why prompts stop being enough

A prompt can tell an agent not to refund more than an order total. It cannot guarantee that a model will always interpret the instruction correctly, that retrieved content will not contain an injection, or that a later model update will preserve the same behavior. It also cannot prove which process performed a write after the fact.

Google’s example uses an autonomous support and returns agent. In its normal path, the agent reads an order, calculates a refund, updates a ledger, and returns a receipt. An attacker can combine a prompt injection with a request to run code and attempt to turn a small refund into a much larger payout while exposing environment variables.

The security boundary therefore has to move outward:

• The model may propose an action, but an authorization layer decides whether it is permitted.
• The model may generate code, but an isolated runtime decides what that code can access.
• The model may produce a tool call, but a deterministic gateway validates the arguments before execution.
• The database may accept a write, but only after verifying the caller’s identity and the policy for that mutation.

This separation complements the Google ADK 2.0 workflow runtime, where deterministic graph transitions can keep side effects outside an unconstrained model loop.

The three-layer zero-trust design

Visual 1 — A zero-trust request path. The model proposes; gateways, the sandbox, the key service, and database ingress enforce. Adapted from Google’s ADK zero-trust guidance and the OWASP agent-security control categories.

1. Give every agent a verifiable write identity

A shared database connection makes attribution weak. If several workers use the same credentials, an audit log may show that a service made a change without proving which agent instance approved it. Google’s design assigns an agent its own signing identity and places the private key in Cloud KMS backed by hardware security modules. The application signs a deterministic representation of the payload; the database-side ingress guard verifies the signature before committing the write.

For a local demonstration, the blog uses an HMAC equivalent. Production systems should not copy a demo secret into an environment variable. Use a managed key service, narrow IAM permissions, key rotation, and a verification path that is independent of the model process.

The payload should cover the fields that matter to authorization, such as:

• agent identity and version;
• tenant, customer, and resource identifiers;
• requested operation and amount;
• policy or approval reference;
• idempotency key and timestamp.

A signature is not authorization by itself. It proves who signed a payload; the receiving service must still check that the agent is allowed to perform that operation and that the payload is current, bounded, and associated with the right resource.

2. Isolate generated code instead of calling exec()

An agent that writes Python for calculations or data transformation can become a code-execution surface. Google recommends running generated code in a gVisor-backed container with no network, dropped capabilities, read-only input, memory and CPU ceilings, and a timeout.

That is defense in depth, not a magic escape-proof guarantee. Keep secrets out of the sandbox environment, mount only the files required for the task, use a minimal image, pin dependencies, and treat the result as untrusted data. If a job needs network access, split that operation into a separately authorized tool rather than giving arbitrary generated code outbound connectivity.

A simplified request shape looks like this:

1result = run_isolated(
2    code=generated_code,
3    network="none",
4    filesystem="read-only-input",
5    capabilities="drop-all",
6    memory="64MiB",
7    cpu="0.1",
8    timeout_seconds=5,
9)

Visual 2 — The isolation contract for generated code. The exact runtime flags, image, and limits must be tested against the deployment environment; this compact example is a design checklist, not a production runner.

3. Put deterministic policy in front of tools and side effects

The semantic gateway is the most familiar application pattern: a policy-enforcing reverse proxy between model output and execution. It should validate structured tool arguments rather than searching only for suspicious phrases.

For a refund workflow, deterministic checks might include:

• the purchase belongs to the authenticated customer;
• the refund amount does not exceed the eligible amount;
• the currency and decimal precision are valid;
• the operation has an idempotency key;
• a human approval exists when the amount crosses a risk threshold;
• the destination tool is on an allowlist;
• the request contains no secrets or unexpected personal data.

String heuristics can catch obvious jailbreaks, but they should be supplementary. A robust gateway validates types, authorization context, resource ownership, state transitions, and side-effect policy. The OWASP guidance similarly emphasizes scoped tools, confirmation for sensitive operations, output validation, and monitoring.

What to implement first

Teams do not need to deploy every control on day one. Start with the paths that can change money, permissions, production data, or external communications.

Visual 3 — Control comparison for an agent that can use tools or mutate state. The table synthesizes the control families in Google’s article and OWASP’s independent checklist.

A good first milestone is a single sensitive workflow with an explicit state machine:

1. Load only the records the caller is permitted to see.
2. Ask the model to classify or extract a structured decision.
3. Validate that decision against typed application state.
4. Request approval when the action is high impact.
5. Sign the final mutation with the agent identity.
6. Verify the signature and policy at database ingress.
7. Record the decision, tool arguments, approval, result, and failure path after redaction.

This is the same principle described in the site’s harness engineering guide for AI coding agents: reliability comes from shaping the environment around the model, not from making the instruction longer.

ADK-specific implementation considerations

The official ADK documentation describes ADK as an open-source, code-first framework available across Python, TypeScript, Go, Java, and Kotlin, with support for workflows, tools, MCP, evaluation, deployment, and human input. The framework gives developers useful building blocks, but the application still owns its trust model.

For an ADK application, keep these responsibilities explicit:

• Agent layer: interpret requests, select from permitted tools, and return structured proposals.
• Workflow layer: control ordering, retries, pauses, and transitions.
• Policy layer: enforce identity, resource ownership, limits, approvals, and idempotency.
• Runtime layer: isolate code and constrain network, filesystem, CPU, memory, and time.
• Evidence layer: record enough context to investigate without logging secrets or unnecessary customer data.

The latest ADK Python releases also show why this matters operationally: framework releases change event handling, tool behavior, telemetry, and compatibility. A model or framework upgrade should trigger authorization regression tests, not just a package update.

Common mistakes

Treating a system prompt as an authorization policy

Prompts express intent; they do not establish identity or enforce a transaction limit. Put the limit in the service that owns the resource.

Giving an agent a general-purpose shell

A tool named execute_command with unrestricted arguments collapses the security boundary. Expose narrow operations with allowlisted paths, commands, and parameters.

Signing after the write

A post-hoc log entry does not prevent an unauthorized mutation. Verify the signed payload before the database commit, and make the record immutable or append-only where practical.

Catching every exception inside tools

If a tool hides timeouts and policy failures, the workflow runtime may not retry, pause, or record the failure correctly. Return typed errors and preserve the failure signal.

Logging too much

Agent traces can contain prompts, retrieved documents, credentials, and personal data. Redact before persistence, separate operational telemetry from sensitive payloads, and set retention limits.

Assuming one control is enough

A signature does not stop a malicious tool call. A sandbox does not enforce refund policy. A gateway does not prove which process made the request. The controls are intentionally layered because each covers a different failure mode.

FAQ

Is Google ADK secure by default?

No. ADK provides agent, workflow, tool, evaluation, and deployment capabilities. The application still has to define least privilege, authorization, isolation, approval, secrets handling, and audit controls.

Do all agents need hardware-backed signing?

Not necessarily. A read-only research agent may not issue state-changing writes. For agents that mutate production data, payments, permissions, or other high-impact state, a verifiable service identity and pre-commit authorization are much more valuable than a shared credential.

Can Docker alone safely run model-generated code?

A standard container reduces exposure but shares the host kernel and can be misconfigured. Use the strongest isolation available for the threat model, remove network access by default, drop capabilities, limit resources, and keep secrets outside the execution environment.

Where does MCP fit?

MCP exposes tools and resources; it does not decide whether a particular agent, user, tenant, or workflow may invoke them. Apply the same allowlisting, authentication, argument validation, approval, and audit rules to MCP tools as to native functions. The site’s MCP security guidance is a useful companion for reviewing the developer-tooling layer.

Conclusion

Zero-trust agent security is an architectural discipline: assume the model can be manipulated, then make important actions fail closed outside the model. For ADK applications, the practical sequence is to keep workflows explicit, restrict tools, isolate generated code, validate every side effect, sign sensitive writes, and test the controls whenever the model or framework changes.

That approach preserves the useful flexibility of agent reasoning without allowing a prompt, tool description, or model update to become the final authority over production state.

Sources and visual credits

• Google Developers Blog: Build zero-trust AI agents with Google’s Agent Development Kit — primary source for the three-layer architecture, example threat, and implementation patterns.
• Google ADK documentation — official framework capabilities and supported integrations.
• google/adk-python releases — official release history and compatibility evidence.
• OWASP AI Agent Security Cheat Sheet — independent source for least privilege, validation, approval, monitoring, and testing controls.
• Visual 1: original Mermaid request-path diagram, adapted from Google and OWASP control categories.
• Visual 2: original isolation-contract code visual, based on the constraints described in Google’s primary guidance.
• Visual 3: original comparison table synthesizing the verified control categories; no invented benchmark or performance data.