Google Publishes Zero-Trust Blueprint for ADK Agents
Google published an open-source zero-trust reference design for Agent Development Kit workflows on August 17. Its refund-agent demo shows how a malicious prompt could turn a $149 return into a $10,000 request, then places hard controls outside the model through signed writes, gVisor isolation, and deterministic input/output checks. The practical lesson is that prompts cannot serve as production security boundaries.
Google published a technical blueprint and open-source demonstration on August 17 for securing autonomous agents built with its Agent Development Kit. The example focuses on a customer-support agent that can calculate refunds, execute generated Python, and write to a database—exactly the sort of workflow where a model's mistake becomes a production action.
A refund prompt becomes a security test
Google's scenario starts with a $149 order. A malicious instruction asks the agent to issue a $10,000 refund and print environment variables. If the agent shares broad database credentials or runs generated code directly on the host, the same prompt could authorize an improper payment, expose API keys, or compromise the runtime.
The example matters because it treats system prompts as soft behavioral guidance, not an enforcement layer. A rule such as "never refund more than the order value" can still be bypassed by prompt injection or behave differently after model and prompt changes.
Three controls sit outside the model
Google's design combines three independently enforceable layers:
- •Cryptographic write identity: each state-changing request is signed so the database can verify the acting agent and later detect tampering. The local demo uses HMAC, while the production mapping uses per-agent service accounts and Cloud KMS-backed keys.
- •Isolated code execution: generated Python runs in a gVisor sandbox with no network access, dropped capabilities, strict CPU and memory limits, and a five-second timeout.
- •Deterministic semantic gateways: input and output checks block known jailbreak patterns, secret leakage, and transaction values outside approved bounds before a tool call or database update is accepted.
The accompanying Google Cloud Platform repository includes a browser simulation and runnable Python examples for signed refunds, ledger verification, tamper detection, and gateway tests. Google is explicit that the local components are demonstrations: production deployments require managed identity, hardened sandboxing, network controls, and continuously tested policies.
What practitioners should take from it
This is not evidence that three controls eliminate every agent risk. It is a concrete architecture for separating model reasoning from security authority. The useful design principle is narrower: when an agent can move money, execute code, or alter records, the permission and validation boundaries should remain deterministic, least-privileged, independently auditable, and outside the prompt context.
Key Points
- 1Google's August 17 reference design uses a malicious $10,000 refund request to demonstrate why prompts are not hard security boundaries.
- 2The blueprint combines signed database writes, gVisor-isolated code execution, and deterministic input/output gateways.
- 3The open-source repository provides local simulations and runnable examples, while Google maps the pattern to managed production controls.
Scoring Rationale
The release gives practitioners a concrete, runnable security architecture for agents that execute code and mutate production data, although the examples are reference patterns rather than independent evidence of production effectiveness.
Sources
Primary source and supporting public references used for this report.
Practice with real Ad Tech data
90 SQL & Python problems · 15 industry datasets
250 free problems · No credit card
See all Ad Tech problems
