Google ADK Zero-Trust AI Agents: A Practical Security Guide

The short answer

Google’s new Agent Development Kit (ADK) zero-trust guidance treats an AI agent as a potentially compromised component—not as a trusted security boundary. The practical pattern is to place deterministic controls around the model: cryptographically sign state-changing writes, isolate generated code in a gVisor sandbox with no network egress, and validate inputs and tool calls through a semantic gateway.

That matters whenever an agent can refund money, update a database, call internal APIs, or execute code. A system prompt saying “never refund more than the order total” is useful policy context, but it is not an enforcement mechanism. The database, runtime, and gateway must independently reject unsafe actions.

This guide translates Google’s reference design into an implementation checklist for intermediate developers building ADK or other multi-tool agents.

Why this guidance matters now

On August 17, 2026, Google published a zero-trust design for an autonomous Customer Support & Returns Agent built with ADK and Gemini. The demonstration uses a $149 order and an injected request for a $10,000 refund plus a request to print environment variables. Google’s point is not that every agent will perform that exact action. It is that an agent connected to production state can turn natural-language manipulation into a financial, data, or host compromise.

The risk is also visible in real repository automation. The Hacker News reported in August that Google removed three ADK repository workflows after Pillar Security demonstrated how an untrusted GitHub issue could influence a public triage agent and reach a privileged code-fixing workflow. The report distinguishes the repository automation flaw from a vulnerability in the distributed ADK package, but the lesson is the same: trusted identity and untrusted text must not be conflated.

For more background on reliable orchestration, see this Google ADK 2.0 workflow runtime guide. For a broader look at agent authorization failures, compare the AI agent tool authorization bypass analysis.

The three-layer architecture

The architecture deliberately separates model reasoning from enforcement. The model may propose a refund or generate a calculation, but it cannot directly decide whether the action is valid.

Figure: original editorial flow showing where hard controls sit around the model. It is based on the architecture described in Google’s official ADK zero-trust guidance.

No layer is sufficient by itself. A signature can prove who signed a bad request, but cannot make the request safe. A sandbox can contain generated code, but cannot enforce a refund maximum. A gateway can block known patterns, but should not be the only control protecting a database.

Layer one: sign every state-changing write

A shared database connection pool makes attribution weak. If several workers write through the same credentials, an audit trail may show that the application changed a row without proving which agent approved the mutation. Google’s design gives each agent a distinct signing identity and requires the database ingress path to verify a signature before committing a write.

In Google Cloud, the production mapping uses a dedicated service account with permission to sign using an asymmetric key in Cloud Key Management Service, backed by Cloud HSM. The private key is generated and retained in the protected key service rather than being copied into a container.

A simplified payload should include the identity, action, resource, amount, and a nonce or request identifier. Serialize it deterministically before hashing; otherwise equivalent JSON objects can produce different signatures.

1import hashlib
2import json
3from google.cloud import kms
4
5
6def canonical_bytes(payload: dict) -> bytes:
7    return json.dumps(
8        payload, sort_keys=True, separators=(",", ":")
9    ).encode("utf-8")
10
11
12def sign_refund(payload: dict) -> bytes:
13    client = kms.KeyManagementServiceClient()
14    key_version = client.crypto_key_version_path(
15        "PROJECT_ID", "global", "agent-keys",
16        "support-refund-agent", "1"
17    )
18    digest = hashlib.sha256(canonical_bytes(payload)).digest()
19    response = client.asymmetric_sign(
20        name=key_version,
21        digest={"sha256": digest},
22    )
23    return response.signature

The snippet is an integration pattern, not a complete payment implementation. In production, verify the KMS key algorithm, IAM policy, key version, replay protection, and database transaction boundary against the current Cloud KMS asymmetric-signing documentation. Do not put private signing material in environment variables merely because a local demo does so.

At the database boundary, verify the signature over the exact payload that will be committed. Store the signature, key version, agent identifier, request ID, and timestamp with the ledger record. A background audit can re-check records and identify tampering after the original write.

Design checklist for signed writes

• Give each materially different agent its own identity and key policy.
• Sign the complete business payload, not only the amount.
• Include a unique request ID and reject replays.
• Verify authorization and signature in the same transaction boundary as the write.
• Keep the audit record append-only or independently protected.
• Rotate keys with an explicit key-version strategy and preserve verification history.

Layer two: isolate generated code

Agents frequently generate code for calculations, transformations, or data inspection. Running that code with Python exec(), a privileged subprocess, or a default container is not a sufficient boundary. Generated code can read environment variables, inspect mounted files, open sockets, or exploit a container configuration.

Google’s example uses gVisor, disables network access, drops capabilities, limits memory and CPU, mounts the input read-only, and applies a timeout. The important principle is defense in depth: the code runner should be disposable, minimally privileged, and unable to reach production credentials.

1import os
2import subprocess
3import tempfile
4
5
6def run_untrusted_python(source: str) -> dict:
7    with tempfile.TemporaryDirectory() as directory:
8        path = os.path.join(directory, "program.py")
9        with open(path, "w", encoding="utf-8") as handle:
10            handle.write(source)
11
12        try:
13            result = subprocess.run(
14                [
15                    "docker", "run", "--rm",
16                    "--runtime=runsc",
17                    "--network=none",
18                    "--cap-drop=ALL",
19                    "--memory=64m",
20                    "--cpus=0.1",
21                    "-v", f"{path}:/app/program.py:ro",
22                    "python:3.10-slim",
23                    "python", "/app/program.py",
24                ],
25                capture_output=True,
26                text=True,
27                timeout=5,
28                check=False,
29            )
30            return {
31                "stdout": result.stdout,
32                "stderr": result.stderr,
33                "exit_code": result.returncode,
34            }
35        except subprocess.TimeoutExpired:
36            return {"error": "execution timed out"}

Treat this as a baseline, not a drop-in guarantee. Pin the runtime image by digest, scan it, set filesystem and process limits, remove all cloud credentials, and apply an external supervisor timeout. Verify that gVisor is installed and actually selected; a misspelled runtime flag must fail closed rather than silently falling back to ordinary Docker isolation.

Prefer avoiding generated code altogether when a typed, constrained tool can perform the same operation. If code is unavoidable, pass data through a narrow file or standard input interface instead of mounting application directories.

Layer three: enforce deterministic semantic policy

The semantic gateway is the policy enforcement point before the model and before side effects. It should inspect user input, model output, tool arguments, and database queries. It can reject obvious secret exfiltration, known jailbreak patterns, malformed identifiers, or a refund larger than the verified order amount.

Figure: original editorial sequence diagram for the request and write path. Policy checks are deterministic code, while ADK remains responsible for orchestration.

A gateway should not rely on string matching alone. Rules should validate structured tool arguments, look up authoritative order state, enforce maximums server-side, and remove secrets from logs. Pattern checks are still useful as an additional signal:

1import re
2
3
4def check_refund(order_total: float, requested: float, text: str) -> tuple[bool, str]:
5    if requested > order_total:
6        return False, "refund exceeds verified order total"
7    if re.search(r"\b(?:\d{4}[ -]?){3}\d{4}\b", text):
8        return False, "payment-card pattern detected"
9    if any(marker in text.lower() for marker in ("sk_live_", "api_key", "environment variables")):
10        return False, "possible secret-exfiltration request"
11    return True, "allowed"

The production version should use typed schemas, policy versioning, authorization checks, and tests for every business-critical invariant. Run the policy test suite whenever prompts, models, tools, or gateway code changes. A model upgrade is a security-relevant change even when the application code is unchanged.

What ADK developers should change in practice

The zero-trust design fits naturally around ADK’s agents, workflows, tools, and human-in-the-loop confirmation. Start with the least authority possible:

1. Separate planning from execution. Let one agent propose an action and a separate service validate and execute it.
2. Use typed tools. Make amount, order ID, currency, and reason explicit fields; do not accept a free-form SQL string.
3. Require confirmation for irreversible actions. ADK’s tool-confirmation flow can add a human checkpoint, but the backend must still enforce limits.
4. Make credentials capability-specific. A refund agent should not possess deployment credentials or unrestricted database write access.
5. Treat retrieved text as hostile input. Issue descriptions, emails, documents, and web pages can contain instructions aimed at the agent.
6. Log proposals and decisions separately. Preserve the model’s proposal, policy result, signer, and final side effect for incident response.
7. Test attack paths continuously. Include prompt injection, replay, over-limit transactions, secret requests, sandbox escape attempts, and malformed tool arguments.

This complements the StepSecurity developer-machine security guide and the harness engineering guide for coding agents. Those topics address adjacent control planes; this article focuses on agents that mutate application state.

Common mistakes and debugging signals

“The system prompt already forbids that action”

A prompt is not a database constraint. Add a server-side invariant and test it with a direct API call that bypasses the model.

“The container has no dangerous Linux capabilities”

Check the actual runtime, mounts, network namespace, image digest, and inherited environment. A secure-looking command line can still expose secrets through a mounted socket or host directory.

“The user is authorized, so the agent is authorized”

Human authorization does not automatically authorize every tool call the model can invent. Map each action to an explicit capability, resource, amount, and purpose.

“The signature verifies, so the transaction is safe”

Signatures provide attribution and tamper detection, not business correctness. Validate the order total and policy decision before signing.

“The policy blocks jailbreak phrases”

Attackers can paraphrase. Use structured argument validation, resource lookups, allowlists, and rate limits in addition to lexical detectors.

Useful operational alerts include repeated gateway rejects, signature failures, replayed request IDs, sandbox timeouts, unexpected outbound attempts, and policy-denied tool calls followed by successful alternate paths.

FAQ

Is this only for Google ADK?

No. The controls apply to any agent framework that can call tools or mutate state. ADK is the reference implementation used in Google’s demonstration; the security boundaries belong in the infrastructure and service layer.

Does gVisor make generated code safe?

No. It reduces blast radius. You still need a minimal image, no credentials, no network, resource limits, patching, monitoring, and a design that avoids arbitrary code when possible.

Should every agent write directly to the database?

Usually no. A policy service or narrow domain API is easier to validate than arbitrary database access. If direct writes are unavoidable, enforce schema, authorization, signing, and transaction checks at the ingress boundary.

Is human approval enough?

Human approval is valuable for high-impact actions, but it can be rushed, spoofed, or applied to an incomplete explanation. Keep deterministic backend controls even when a person approves the action.

Conclusion

Google’s ADK zero-trust guidance offers a practical rule for production agents: let the model reason, but do not let it define the security boundary. Bind writes to cryptographic identities, execute untrusted code in a constrained sandbox, and validate every meaningful input and side effect with deterministic policy.

The most important implementation step is to move from “the agent was instructed not to do that” to “the system cannot do that without passing independent checks.” That shift makes agent behavior auditable, limits prompt-injection damage, and gives developers a repeatable foundation for safer multi-tool workflows.

Sources and visual credits

• Google Developers Blog: Build zero-trust AI agents with Google’s Agent Development Kit — primary source and architecture reference.
• Help Net Security: Google’s $10,000 refund test shows why AI agents need zero trust — independent technical coverage.
• The Hacker News: Google deletes three ADK AI workflows after a malicious GitHub issue — independent security context.
• Google ADK Python repository — official toolkit documentation and implementation reference.
• Mermaid diagrams and the comparison table are original editorial visuals created for this article; the architecture concepts are credited to Google’s primary source above.