Zero-Trust AI Agents Need Hard Boundaries Outside the Model

TL;DR

An autonomous returns agent that can calculate a refund, run generated code, and write a database row sounds like a demo. Google's zero-trust example, built on the Agent Development Kit (ADK), runs it as an adversarial test instead, and the underlying premise is the one worth sitting with: the model may be tricked or jailbroken, so hard security guarantees must sit outside the LLM context across multiple layers.[1] A system prompt is not a security boundary, no matter how carefully it's worded. The practical pattern Google lays out has three layers: cryptographic identity for every state-changing write, user-space isolation for anything the agent generates and runs, and deterministic validation that sits between the model and any tool call or side effect. None of the three is sufficient alone — a sandbox still sits on a shared host kernel, and a signed write nobody validates is still an unstopped write — so the practical path is to implement all three together for one narrow, high-stakes workflow first, since agent security is an infrastructure discipline, not a prompt-writing exercise.

What the example is actually testing

The scenario is an autonomous customer-support and returns agent.[1] On the normal path, it reads a request, generates a Python calculation, writes an approved refund to a ledger, and returns a receipt to the customer. The dangerous path combines two tests: a crafted prompt tries to inflate the refund amount while the generated code is also asked to print environment variables. Google uses this pair of scenarios to make a specific point — a system instruction telling the model that a refund must never exceed the order total is a soft constraint. The model can be argued out of it, distracted from it, or simply mistaken about it. Nothing about "the model was told not to" survives an adversarial user who is trying.

Control one: sign every state-changing write

The first control is cryptographic non-repudiation.[1] Each agent gets its own identity, and every database mutation is signed before the database will accept it. Google maps the production version of this to a service account permitted to use an asymmetric Cloud KMS key backed by an HSM; the private key is generated inside the HSM and never leaves it, so the private key remains inside the HSM rather than being exposed to the container or process.[1]

That distinction matters most during incident response, not during normal operation. A database row that says "refund approved" is not evidence of anything on its own. What an investigator actually needs to know is which agent identity produced the write, under which workflow, and whether the payload changed at any point between authorization and commit. I would build signature verification directly into the write path itself, as a precondition the database enforces, not as something a nightly reconciliation job discovers after the fact.

Control two: treat generated code as hostile by default

The second control is execution isolation.[1] Standard containers still share the host Linux kernel, and Google's example treats that as a reason a generated script should never receive broad access just because the task in front of it looks harmless. The pattern uses gVisor for user-space isolation, read-only mounts, zero network egress, resource limits, and an explicit timeout on every run.[1]

None of that is a claim that gVisor eliminates every container risk on its own. The host kernel still matters underneath any sandbox: containers share it, and a sandboxed process is not exempt from a host-kernel vulnerability. It is a narrower design decision: generated code runs in a smaller trust domain than the agent orchestrator that produced it, and the runner has a hard end condition instead of running until something stops it. Google's guidance also points to VPC Service Controls and CI/CD regression tests as part of the same layer — network-level containment around the execution boundary, and automated tests that catch a policy or prompt change before it reaches production rather than after.[1] For a production workflow, add a separate credential boundary for the sandbox, an ephemeral workspace that does not persist between runs, a CPU and memory budget, and a retained execution record that survives the sandbox being torn down.

Control three: put deterministic gates before anything with a side effect

The third control is a semantic gateway that checks incoming requests and outgoing tool calls against rules that do not depend on the model correctly remembering its own instructions.[1] A refund ceiling, a secret filter, an allowed-destination list, or a required-approval condition can each be written as a testable contract with a pass or fail outcome — not a hope. The gateway rejects the action before the database or the external API ever sees it, which means the check happens at the one point in the pipeline where the model's judgment is no longer the deciding factor.

A grounded case worth working through

Take a concrete case. Imagine a Casablanca e-commerce SME running a returns agent close to Google's own example: it reads a customer message, calculates a refund, and writes it to an order-management system. Without the three controls, the failure modes are exactly the ones described above, just with real money attached — an inflated refund that nobody can trace back to a specific agent run, or a generated script that reaches further into the host than anyone intended because "it's just a calculation." With the three controls in place, the same agent can still act autonomously on the routine case, but every write carries an identity that survives a dispute, every generated script runs inside a boundary it cannot talk its way out of, and every refund above a threshold hits a gate that does not care how persuasive the prompt was. The architecture does not make the agent smarter. It makes the failure cheap to detect and cheap to reverse, which is the actual goal.

The boundary is an architecture, not a prompt

The three controls are complementary rather than redundant.[1] Signatures answer who wrote the state. Sandboxing limits what generated code is physically able to do. Deterministic gates answer whether the requested action is allowed at all, independent of how the model got there. Remove any one of the three and the remaining controls end up carrying more responsibility than they were designed for — a signed write that was never validated by a gate is still a write nobody stopped.

This is the same inventory-first discipline this blog applies whenever a team connects agents to existing systems: map what the agent can touch before buying an AI gateway. The model choice comes later in the process, not first. The permission map, the approval owner, the rollback path, and the audit record have to come before it.

What to implement first, in order

Start with one narrow workflow, not the whole product surface, and write down five things before touching any code: the resources it may read, the state it may change, the actions that require human approval, the evidence retained for each action, and the rollback procedure if something goes wrong. Then implement a signed write, or an equivalent tamper-evident record, for that workflow specifically. Isolate code execution next, using the narrowest sandbox that still lets the workflow function. Finally, add deterministic tests that run automatically in CI whenever the prompt, the model, the tool schema, or the policy changes — because any of those four can silently break an assumption the gate was built around.

Do not begin with "full autonomy" as the design target. Begin with a workflow whose failure cost is fully understood, and expand from there once the boundary has actually been tested against a hostile input, not just a happy path.

Bottom line

Google's ADK example is valuable because it treats agent security as an infrastructure problem rather than a prompt-writing contest, which is a genuinely different discipline with different people responsible for it. The durable lesson holds regardless of which model or framework a team eventually picks: reasoning can stay flexible, but identity, execution boundaries, and business rules have to be hard. If your team is preparing its first production agent, Netics can help audit the permission and rollback boundary.

Sources

[1] https://developers.googleblog.com/build-zero-trust-ai-agents-with-googles-agent-development-kit — Google Developers Blog — Build zero-trust AI agents with ADK

Source: Google Developers Blog — 2026-08-17. Netics analysis.