Google published on August 17, 2026, an architecture and practices guide, accompanied by an open-source demonstrator, for agents capable of modifying a production system. Its central message is clear: a prompt, even a very detailed one, is not a security boundary. Important rules must be enforced by code, permissions, and cryptographic proofs independent of the model.
1. The new risk: the agent who writes
A chatbot that responds poorly mainly produces an information problem. An agent who changes a price, refunds an order, creates a user, or changes a configuration can cause direct harm.
Mistakes do not come solely from malicious intent. The model can misunderstand a context, call the wrong tool, repeat an action after a delay, or follow an instruction injected from an external source.
Security must therefore focus on the capacity for action itself. The target system should not trust a request simply because it comes from the 'agent' service.
2. Why instructions are not enough
A prompt can say 'never refund more than 100 euros' or 'request human validation.' These instructions improve average behavior, but they are still interpreted by a probabilistic model.
An injection can try to bypass them. A model update can change the way they are tracked. A context error can finally lead the agent to believe that an exception is allowed.
Safety rules must be written in a deterministic gateway or in the target API. The model proposes an action; a classical component decides if it is admissible.
3. First layer: sign each modification
Google's architecture recommends a separate key for each agent, managed by Cloud KMS and hardware-protected by Cloud HSM in the described configuration. Each mutation of the demonstrator's ledger is signed. For a production architecture, we recommend extending this principle to every write to the target system. The API can then verify the agent's identity, the integrity of the request, and the absence of tampering.
The signature must cover more than just the JSON body. Include the agent ID, the user who initiated the request, the action, the resource, the amount, the timestamp, a unique identifier, and the applied policy. A nonce or idempotency ID only prevents repetitions if the API keeps track of already processed identifiers and refuses their reuse.
A key unique to each agent makes revocation easier. If a service is compromised, it is possible to block its writes without interrupting all the others.
The signature also provides evidence of technical attribution. It does not prove that the decision was correct, but it allows one to know which component issued the request and whether it has been modified.
4. Second layer: execute in a sandbox
Google illustrates isolation with gVisor, an environment that intercepts system calls in user space. The general principle is to reduce the capabilities of generated code or called tools: no network access by default, limited file system, removed privileges, capped resources, and maximum duration.
The repository specifies that the demonstrator's interface simulates the sandbox and that actual execution under gVisor is optional. Therefore, this is a guide and a starting point to harden, not proof that a complete production architecture has been audited.
A sandbox is only useful if the outputs are controlled. An isolated agent that can write a file which is then blindly interpreted by a privileged service retains an attack path.
The data injected into the environment must be minimal and temporary. A production secret should not be copied into the sandbox when the action can be performed by a narrow API behind a gateway.
5. Third layer: a deterministic semantic bridge
The gateway checks the direction of the action before execution. It applies testable rules: maximum amount, user role, order status, frequency, country, presence of a validation, and field consistency.
The model must not be able to choose the policy itself. It provides a structured intent, ideally conforming to a schema. The gateway enriches it with reference data and decides to allow, deny, or request approval.
The Google demonstrator relies mainly on regular expressions, keywords, and an SQL value check. The richer business controls proposed here constitute an architectural recommendation to be adapted and tested, not a capability universally demonstrated by the tool.
Rules must be tested in CI like business code. A change of threshold or exception goes through a review, a version, and a history.
6. The independent audit journal
The traces generated by the agent are not sufficient, because a compromised component can modify them. Keep an independent log on the gateway or target system side: received request, signature, policy, decision, response, and final state.
To go beyond the Google demonstrator, which periodically checks ledger signatures and recommends Cloud Logging in production, an append-only storage or a hash chain can enhance tampering detection. Logs must remain usable by security and business teams without unnecessarily exposing the full data.
The audit must allow reconstruction of a decision: who requested it, what context was used, which version of the policy was applied, and what action was actually carried out.
7. Design permissions by capability
Avoid a versatile technical account. Create narrow capabilities: read an order, propose a refund, trigger a capped refund, or open a validation request.
Each capability has its own schema, its limits, and its rights. A support agent should not access the cluster configuration simply because both functions use the same tool platform.
Permissions must also take the end user into account. The agent cannot extend the rights of the person they are assisting. This principle is central for any agent connected to the information system.
8. A concrete example: customer refund
Let's consider an illustrative scenario, separate from the Google demonstrator: the agent analyzes the conversation and proposes a refund of 42 euros for order X. It does not directly have the payment key. It calls a capability propose_refund with a strict schedule.
The gateway retrieves the amount paid, the status, previous refunds, and the operator's role. It authorizes amounts under 50 euros in certain cases, requires validation up to 200 euros, and rejects above that.
After authorization, a dedicated service executes the operation and signs the result. The log links the proposal, the policy, and the transaction. A repetition with the same identifier does not create a second refund.
9. The production deployment checklist
Before opening an entry for an agent, check that the action has a closed schema, a deterministic policy, a dedicated identity, a signature, idempotence, and an independent log. Test the limits, repetitions, delays, and malformed data.
Then simulate the attacks: hidden instruction in a document, tool that returns hostile content, revoked key, old timestamp, out-of-role action, and attempt to bypass the cap.
Start in read-only mode, then in suggestion mode. Only allow automatic execution for reversible operations, with low impact and sufficiently monitored.
The zero-trust approach does not aim to make the model foolproof. It assumes that it can be wrong and limits what a mistake can produce. It is this inversion that makes it possible to move from a demonstration to an actionable capability.
Partitech supports the securing of business agents: capability design, policy bridges, KMS signatures, sandboxing, audit, and adversarial scenario testing.