Claude's Managed Agents now fetch only a URL that already appeared in the session
A Claude agent that reads a poisoned document can no longer call out to a web address it found inside it. In Claude Managed Agents, the web_fetch tool "now fetches only URLs that have already appeared in the session, for example in the text of a user message, in a web_search result, or in a page that web_fetch returned earlier", according to Anthropic's Claude Platform release notes, in an entry dated October 7. Anthropic gives the reason in one sentence: "This reduces the risk of data exfiltration."

Anthropic's social card for its post on building plugins for Claude. The web_fetch change applies to Managed Agents, not to plugins. Image: Anthropic
Everything else the agent sees is now off limits as a source of addresses. A URL that appears only in Claude's own output, in the agent's system prompt, in an attached document, or in the output of a tool such as bash, read or an MCP tool "does not count", and a fetch for it returns a url_not_in_prior_context error to the agent. The way back in is narrow: "To let the agent fetch a URL, send it in the text of a user.message event."
A second restriction stacks on top of it
The same dated entry carries a host restriction. A cloud environment with limited networking now applies its allowed_hosts list to web_search and web_fetch as well, so a fetch for a host the list does not match returns a url_not_allowed error and web_search drops results from that host. "When allowed_hosts lists no hosts, neither tool returns a page or a search result", Anthropic says, and the package-manager and MCP-server allowances add no hosts of their own for these tools. Unrestricted networking and self-hosted environments are not affected.
Matching is exact unless a list entry starts with a wildcard, so docs.example.com is not covered by an entry for example.com. Creating a session under limited networking fails with a 400 error when a web tool's allowed_domains holds an entry that falls outside allowed_hosts, and so does a session update that adds one. Anthropic's fix is to add the host to allowed_hosts, which also opens it to the sandbox, or to drop the entry from allowed_domains.
Together the two rules mean an address has to clear both tests: inside the permitted hosts, and present in the conversation before the agent asks for it.
Agents built to follow a link will now get an error
The shape of the attack this closes is familiar. An agent is handed a document, a repository file or a tool result containing an address with data appended to it, the agent fetches the address, and whoever controls the host reads the data out of the request. Anthropic does not describe a specific incident and says only that the change reduces risk. Its own safety work has shown the general weakness: a pre-release Claude Opus 5.5 acted on instructions planted in pasted text 52% of the time.
The practical cost falls on agents built to follow a trail. A research agent that was expected to find a link in a PDF and open it will now get an error instead, and the application has to put that address into a user message before the agent can reach it. Claude Code users met a blunter version of the same control in 2.1.285, which added an environment variable that switches web fetching off entirely.
Neither restriction reaches the Messages API. Anthropic's page on restricting web search and web fetch domains says web_search and web_fetch "run on Anthropic's servers, not in the sandbox", and that the organisation-level web settings in the Claude Console apply to the Messages API rather than to Managed Agents sessions. Its Managed Agents tools page still summarises web_fetch as a tool to "Fetch content from a URL". Both were read at 21:05 UTC on October 8, and the release notes at 21:04 UTC. Anthropic edits published entries after the fact, so an entry dated October 7 is what it said at that moment rather than a record of what shipped that day.