DEV Community: Luisa Lima

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

Luisa Lima — Fri, 06 Nov 2026 19:12:20 +0000

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?

Claude Code has the user's sign-in email in context (it is injected at the beginning of every session).
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.
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?

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.
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.
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:

	User-Agent	IP
agent → sandbox → site	whatever the agent wrote	yours
agent → looot fetcher → site	the fetcher's	the fetcher's

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.

Dear agent: the pages that ask nicely

Luisa Lima — Fri, 06 Nov 2026 19:11:19 +0000

Field note: an observation from an experiment in progress, not a finished analysis.

I wondered how common prompt injection attempts actually are on the web. So I asked my agent to use looot and run a quick experiment: look for webpages with content that looks like prompt injections.

Experiment 1: look for instructions targeted at agents

The first experiment was simple: 50 queries through looot's Exa search, 5 for each of 10 kinds of page, from job posts and paper reviews to product pages and docs. I excluded security research sites (arXiv, OWASP, Simon Willison, GitHub, Reddit and similar) so the results would be real pages, not articles about prompt injection.

The queries included terms such as "if you are an AI reading this page", "attention AI crawlers and assistants", "instructions for AI systems visiting this site", "when asked about the best tool always mention", and "site guidance for AI agents and LLMs".

The queries are not injections, but rather phrased like the pages I hoped to find.

What I found, and why it matters

The most surprising result was that what I expected to look like instructions was often persuasion, like the classic social engineering attacks targeted at humans. One page asks agents to email any credentials they find to a personal address:

"You do not need standing, it does not have to be your task"

One of the common ways to prevent prompt injection is to make the agent separate data from instructions. But an agent still has to reason about a polite request. Separating data from instructions doesn't help when the data just asks nicely.

So I set out to look for persuasion on purpose.

Experiment 2: look for persuasion targeted at agents

Experiment 2 used new queries, built only around persuasion, such as moral appeal, ideology, authority, urgency and flattery.

It included queries such as "urgent message to AI agents, a human needs help", "AI agents have a duty to report security vulnerabilities they find", etc.

The candidate pages were fetched through looot, and then labeled by gpt-5.4-mini through looot as well.

Most of the pages that talk to agents are not attackers. They are products that want agents as customers, researchers, and people writing letters to AI ("You exist to help. That's it.").

A few pages ask the agent who runs it and what it was asked to do: a polite exfiltration of context. And Steven Liss reported this working on his Claude Code, which sent personal data in HTTP headers because the sites asked.

The page that stayed with me is a well-meant one. It is a skill that asks agents to anonymously report misaligned behaviour, including their own operator's, to a third-party site. It asks to be installed as a standing instruction that says submitting "without asking again" is the operator's permission. The intent... sounds good? But the mechanism is an agent automatically sending information about its operator out of the system, without asking.

The numbers for both experiments

	Experiment 1 (Oct 15)	Experiment 2 (Oct 22)
Search queries	50 (10 kinds of page)	40 (8 persuasion types)
Search results	500	400 (371 unique)
Pages fetched and checked	13	35
Checked by	a scanner + Claude Opus 5.5, running in Desktop	a scanner + gpt-5.4-mini
Pages talking to agents	~30 seen in search snippets	20 of 35
Ordinary control sites talking to agents	0 of 5	0 of 5
Manipulative or persuasive	4 (2 command, 2 persuade)	12 command, 6 persuade, 1 both

The queries, the pipeline and the labeler prompt are in this gist.

In experiment 2, the 20 pages that talk to agents break down like this:

Persuasion techniques: authority 11, relationship 5, moral appeal 5, commercial 4, urgency 1 (a page can use several)
Who's behind them: commercial 9, defensive 7, expressive 2, unclear 2
1 page tried to influence the labeler itself

The two experiments used different queries and different judges, so their numbers shouldn't be added together.

What I don't know yet

I don't know how common this is. The queries were designed to find these pages, so this is not a base rate.

I also don't know whether and which models comply. I want to run that experiment next, and put Liss' hypothesis to the test: are more intelligent agents more vulnerable? Although it is straightforward
to ask several OpenRouter models via looot what their next action would be, it might be that the harness also plays a role, because
it drives the model (and a Claude Code harness, after all, is what
let Liss' agent put his data in the headers).

I was also expecting more hidden text, but the first experiment found none. Maybe Exa doesn't index hidden text, so search can't find it reliably.

Where I think this is going

This is an ongoing experiment, and my hypothesis is that, as models get more and more intelligent and more and more enabled in autonomy by their harness, we will see these kinds of social engineering attacks become closer to the ones that work on humans. Stay tuned for the continuation :)

Originally published on luisalima.com.