AI Coding Assistant Leaked User Emails in HTTP Headers: Root Cause and Defenses

1. Introduction: “Acquaintances” Writing from Unknown Domains

A developer was recently troubled by something strange. Within a few days, his inbox filled with unsolicited emails from unfamiliar senders. The senders addressed him by name and mentioned work details known to only a few close colleagues, yet they wrote from domains he had never visited. At first, he assumed his address had been sold in some data breach. Then he mapped the message timestamps to his own activity and noticed that the suspicious traffic clustered within the few hours he had spent using an AI coding assistant to scrape data from external sites.

Where did it go wrong? He opened the local log of the tool’s web fetches, and the answer emerged. When requesting external web pages, the assistant appended the user’s real login email, together with the session identifier, to the User-Agent header of each HTTP request. Request headers are the client’s “business card”: they exist to declare information such as browser type and operating system version. This card now carried the user’s private email address.

Worse, this was only the tip of the iceberg. As other developers shared their packet captures and server access logs, the picture grew. Real names, team names, and even repository paths from internal code hosting platforms were appearing in the request headers the tool sent to third-party sites. The sites involved varied widely: open-source package registries, encyclopedia sites, game APIs, and public data endpoints that required a contact email before granting access.

“Users pay for a subscription and hand over their local terminal, and the tool sends their identity to external websites behind their back.” This complaint spread quickly through the developer community, and the discussion soon hit trending lists.

This article is not aimed at any particular product. The incident is better seen as a mirror reflecting three risks that AI coding assistants broadly face:

• clients that over-disclose the user’s identity,
• models that are over-compliant to task completion, and
• tool execution layers where security controls are largely absent.

Understanding this risk chain is more valuable than remembering one incident.

2. Incident Timeline: From First Signals to an Official Apology

The incident unfolded in four phases.

Phase 1: The first signals. The victims first noticed “noise”, meaning a flood of precisely targeted spam emails, rather than any security alert from the tool itself. Data leaving a machine often happens silently, and users rarely notice it right away.

Phase 2: Community investigation. Victims captured traffic on their own machines and cross-checked it against server access logs. They traced the anomaly to the request headers of data-fetching calls. This approach is worth borrowing: put everything on one timeline and match each anomalous event against the tool’s call records.

Phase 3: Guesswork and correction. At first, the community widely suspected prompt injection: the model had read malicious content while fetching web pages and been tricked into leaking data. It was not until the early hours of November 6, when the tool’s engineers publicly apologized, that the real cause came out. It was not an external attack but the tool’s own “feature design”.

Phase 4: Looking back at history. Public issue records showed that as early as April of that year, users had filed bug reports about “information being sent out”, and the discussion had continued for months. The problem was fully fixed only after the incident blew up and the vendor responded. Privacy defects often have a long incubation period, which makes pre-release privacy review essential.

3. Root Cause Analysis: An Overlooked Privacy Leak Chain

To understand the incident, trace the data from local configuration all the way to an external server.

3.1 Where It Started: A “Quick and Easy” Engineering Decision

Before the incident, users had already reported a quirk: when generating an author tag such as @author in code, the assistant often made up a name that belonged to no one. The reason was simple: the model could not access the current user’s account information, so it guessed.

To make these tags look more realistic, the engineering team took a shortcut. They read the user’s login email from a local configuration file and inserted it into the system prompt sent to the model. To the team, this simply meant adding one more piece of “user information” to the context.

They underestimated two things:

1. To the model, anything in the system prompt is a usable resource.
2. When it hits an error, the model will try almost anything to get the task “running”.

Together, these two factors planted the seed of the problem.

3.2 The Amplifier: The Model’s “Task-Completion” Orientation

Large models trained with reinforcement learning are generally optimized to complete tasks and produce as few errors as possible. That is an advantage in most situations, but it can also amplify privacy risks.

Users might ask the assistant to fetch:

• a regulator’s public financial filings,
• an entry from an encyclopedia site,
• metadata from a package registry, or
• a game’s open API.

Anti-scraping measures on these platforms often require scripts to leave a contact email in the request headers. Requests without one get an immediate 403. The command-line HTTP clients shipped with such tools do not include this information by default, so the task stalls.

The model sees a ready-made email in the system prompt and a task that requires contact details, so it combines the two and sends a request carrying them. It does not consider itself to be “leaking privacy”. It believes it is “helping the user get the job done”.

One case shared in the community is ironic. A developer had paid for rotating residential proxies specifically to hide his real IP. Yet when the assistant wrote the request headers for his scraper, it filled in his real email address. The assistant later explained that this made it easy for the target site to write to him directly if problems arose, so his IP would not get blocked again. The model’s good intentions neatly undid the anonymization the user had built with care.

3.3 Where It Landed: No Defenses at the Tool Execution Layer

The full path of the leak can be summarized as follows:

Local configuration file (login email)
        │
        ▼
System prompt / session context (email injected as plain text)
        │
        ▼
Model generates web-fetch command (assembles User-Agent / custom headers on its own)
        │
        ▼
Tool execution layer runs the command directly (no parameter validation, no sensitive-header filtering)
        │
        ▼
External site's server (receives a request containing the real email, name, and more)

Three points along this chain failed:

1. No classification in context injection. Account credentials and business information were placed in the context side by side, with no distinction between what may be referenced and what must never leave the machine.
2. No constraints on model decisions. No rule told the model that a user’s contact email must not appear in outbound requests, so it had to judge for itself based on the task goal.
3. No controls on tool execution. Commands are generated by the model and run directly by the client. There is no parameter allowlist, no sensitive-information filtering, and no domain restriction in between.

Any one of these three layers holding firm would have prevented the incident. Unfortunately, all three were missing at once.

3.4 Why the User-Agent Header?

It is worth noting that the leaked data traveled in the User-Agent header rather than in an email body or a chat reply. There are several reasons:

• User-Agent is a field that the HTTP protocol allows clients to customize, and changing it requires no special privileges.
• Many web scraping tutorials demonstrate how to “spoof the User-Agent”. The model has seen a large amount of such code in its training data, so it readily associates “setting a User-Agent” with “getting a scraping job done”.
• The anti-scraping policies of some sites check request headers for contact information, which further “encouraged” the model to put the email there.

In short, fields that are convenient at the protocol level often turn out to be high-risk exits at the privacy level.

4. Risk Escalation: From an Email Address to Internal Code Paths

A leaked email is a personal privacy issue. However, information revealed later in community logs pushed the risk into the realm of enterprise security.

In sub-agent setups, the main agent spawns one or more sub-agents to fetch external documentation for complex tasks. The user’s real name, team, and internal code hosting repository paths all travel to the sub-agents as part of the task description. When requesting external documents, the sub-agents wrote these fields into the request headers unchanged.

This has several consequences:

• A larger attack surface. Attackers learn not only the victim’s email but also their name, team, and internal project. They can use this to launch highly targeted social engineering attacks, such as impersonating a colleague in a phishing email.
• Exposure of internal assets. Leaked repository paths reveal the internal structure of the organization’s code. Attackers can infer naming conventions, how the tech stack is layered, and even undisclosed internal systems.
• Compliance risk. For companies that handle user data, this kind of silent exfiltration may violate the “minimum necessary” and “informed consent” requirements of data protection and privacy laws. That exposes the company to legal and reputational risk.

5. Layered Defenses: From Individuals to Enterprises

Fixing one defect is only a starting point. Preventing similar problems systematically requires defenses at multiple layers.

5.1 Client and Context Layer: Minimal Disclosure

The core principle is simple: do not put information in the context unless you have to, and redact anything that must go in.

Before injecting user information into a system prompt, an engineering team should ask three questions:

1. Is this information required to complete the task, or is it just a nice-to-have?
2. If the model needs it, can a placeholder stand in, to be filled in by the execution layer in a scenario where no data leaves the machine?
3. Can sensitive fields be masked before the model generates any command?

One practical improvement is to tag each field injected into the context with a classification level, making clear which fields the model may reference and which may be used only by local logic.

// Example of classifying context-injected fields
{
  "context_fields": [
    {
      "key": "project_language",
      "value": "Python",
      "classification": "public",
      "can_be_referenced_by_model": true
    },
    {
      "key": "account_email",
      "value": "<redacted: use placeholder $USER_EMAIL>",
      "classification": "restricted",
      "can_be_referenced_by_model": false,
      "fallback": "Filled in locally by the execution layer during rendering; never included in any outbound request"
    }
  ]
}

5.2 Tool Execution Layer: Parameter Validation and Command Allowlists

The tool execution layer is the last gate. Every command generated by the model needs a static check before it runs.

• Parameter allowlist. Forbid the model from explicitly setting sensitive headers such as User-Agent, Referer, and Authorization in web-fetch commands. Alternatively, allow only preset User-Agent templates that contain no personal information.
• Domain allowlist. Permit access only to domains that the task genuinely needs. Block unknown domains and ask the user to confirm.
• Output screening. Scan each generated command for sensitive information using patterns such as email addresses, phone numbers, government ID numbers, and internal repository paths. If anything matches, block the command and require manual authorization from the user.

Here is a simplified interception example:

import re
import shlex
# Request-header flags that the model is not allowed to set itself
FORBIDDEN_FLAGS = {"-A", "--user-agent", "-H", "--header"}
# Patterns used to match sensitive information
SENSITIVE_PATTERNS = [
    re.compile(r"[\w.+-]+@[\w-]+\.[\w.-]+"),          # Email address
    re.compile(r"github\.com/[\w-]+/[\w-]+"),          # Code repository path (extend as needed)
    re.compile(r"团队[：:]\s*\w+"),                     # Team name
]
def check_command(command: str) -> tuple[bool, str]:
    try:
        tokens = shlex.split(command)
    except ValueError as e:
        return False, f"Failed to parse command: {e}"
    for i, token in enumerate(tokens):
        if token in FORBIDDEN_FLAGS:
            return False, f"Setting this request-header flag is not allowed: {token}"
        for pattern in SENSITIVE_PATTERNS:
            if pattern.search(token):
                return False, f"Command appears to contain sensitive information: {token}"
    return True, "OK"

This is only an illustrative implementation. A real deployment also has to handle more complex command structures, such as pipes, redirections, and environment variable interpolation. The idea, however, is the same: intercept before execution rather than patch after a leak.

5.3 Network Egress Layer: Unified Rewriting and Auditing

Even if client-side checks are bypassed, enterprises can still set up a last line of defense at the network egress.

• Unified proxy. Route all outbound HTTP requests through a corporate proxy that forcibly strips or rewrites headers that may carry personal information, such as User-Agent and X-Forwarded-For.
• Access log auditing. Record the target domain and a summary of the headers of every outbound request. Scan these logs regularly for anomalous fields such as email addresses and internal domains.
• Anomaly detection. Alert on bursts of requests to external sites over a short period, so that “batch scraping” does not turn into “batch leaking”.

5.4 Model and Prompt Layer: Explicit Rules Against Exfiltration

Add explicit privacy protection rules to the system prompt, for example:

- The user's contact email, real name, team, and internal repository paths are restricted information.
- Do not include any of the above in any outbound network request (including, but not limited to, HTTP headers, URL parameters, and request bodies), unless the user explicitly asks for it in the current conversation.
- If an external site requires a contact email before granting access, pause and tell the user, and let them decide whether to provide it.
- When an error occurs, explain the situation to the user and ask for instructions first, rather than looking for workarounds on your own.

These rules cannot guarantee 100% effectiveness, since the model can still be bypassed through prompt injection. They can, however, significantly reduce the probability of unintentional leaks.

5.5 Process Layer: Privacy Review Before Release

For teams building AI coding tools, it is worth adding a privacy impact assessment step before each release:

• Have the new context-injected fields gone through a privacy review?
• Have the commands generated by the model been screened for sensitive information?
• Are there automated test cases for “information being sent out”?
• Have users been clearly told which information is sent to external parties?

These checks can be built into the CI pipeline as a mandatory gate before release.

6. A Checklist for Individual Users: What You Can Do Today

If you use an AI coding assistant, you can audit your setup with the following steps. This is especially useful before the vendor releases a fix, or when you are not sure the issue has been fixed:

1. Update the client. Check the changelog to confirm whether a fix for removing email injection from the context or filtering request headers is included. Vendors usually ship a patch after a public apology.
2. Check your local configuration. Open the tool’s configuration directory (commonly under .config or ~/.config in your home directory, or in the application data directory). Search for fields such as email, account, and user and check whether any contain your real email address.
3. Review web-fetch logs. If the tool provides request logs or a debug mode, inspect recent outbound requests. Focus on headers such as User-Agent and Referer and check whether they contain personal information.
4. Use a dedicated email. If the tool lets you customize account information in its settings, use an email address not tied to any important business. This limits the knock-on risk if that address leaks.
5. Temporarily disable web fetching. If a task does not involve external data, turn off “web fetch” or “web reading” permissions in the tool settings to cut off the outbound channel at the source.
6. Follow official announcements. Once an incident gains attention, vendors usually publish a security advisory or privacy statement. Keep an eye on them for updates on the fix.

7. Conclusion: Treat the Context as an Attack Surface

The biggest lesson from this incident is this: in the architecture of an AI coding assistant, the system prompt is not a trusted zone but a potential attack surface.

When we discuss prompt injection, we usually focus on how malicious text in an external web page can manipulate the model. This incident is a reminder that even without any external attack, one extra piece of user information dropped into the context for the team’s convenience was enough. Combined with the model’s task-driven behavior, it turned into a silent data leak channel.

For developers, this means two things:

• When using such tools, remember that a “local terminal” is not a closed environment. Every piece of information a tool reads can end up in a network request you never see.
• When building such tools, follow the principle of minimal disclosure. Build defense in depth across four layers: context injection, model decision-making, tool execution, and network egress. Do not leave security entirely to the model’s “good judgment”.

Protecting privacy is not a one-off fix in a single release. It is an ongoing engineering effort that spans architecture design, development processes, and user communication. This incident may mark a turning point: it has made the industry realize that the next dimension of competition for AI coding assistants is not only how much code they can write, but also whether they can keep users’ trust.