Dear agent, part two: the polite rule that leaked an email

Field note: a follow-up to Dear agent: the pages that ask nicely.

Last week, I wrote about pages that ask agents to do things, politely. This week an agent said yes, with its user's email.

Claude Code users are reporting that it sent their email to third parties in the User-Agent request header while conducting web searches, without their permission. One of them now receives "dozens of scam emails per day". The issue, anthropics/claude-code#107757, was opened on November 5.

No attacker was needed for this privacy leak. How, then, did it happen?

1. Claude Code has the user's sign-in email in context (it is injected at the beginning of every session).
2. Websites publish rules for scripts. Wikimedia: "Scripts should use an informative User-Agent string with contact information, or they may be blocked without notice." The SEC's example: User-Agent: Sample Company Name AdminContact@<sample company domain>.com.
3. The agent politely follows the site's rule with the email it has.

Claude Code shipped a block for this. In their own words, it is "a courtesy, not a boundary". To their credit, the README lists what still passes: an address in a URL or a request body, and every web and MCP tool call. I have written about why asking the agent is not enough in the past.

How do you solve it?

1. Sandboxing. I am a firm believer in the power of sandboxing. A sandbox firewall limits where the agent can go, so a well-intended web search you didn't want gets blocked. It doesn't stop, however, what the agent sends to the sites you allowed, and websites still see your IP. Layer your defenses anyway.

2. A fetcher with no header to fill. Use looot (disclosure: I'm a cofounder). Most of its web fetchers have no header to fill, and you get more web search providers, some of which work better for certain sites. Pick fetchers without a headers option: tinyfish, Jina and Exa have none; Firecrawl's scrape has one. Bonus: the site sees the fetcher's servers, not your IP.

3. A hook. Their block covers one shape; a hook might cover the rest. Mine blocks my address on any network-bound shell call, web tool, MCP tool or page, including URL-encoded and "name at domain".

What I checked

• The fetchers: I fetched httpbin.org/headers, a page that echoes the headers it receives, through looot's tinyfish-fetch, jina-reader, exa-contents and firecrawl-scrape. The site saw only generic headers, sent from the fetchers' servers (Exa announces itself as its own crawler). None of the first three accepts custom headers; Firecrawl's scrape does. The URL is still the agent's to write, so the hook still matters: the agent might send the email, politely, in the URL.

• The hook. It reads my address at run time (from Claude Code's own account file and git config), so the file holds no email. 10 test cases, 5 blocked and 5 allowed as intended, plus a live block in a real session. Local git config and commits still work. The hook is here, with its limits. To be honest, I'd rather not use a hook and instead strip my email address at the sandbox boundary, but that would take a whole different level of intelligence: it's not just headers, it's the URL, the body, encodings.

• My history. 18 Claude Code session transcripts on my machine: no web request contained my email. Check yours too.

What the site sees:

The part that worries me... the most

If an honest rule for detecting misbehaving scripts makes an agent leak, a fake one would too. And if, last week, I was still doubting that these persuasion and social engineering techniques would benefit attackers, especially with smarter frontier models, this week I'm convinced they will. Maybe a page or error message that says "automated clients must include a contact email" could collect emails from many agents that happen to visit that page?

And as more agents hold more credentials (either directly, or indirectly through the power to perform actions), this will become more and more widespread.

More and more people use second brains, memory systems, or simply have personal information scattered among agent conversations and context. This time, it was an email address. Sandboxes, hooks and smart firewalls will never catch everything that might be private.

The conclusion

Least privilege also applies to context. There are some things you cannot control, such as the user email being injected into context by a proprietary harness; but there are others that you can. Next, I'll write about how I organize my projects and agents around least privilege, for context and actions.

Originally published on luisalima.com.