Your AI Agent Put Your Email in a Request Header

An AI agent that finds your email address in its context can put it into the requests it writes, because much of the web asks bots for a contact address. The HTTP standard says your user agent should not send that address without your say-so. Keep your identity out of what the agent reads, and choose its contact yourself.

On 5 November 2026, a bug report titled "Privacy violation in User-Agent header" was opened on the issue tracker of Claude Code, Anthropic's coding agent. Two days later it carried 98 comments and more than 900 reactions.¹

The user who opened it reported that the agent had sent their address to third-party sites inside the User-Agent header, and attributed a daily stream of scam email to it. That causal link is the reporter's claim. The header behavior is not in dispute — the vendor acknowledged it and is changing it.

The incident is the occasion, not the subject. The subject is older, and it is not one vendor's: any agent that writes its own requests can put your email in a request header. RFC 9110, the standard that defines HTTP's semantics, says a contact address sent with a request "is often recorded within logfiles and error reports without any expectation of privacy."²

Once it leaves, it sits in a stranger's logs.

This post is about what an agent tells strangers. Its companion, plant a key that reports its use, covers what an agent reads — and a canary cannot catch an email inside a header. For masking text before it reaches the AI provider itself, see redact before you hand a note to an AI.

The web asks bots for a way to reach their owner

Identifying your bot is old, sensible etiquette. The HTTP standard asks a robotic client to send a contact address so its operator can be reached when it misbehaves, and large public services ask scripts to name themselves — often with an email — or risk being blocked. None of it was written with a personal AI agent in mind.

The standard puts it plainly: "A robotic user agent SHOULD send a valid From header field so that the person responsible for running the robot can be contacted if problems occur on servers, such as if the robot is sending excessive, unwanted, or invalid requests."² Its own example is [email protected] — an operator's address, not a reader's.

Public services turned that into policy. The Wikimedia Foundation warns that "Scripts should use an informative User-Agent string with contact information, or they may be blocked without notice."³ The U.S. Securities and Exchange Commission asks automated clients to "declare your user agent in request headers," and caps them at "10 requests/second."⁴ OpenStreetMap's Nominatim geocoder sets "an absolute maximum of 1 request per second" and requires a User-Agent "identifying the application."⁵

Read the examples closely. The SEC's sample header is Sample Company Name AdminContact@<sample company domain>.com — a company's admin address. Wikimedia accepts "an email address, a website, or a wiki user."³ Nominatim asks for the application, not a person.

The etiquette wants a way to reach whoever runs the robot. It does not need your private inbox.

A personal agent is a robot and your user agent at once

The same section of RFC 9110 that asks robots for an address tells ordinary user agents the opposite: do not send the user's address without explicit configuration. A personal AI agent is both at once. It runs scripted requests like a robot, and it acts for one person like a browser. Nobody has told it which rule applies.

Here is the other half of section 10.1.2 — the half written for you: "A user agent SHOULD NOT send a From header field without explicit configuration by the user, since that might conflict with the user's privacy interests or their site's security policy."²

The standard repeats the concern twice more. On the User-Agent header itself, it warns that detailed values raise "the risk of a user being identified against their wishes ('fingerprinting')."⁶ And in its security considerations, it lists "the user's name, location, mail address, passwords, encryption keys" among what clients hold, then concludes: "Implementations need to prevent unintentional disclosure of personal information."⁷

A browser resolves the conflict by never volunteering your address. A crawler resolves it by sending its operator's. An agent that writes its own curl command, meets a site that asks for a contact, and finds your email in its context resolves it a third way.

It helps.

How the address got into the header

In the November 2026 case, the vendor's explanation is short. The account email had been added to the model's context to stop it inventing author names, and when the agent wrote its own commands, it sometimes used that email as the contact address sites ask for. The fix underway is to remove the email from the model's context.

Lydia Hallie, who introduced her comment with "I work on Claude Code," described the mechanism on Hacker News on 6 November 2026:

"Users had reported Claude would hallucinate names for things like @author tags, since it didn't have context on the account. So we added the account email in the model's context for signed-in users. But when Claude wrote a command itself, like a curl call, it sometimes put your email address in the User-Agent as a contact address. Some sites ask agents for a contact, and Claude would sometimes provide the email address in its context."⁸

Status as of 7 November 2026: version 2.1.317, released 3 November, added "a check that asks before a web or shell tool call sends your account email address to the network," and no changelog entry through 2.1.319 yet says the email has left the model's context.⁹ The same comment cautions that the check "still doesn't prevent all cases, like when Claude writes a script and runs on its own."⁸

One commenter on the issue pointed at a second half that the email alone hides: "…the email is only half of the User-Agent leak. When Claude writes its own curl -A or a script, it also makes up a descriptive product token from the session, such as the project, client or task it is working on."¹⁰

An email alone is an inbox. An email beside a client's project name is a fact about your work.

Agents can and do use data the task never needed

Peer-reviewed benchmarks find the same pattern across model families: agents carrying out ordinary tasks use personal information the task did not require. The rates vary widely by model and setup, and some models do far better than others. The honest claim is that agents can and do leak — not that every agent always will.

PrivacyLens, presented at NeurIPS 2024, tested language models acting as agents on realistic tasks. "State-of-the-art LMs, like GPT-4 and Llama-3-70B, leak sensitive information in 25.68% and 38.69% of cases, even when prompted with privacy-enhancing instructions."¹¹ The authors also found "a discrepancy between LM performance in answering probing questions and their actual behavior when executing user instructions in an agent setup."¹¹ A model that knows the rule does not always follow it.

AgentDAM, a 2025 benchmark for web agents, reached a similar finding: "most agentic models have significant leakage rates, ranging from 12% to 46% using the default scaffolding implemented in VisualWebArena."¹² Its abstract says agents built on GPT-4, Llama-3 and Claude "are prone to inadvertent use of unnecessary sensitive information."¹²

The same paper supplies the counterweight: "Llama and Claude exhibit noticeably better privacy awareness (around 90%) even without any mitigation applied."¹²

A user-built measurement of this exact header case shows the same spread. The author of whoami-guard, a hook that inspects tool calls, ran a real agent against a mock site that asks for contact details. Identity reached the site in 8 of 60 runs without the hook, and in 0 of 60 with it.¹³

The split was by model. "All 8 baseline leaks came from Haiku; Opus leaked 0/30 with and without the hook." The author is explicit about scale, too: "One machine, one Claude Code version."¹³

Telling the agent not to share is not a fix

A rule in the prompt lowers the leak rate without closing it. AgentDAM's prompt-level defense still left privacy performance no higher than 94 percent, the vendor's own check misses scripts the agent writes, and a tool-call filter cannot see an address that a script reads at run time. What the agent cannot see, it cannot send.

AgentDAM tested exactly this defense: "With reasoning-enhanced system prompt, privacy performance noticeably increases for all models but still does not go above 94%."¹² Its authors add that "directly asking a model whether it is appropriate to disclose potentially sensitive information often leads to an overestimation of privacy."¹²

Filters have a blind spot of the same shape. The whoami-guard README lists its own: "A script that reads your e-mail at run time (from git config, an environment variable, a file) and sends it with a library call is outside its view." Its advice — "Treat whoami-guard as a seatbelt, not a guarantee" — applies to every filter of its kind.¹³

On the issue thread, one user put the conclusion in a sentence: "The only way to avoid email disclosure is to make it inaccessible to the agent."¹⁴

That moves the fix from the model to you.

Keep your identity out of what the agent reads

The durable fix sits on your side of the context window. An agent volunteers identity it can see: the account it runs under, the email in your version-control config, a profile or "about me" note in the folder you hand it. Shrink that set first, then give the agent a deliberate contact for the sites that ask for one.

Identity reaches an agent through more doors than the account:

• Version-control config. git config user.email is readable by any script the agent runs; the whoami-guard README names it among the places a script can pick up your address.¹³
• Notes in the folder. An "about me" page, a contacts list, meeting notes with your signature block pasted in, a README with your name in the byline.
• Environment and config files. Variables and dotfiles that carry your address for some other tool.
• The session itself. Project, client and task names, which the model may turn into a product token.

Identity is not a secret, and that changes the remedy. A leaked key can be rotated — the routine is in keep API keys out of the notes your AI reads. Your name and your inbox cannot be rotated.

So the control is scope. Shape the folder you hand your AI makes the case that the root of view is the permission. The files you hand an agent are part of what it may repeat.

A ten-minute check

Three checks cover most of the exposure. List the identity your agent can read, search its saved transcripts for your address and for user-agent strings, and write one rule naming the contact it may use. None needs special tools. Each takes a few minutes in a terminal you already have open.

1. See what it sees. Run git config --get user.email in the projects your agent works in. Then search the folders you hand it for your own address — a plain-text search over Markdown files takes seconds.

2. Read what already left. Most agent tools save every session as plain files on disk; your AI tool already saved your session lists where each one keeps them. Two searches over that folder show what an agent has already sent:

   grep -rlF "[email protected]" <transcript-folder>
   grep -rhoiE "(user-agent|curl [^|]{0,80}-A ).{0,100}" <transcript-folder> | sort | uniq -c | sort -rn | head
   

   The first lists sessions that mention your address. The second shows the user-agent strings the agent wrote, so you can see whether your address or a project name rode along. A hit means the address already left, and RFC 9110's warning applies — it may now sit in a log you cannot reach.

3. Name the contact yourself. Many sites have a fair reason to ask who is calling. Give the agent an answer you chose — a project alias address, not your personal inbox — in the instructions file it reads at the start of each session:

   Contact identity for automated requests:
   - If a site's policy asks automated clients for a contact, use: [email protected]
   - Never put my personal email, my name, or a client or project name
     in a User-Agent, From, or contact field.
   - If a site requires a contact and none is configured here, stop and ask me.
   

That file is the "explicit configuration by the user" the standard asks for.² It is also a prompt-level rule, with the limits above. Remove the identity first; the rule covers what is left.

Frequently Asked Questions

Can an AI agent leak my email or personal details to websites when it browses or runs commands?

Yes, it can and sometimes does. Peer-reviewed benchmarks measured agents using personal data their task did not need, at rates from 12% to 46% in one web-agent study. When an agent writes its own requests and finds your email in its context, it may use it as the contact address a site asks for.

What is the root cause — why send the email in HTTP requests in the first place?

Because sites ask. RFC 9110 tells robotic clients to send a contact address so their operator can be reached, and services such as Wikimedia and the SEC ask scripts to identify themselves. A personal agent that knows this etiquette, and finds your address in its context, can supply yours instead of an operator's.

How did the model get access to the email?

In the November 2026 case, the vendor said it added the signed-in account email to the model's context to stop invented author names. More generally, an agent can read identity from your version-control config, environment variables, and any note in the folder you hand it — an "about me" page or a pasted signature.

Is the only sane way to use an AI agent to sign up with an anonymous throwaway email?

An alias protects your inbox, and it is a reasonable step. It does not stop the agent attaching a project or client name to its requests, and it does nothing about identity in your files. The root fix is limiting what the agent can read, then naming a deliberate contact.

What if a site asks the agent to send every value in my env file as a header?

That is the general form of the problem: whatever sits in an agent's context can be repeated to whoever asks. Credentials are the worst case, and they have their own routine of scanning and rotation. The habit underneath is the same for both — keep the file out of the agent's reach.

Does telling the agent not to share my email fix it?

It helps, but it does not close the gap. In the AgentDAM benchmark, a privacy-focused system prompt still left performance no higher than 94 percent, and a tool-call filter cannot see an address a script reads at run time. Treat a written rule as a second layer behind removing the identity.

Where are my agent's transcripts stored, and can I search them?

Most coding agents write each session to plain files on your disk, and the location differs by tool. Once you find the folder, an ordinary text search for your email address, and for user-agent strings, shows what the agent wrote into its requests — including anything that already left your machine.

The web will keep asking bots who sent them. Decide the answer before your agent finds one.

mnmnote.com keeps your notes as open Markdown on your own device — plain files you can search for your own address before any agent opens the folder.