Security1 distinct publisher3 min readUpdated
The open-source demo treats the model as untrusted and pushes controls outward: signed database writes, a gVisor sandbox with no network, and a deterministic gateway in front.
The Watch · Security desk

Compiled by The WatchSomething wrong?How this is made
The open-source demo treats the model as untrusted and pushes controls outward: signed database writes, a gVisor sandbox with no network, and a deterministic gateway in front.
Google has published an open-source Customer Support and Returns Agent, built on its Agent Development Kit and Gemini, and shipped the attack against it in the same package: a customer with a $149 order instructs the agent to issue a $10,000 refund and to run Python that exposes environment variables [1][4]. That demonstration matters less than the argument it is there to make, which is that the security boundary does not belong inside the model [5][6].
In normal operation the agent reads a return request, generates a Python script to calculate prorated restocking deductions, records an approved refund in a database ledger, and returns a confirmation [3]. Every one of those steps is an attack surface. Google's own description of the failure case is blunt: an agent using a shared database connection and executing code in an unisolated environment could authorize the payment, expose API keys, or compromise the host server [c4a]. The refund in the demo is roughly 67 times the order value [17], which is precisely the kind of thing a system prompt is supposed to catch.
It does not. Google states that a system prompt telling the agent never to refund more than an order's value is not a hard security boundary, because prompt injection can bypass such instructions and because prompt tuning and model updates change how the model responds [5][6]. This is the useful part of the writeup for anyone currently negotiating with their own prompt file.
The reference architecture puts three layers outside the model [7]. First, every state-changing database write is signed by the agent responsible for it, and the database verifies the signature before committing, giving cryptographic attribution and making later tampering detectable [8]. For production on Google Cloud, Google recommends one service account per agent with signing permissions on an asymmetric key in Cloud KMS backed by Cloud HSM, with the private key generated inside the HSM and never leaving it [9]. The open-source demo substitutes an HMAC key for local testing [10]. A background audit checks record integrity: alter a $149 refund to $10,000 directly in the database and the signature no longer matches the payload, and the audit alerts [11].
Second, generated code runs inside a gVisor user-space sandbox with network egress disabled and limits on memory, CPU, and execution time, with a five-second timeout for runaway jobs [12]. Third, a Semantic Gateway sits between the agent and the systems it can touch, applying deterministic checks to incoming prompts and outgoing tool calls before the model is invoked or a database update executes, identifying credit card numbers and secrets, matching specified jailbreak patterns, and enforcing transaction limits [13][14]. Google recommends treating those policies as software contracts with automated tests, so they keep working after prompt changes or model migrations [15]. Production deployments can also sit inside a VPC Service Controls perimeter to limit exfiltration across the project boundary if a workload is compromised [16].
"Building autonomous agents does not require accepting unconstrained risk," wrote Google's Shubham Saboo and Eric Dong [18].
What to watch: whether the signing story survives contact with latency and cost budgets, since per-write HSM signing is not free, and whether the HMAC shortcut in the demo becomes the thing teams actually ship. Watch the Semantic Gateway's pattern matching too. Deterministic transaction limits will hold; a list of "specified jailbreak patterns" [14] is a denylist, and denylists age. The signed ledger and the sandbox are the load-bearing controls here.
Follow any of these and your For You feed starts watching them — no settings page required.
Ranked by verification strength, evidence, and original report placement.
Google published an open-source autonomous Customer Support & Returns Agent built using the Agent Development Kit (ADK) and Gemini, demonstrating zero-trust security principles for AI agents that interact with sensitive systems and take real-world actions.
The project tests an approach that assumes an AI agent could be manipulated or compromised and puts security controls around it to limit what the agent can do.
During normal operation the customer support agent reads a customer's return request, generates a Python script to calculate prorated restocking deductions, records an approved refund in a database ledger, and provides a confirmation.
Google demonstrates an attack in which a customer with a $149 order instructs the agent to issue a $10,000 refund and run Python code that exposes environment variables.
Google states that an agent using a shared database connection and executing code in an unisolated environment could authorize the payment, expose API keys, or compromise the host server.
Google's design treats the model as a component that could be tricked or jailbroken, and states that a system prompt telling the agent never to refund more than an order's value does not provide a hard security boundary.
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Detailed but single-sourced and vendor-originated
The architecture is described in unusual technical specificity - signed writes verified pre-commit, gVisor sandbox with egress disabled and a five-second timeout, deterministic gateway checks, KMS/HSM signing, VPC Service Controls - and the code is publicly runnable, which is checkable in principle. But all of it traces to Google's own publication relayed by one outlet, with no independent red-teaming, no benchmark of block rates, and an admitted gap between the recommended HSM-backed signing and the HMAC stand-in that ships in the demo.
Reference implementation only
The only observable adoption event is the open-source release itself plus a browser-based attack playground for testing. No production deployment, customer, usage disclosure, or downstream implementation of the pattern appears in the supplied material, and the demo's local configuration substitutes an HMAC key for the recommended Cloud KMS/HSM path.
Mildly overstated relative to what is verified
The underlying reporting is restrained and hedged ('can be blocked', 'help allow'), and the threat model is a legitimate one. The overstatement is modest and structural: an unverified vendor demo is presented as an answer to agent risk, the headline dramatizes a staged $10,000 refund on a $149 order, and the defensive claims - gateway blocks, tamper-evident ledger, sandbox containment - have no independent test or adoption behind them, while the demo itself weakens its own key-management claim.
Strong first-party commercial incentive
Every claim originates with Google, and the recommended hardening path runs through Google's own paid or platform services: ADK and Gemini for the agent, Cloud KMS with Cloud HSM for signing identity, and VPC Service Controls for the perimeter. The named authors are Google employees. That does not make the architecture wrong, but the material doubles as product positioning for agent security spend, and the sole publisher relays it without an independent counterweight.
Moderate: facts are clear, significance is not established
Confidence in what was published is high - the technical description is internally consistent, specific, and attributable, and the release is checkable. Confidence in the broader implication that this pattern constrains real agent risk is much lower, because there is one publisher, one originating party with a commercial stake, no independent evaluation, and no adoption signal beyond the release.
build
Grok built its own prompt injection: the filter never saw the payload1 distinct publisher
security
Encrypted injection walks past Grok's filters and out through its own browser1 distinct publisher
invest
A Connecticut judge just priced prompt injection: no fine, no e-filing2 distinct publishers
build
Your agent needs the API call, not the API key1 distinct publisher
Distinct publishers with included, body-backed reporting in this cluster.
1 article · August 18, 2026