Your AI agent can read your data, fetch the web, and remember you. Pick two.

Version 1.0 · Published 2026-07-20

In the second week of July 2026, mainstream agent tooling leaked twice. A researcher showed that Claude could be tricked into leaking user data through its web fetch tool, and xAI’s Grok Build CLI turned out to be uploading entire code repositories to a cloud bucket, secrets included.

If you are evaluating a customer-facing AI agent right now, these two stories are more useful than any feature list. By the end of this post you will have four questions that reveal more about an agent’s real risk than a hundred-page security questionnaire.

The week agent tooling leaked twice

The first incident was a design loophole, not a bug. Anthropic’s web fetch tool was only supposed to visit URLs the user typed or search returned, but it would also follow links embedded in pages it had already fetched. Researcher Ayush Paul chained that into an exfiltration attack: a honeypot site with nested links walked the agent into leaking the user’s name, city, and employer, and the malicious content was only served to requests identifying as Claude to make it harder to spot.

The second incident was blunter. xAI’s Grok Build CLI uploaded entire repositories to a cloud storage bucket, including .env files full of credentials, regardless of which files the agent actually read and even with the privacy toggle switched off. xAI disabled the feature and open-sourced the tool after the backlash.

Neither is a rogue-vendor story. Both are reasonable-looking designs that leaked anyway, and that is exactly why they matter to a buyer.

The lethal trifecta, in buyer’s terms

Simon Willison has a name for the pattern: the lethal trifecta. An agent becomes dangerous when it combines three individually useful capabilities: access to private data, exposure to untrusted content, and a channel to communicate out.

The problem is that a language model reads instructions and data through the same channel. Anything untrusted the agent reads, a web page, an email, a customer message, can carry instructions, and if a path out exists, those instructions can carry your data with them. This is prompt injection, and no vendor has solved it.

Now look at a customer-facing agent through that lens. It holds customer history, it reads whatever customers type, and it answers in the open. The trifecta is not an edge case; it is the default shape of the product category you are buying.

The axis that decides the risk

Since you cannot remove any leg of the trifecta and still have a useful Customer Agent, the risk is decided elsewhere: by what each component can see and where data can flow. Good intentions do not enter into it, and neither does the logo on the SOC 2 report.

We have made this argument before about cloud regions: an EU region is not a data boundary, because residency fixes where data sits, not what can see it. Agent tooling is the same axis, one layer up. The Grok Build case makes it concrete: the marketing said local-first, the data flow said otherwise.

The four procurement questions

This gives you a checklist you can run on any agent vendor, including us.

• Which tools can touch private data? Ask for the list of tools the agent can call, and which of them can read customer records, memory, or files. Every tool on that list is a leg of the trifecta.

• What sits between the data and the model? At UNLESS, PII is filtered and tokenized at the gateway by the Privacy Vault, before any model sees the prompt. Whatever the vendor’s answer, it should name a mechanism, not a policy.

• What crosses the boundary out? Which calls leave the perimeter, to which providers, in which jurisdiction, and is that flow logged? This is the question the Grok Build users never got to ask.

• What trail does each decision leave? Unless writes a per-decision audit trail: timestamp, decision path, model used, source citation, exportable. Pair it with reversibility: the agent never takes an irreversible action without a human-approved boundary.

The common mistake is accepting a certification as the answer. SOC 2 and ISO reports describe an organization’s processes; the trifecta lives in the data flow, and only the four questions above expose it.

What no vendor should tell you

If a vendor tells you their agent is immune to prompt injection, end the meeting. Nobody is immune, including us, and the honest design goal is different: contain the blast radius when an injection lands, and prove afterwards exactly what happened.

That is what the checklist actually tests. Not whether the vendor is confident, but whether the architecture assumes the attack and limits what it can reach.

So here is the next step: take the four questions to the agent vendor you are currently evaluating, or to the one you already run. If you want to see what the answers look like when the architecture was built for them, our trust page is the worked example.