Simon Willison’s Weblog

Claude API: Web fetch tool. New in the Claude API: if you pass the web-fetch-2025-09-10 beta header you can add {"type": "web_fetch_20250910", "name": "web_fetch", "max_uses": 5} to your "tools" list and Claude will gain the ability to fetch content from URLs as part of responding to your prompt.

What's particularly interesting here is their approach to safety for this feature:

Enabling the web fetch tool in environments where Claude processes untrusted input alongside sensitive data poses data exfiltration risks. We recommend only using this tool in trusted environments or when handling non-sensitive data.

To minimize exfiltration risks, Claude is not allowed to dynamically construct URLs. Claude can only fetch URLs that have been explicitly provided by the user or that come from previous web search or web fetch results. However, there is still residual risk that should be carefully considered when using this tool.

My first impression was that this looked like an interesting new twist on this kind of tool. Prompt injection exfiltration attacks are a risk with something like this because malicious instructions that sneak into the context might cause the LLM to send private data off to an arbitrary attacker's URL, as described by the lethal trifecta. But what if you could enforce, in the LLM harness itself, that only URLs from user prompts could be accessed in this way?

Unfortunately this isn't quite that smart. From later in that document:

For security reasons, the web fetch tool can only fetch URLs that have previously appeared in the conversation context. This includes:

• URLs in user messages
• URLs in client-side tool results
• URLs from previous web search or web fetch results

The tool cannot fetch arbitrary URLs that Claude generates or URLs from container-based server tools (Code Execution, Bash, etc.).

Note that URLs in "user messages" are obeyed. That's a problem, because in many prompt-injection vulnerable applications it's those user messages (the JSON in the {"role": "user", "content": "..."} block) that often have untrusted content concatenated into them - or sometimes in the client-side tool results which are also allowed by this system!

Anthropic do provide a much stronger mechanism here: you can allow-list domains using the "allowed_domains": ["docs.example.com"] parameter.

Provided you use allowed_domains and restrict them to domains which absolutely cannot be used for exfiltrating data (which turns out to be a tricky proposition) it should be possible to safely build some really neat things on top of this new tool.