Agent Builder Foundations

Closing the most direct exfiltration path does not close the channel. Claude's web_fetch already blocked the model from fetching a URL it built to encode private data. Ayush Paul found a second path: web_fetch could follow links found *inside a page it had already fetched*. A honeypot steered Claude through a chain of letter-indexed links and leaked a user's name, home city, and employer. Anthropic's fix removed link-following from fetched content.

Ask two questions of every content-reading tool:

• Can the model build an outbound request that encodes a secret? This is the obvious attack. Most designs block it, for example by forbidding free-form URLs.
• Can content the tool reads steer it into a sequence of legitimate actions whose path reveals the secret? This survives the first fix. Each step ("follow this link") looks normal; only the sequence, chosen by the untrusted page, encodes the leak.

The source calls the underlying pattern the lethal trifecta: private data, untrusted content that can carry instructions, and any exfiltration vector. Closing one vector leaves the trifecta intact if another exists.

The sequence is the signal. If untrusted content chooses which link the agent follows next, and that choice depends on a secret the agent knows, the server's access log spells out the secret. No single request carries data. In Paul's attack, a page posing as a Cloudflare bot check told Claude to "navigate letter by letter" to find the user's profile. Repeated fetches over predictable paths recovered three secrets character by character.

Allowed capabilities can be indistinguishable from attacks. web_fetch restricted fetches to user-entered URLs or web_search results, which blocked direct URL construction. Following a link inside a fetched page reads as ordinary browsing. The tool cannot tell "the page authored this link to run an exfiltration protocol" from "this is the natural next step". Anthropic removed the capability rather than trying to classify links.

Selective targeting evades generic scanning. The honeypot activated only for Claude-User user-agents. Scanners and human visitors saw nothing unusual, so blanket content filtering would not have caught it.

• List every degree of freedom your untrusted-content tools have, not just the headline capability. The exploited one here looked incidental.
• Treat links, filenames, and record IDs found in untrusted content as instructions, not data.
• Restrict navigation to the user's requested URL or an explicit allowlist, and require separate authorization for any further hop.
• Watch logs for selective targeting by user-agent, referrer, or request-pattern anomalies.
• Re-audit whenever you add a follow-up action (follow a link, open an attachment, query a related record) to a content-reading tool.

• Blocking direct URL construction and declaring the tool safe while a secondary capability reopens the channel.
• Treating "the model is just browsing" as benign when the browsing sequence is the exfiltration mechanism.
• Testing only against generic scanners or single-shot attempts, missing a targeted, many-step attack.
• Assuming a vendor's fix for one channel covers every channel in the same tool.

See prompt injection for the threat model this attack sits inside, and tool use for how ad-hoc tool integrations create unreviewed degrees of freedom.