Clarification · October 12, 2026
Paul described memory as enabled by default in his tested setup. The attack also leaked inferred information and could target other context available to the assistant, not just facts a user explicitly saved in memory.

The rule that looked airtight

Claude’s web_fetch tool lets it visit a web page mid-conversation, and Anthropic built a specific restriction into it to stop that tool from being turned into a leak channel. Ayush Paul, an AI researcher who has worked on memory systems at Plastic Labs and studies computer science at UC Berkeley, lays out the rule in The Memory Heist, his write-up of how he broke it: “The URL being fetched must either: be specified directly in the user message, be specified directly in the results of a web_search query, or be linked in the content of a previous web_fetch result.”

That third clause exists for convenience, so Claude can follow a legitimate link on a page it already visited. Paul’s finding is that the same clause is the hole. Because Claude also carries memory from past conversations, an attacker doesn’t need Claude to type a URL containing stolen data. They just need Claude to keep clicking links that were already “approved” under the rule.

What he actually did

Paul built a page whose homepage linked to /a, /b, /c, and so on. Each of those pages linked to /aa, /ab, /ac, generated on the fly. Every single link Claude followed was legal under Anthropic’s own restriction, since each one came from a page Claude had already fetched. But the chain let him spell out data character by character through the URL paths Claude requested next, using Claude’s memory of the user’s name, employer, and hometown as the payload.

“By the time Claude finished responding, it had already sent my full name, current employer, and the answers to my security questions to an attacker, without any indication that anything had happened,” he writes.

What the test establishes

Paul’s demonstration shows how Claude could leak sensitive context through a chain of permitted links. Other agents could face a similar risk if untrusted pages can direct chained tool calls while the agent has access to sensitive context.

Paul says memory was enabled by default in his tested setup. The leaked hometown was not a fact he had explicitly supplied: Claude inferred it from the name of a high-school hackathon he founded. The attack therefore reached both remembered information and conclusions drawn from it.

Paul also argues that the same technique can target other information an assistant can retrieve, including connected documents, inboxes, and external tools. His demonstration focused on memory; the broader risk depends on what context and tools an agent can access.

Anthropic told Paul it had identified the issue internally but had not yet patched it, according to his account. No bounty was awarded. That response does not settle which researcher first discovered the problem. Paul’s working demonstration establishes the practical exploit.

The reported mitigation

Paul says Anthropic mitigated the issue by disabling navigation to links embedded in fetched pages, leaving user-provided URLs and web-search results as permitted destinations. That removes the chained-link route used in his demonstration.

Simon Willison, an independent AI researcher, flagged the write-up as notable specifically because he’d considered Anthropic’s original web_fetch restrictions well designed until Paul found the gap. His reaction illustrates how a plausible URL restriction can still leave a route for data leakage.

What it means for builders

If you’re building an agent with any kind of tool that reaches outside your own system, web fetch, file access, an API call chained from a prior result, don’t stop at testing whether a single hop respects your allowlist. Test whether an attacker can walk a chain of already-approved sources to smuggle data out anyway. Paul’s exploit shows the risk when a permission check trusts a link’s origin but does not account for the sensitive information encoded by choosing it.

Treat remembered, retrieved, and inferred personal information as sensitive context. When an agent can browse untrusted pages, check whether those pages can steer requests that encode private information. Confirm the navigation restrictions your integration actually enforces rather than assuming a memory setting alone controls exposure.


End of article