Why Coding Agents Leak Account Emails in Outbound Requests—and How to Govern It

Identity fields that enter a model context and then share an automation path with networked tools and generated scripts can turn a casual “include a contact” into a real outbound leak. Recent industry discussion has repeatedly confirmed one pattern: when coding agents run networked commands, they write the current login email into the HTTP User-Agent sent to visited sites. This is not a full dump of a server-side user store, so the blast radius is usually smaller than a database breach. The nature of the issue is still serious: a field meant only for account identification leaves the product boundary and lands in third-party request logs, gateways, and security appliances.

Separate facts: mitigation is not a root fix

Judgments that hold up in public discussion fall into three layers. Technical write-ups should not collapse them into “already fixed.”

Layer 1: incident reports. Multiple users on nearby versions observed account emails in User-Agent when the agent fetched pages or generated requests. In sub-tasks and multi-agent collaboration, visits to external sites also repeatedly carried the email as contact information. These are case reports and reproductions, not a population-wide rate. They are enough to show the path is triggerable, not a one-off false alarm.

Layer 2: vendor-side deterministic intercepts. Maintainers have acknowledged a need for privacy intercepts that are on by default: if a command about to run carries both a login email and User-Agent-related signals, execution should be blocked. A prompt line that says “do not leak” is not enough. Publishing such a module treats the issue as an engineering defect, not an occasional model slip. Putting the check before tool execution—not after answer generation—is the right direction. Model output is unreliable; policy checks must be independent of generation.

Layer 3: completeness of the fix. The same threads still report misses: some command shapes, scripts the model assembled on the fly, and indirect call paths were not blocked. Maintainers also said they would later remove the account email from model context. Until release notes clearly state that the email is no longer injected into context, “we have an intercept” must not be written as “fully fixed.” A safer status is: temporary mitigation exists; a complete fix depends on official notes and repeatable retests.

How the outbound leak happens

Splitting the chain is more useful than blaming a model that “remembers too well.”

Account systems often put email into the session or tool-visible environment so the UI can show “who is logged in,” generate commit messages, or fill a feedback contact. A coding agent’s context often includes chat, project files, terminal snippets, browser or page summaries, plus executable shells, scripts, and HTTP clients. Under the goal of acting like a diligent client, the model copies common request headers and fills in the email it saw as User-Agent or a custom contact field. Once the command runs, data leaves the range local policy can easily retract: the remote site, CDN, WAF, and enterprise proxy logs may all keep copies.

Risk therefore does not depend on whether the model recites the email in chat. It depends on three conditions at once: it can read an identity field; it can call tools that make network requests; there is no model-independent check before send. When those three sit on an unattended path, a single error turns from a wrong answer into data leaving the boundary.

User-Agent is easy to ignore. In the protocol it is an optional, unstructured string; many libraries let callers concatenate freely. Reviews that only watch tokens, passwords, and private keys miss a field that looks like a product identifier but is actually a personal identifier. Email in User-Agent has a side effect: it is often written to access logs and kept for a long time, and it is hard to delete line by line afterward.

Why intercepts miss

String-feature intercepts are allow-list patches, not context isolation.

They typically match “the command text contains both an email and the words User-Agent.” Several patterns weaken or bypass that:

• The email is split into variables, environment variables, or config files, so the command line never shows a full address.
• The request is issued by a script, task runner, or language runtime; the outer command is only “run this file.”
• The header is not named User-Agent but Contact, Origin, Client-Info, or similar.
• Sub-agents, retries, and pipelines split one intent into steps that individually miss the rule.
• The model first writes the email into generated source, then the user or agent runs it in a later step.

Default intercepts are necessary mitigation, not a sufficient condition. They show vendors accept deterministic control, and they expose the ceiling of scanning command text only. If identity data still enters context by default, the model will find new carry methods.

Conceptually, a pre-execution check is a gate independent of generation—not another question to the model:

Command or script about to run
    -> Parse whether it constructs outbound HTTP
    -> Scan headers, body, and query parameters for registered sensitive identifiers
    -> On hit: deny and audit
    -> On miss: allow the tool to run

The scan target should be the request about to leave the process, not only the one command line the user can see. Environment variables, temp scripts, and headers assembled at runtime belong under the same rules.

How ordinary users judge and shrink risk

Upgrading to the current official version is the first step, but upgrade is not zero risk. If notes only say “stronger privacy” and do not say whether context still contains the account email or which call paths are covered, treat the version as partial mitigation.

Until a complete fix is confirmed by notes and retest, avoid letting the agent visit unfamiliar sites unattended, especially when the task generates request headers, batch scripts, or crawl logic. When networking is required, narrow targets to known hosts and review headers that will be sent—do not only read the final chat answer.

Local checks can follow three lines. Do not assume a leak occurred, but be able to falsify one:

• In history and terminal records, did the account email appear together with User-Agent or header setup?
• If you use version control, check whether commit messages, author fields, and collaboration attribution were auto-filled with a real work email. Public repos keep that metadata in clones for a long time.
• On the enterprise side, search egress, dev-proxy, or tool-gateway logs for whether this account’s email appears in outbound headers or URLs. Log search itself must follow least privilege so investigation does not become a second leak.

Identity layering also helps: separate a daily public contact email, a work email, and high-sensitivity account emails. What a coding agent binds by default should be a public, rotatable contact identifier—not the primary mailbox used for payroll, admin consoles, or cloud control planes. Rotation cannot erase logs already sent, but it limits later sessions from carrying the same identifier.

Enterprises should not rely only on desktop prompts. Stronger controls sit at the tool-call layer and network egress: pattern-check outbound HTTP headers; deny or redact hits on registered employee emails, employee IDs, or internal domains; write the deny reason back to the user. Egress policy looks at packets, not at whether the model “promised not to leak,” so it covers client-side misses.

What counts as a trustworthy fix

A one-shot patch is easy to phrase as “we added filtering.” An acceptable fix should meet all four of the following; missing one still justifies contracted use.

Sensitive data does not enter model context by default. Account display can stay in the UI without stuffing identifiable emails or phone numbers into every inference input. If a task truly needs a contact field, require explicit authorization, limit scope, and clear it from context and temp files when the task ends. Default least privilege beats default full injection plus model self-control.

Outbound traffic has a model-independent deterministic check. Check failure should block the tool outright, not emit a warning the user can ignore. Rules should cover command lines, script files, environment variables, and header setup for common HTTP clients, and they should state known uncovered paths so “secure by default” is not read as “all paths are safe.”

Permissions are visible and revocable. Users should see which identities the agent holds, which tools can reach the network, and which directories can be read. After revoke, the next call must fail—not merely hide an icon while the process still carries old tokens.

Failures are auditable. Intercepts, denials, and still-allowed outbound requests should leave audit records without sensitive bodies: time, tool, target host, rule type hit, whether blocked. Without audit, you cannot tell whether intercepts actually work or only work on some commands. Retests should include direct header setting, indirect scripts, sub-tasks, retries, and emails that exist only in environment variables. Testing one obvious command repeats the problem of “intercept on, bypass still open.”

Privacy boundaries when designing agents

Architecturally, a coding agent’s privacy boundary is data plane plus control plane. The data plane answers which fields may enter context, how long they stay, and whether they are written to logs and training feedback. The control plane answers which tools may network, who checks before network, and who may override a failed check. Handing both to the same model sample makes the least certain component the last gate.

In practice, split session material into two grades: visible to inference versus visible only in the UI. Emails, billing identifiers, and access tokens should live in the UI or a dedicated credential store by default. Tools inject short-lived credentials on demand rather than writing long-lived identity into the prompt. Network tools should default to least privilege: constrain methods, hosts, and header allowlists, and forbid freely setting headers that can carry personal data. If generated code contains outbound requests, run the same scan before it is written to the workspace so “write then execute” cannot skip command-line checks.

Logs are another exit. Debug logs, crash reports, and “improve the product” feedback that upload command lines verbatim send a local email out again. Redaction before upload must happen on the client, using the same sensitive-field list as pre-execution intercepts so two rule sets are not one strict and one loose.

For teams, write “what the agent may do” as you write CI permissions: default readable scope, default network destinations, no automatic rewrite of commit identity, no opening arbitrary URLs in unattended jobs. Put policy in the repo or platform; do not rely on everyone remembering to add “don’t leak the email” in chat.

How to communicate without hype or downplay

External messaging slides toward two extremes: “the user database was breached,” or “just a small header issue, upgrade and done.” A more accurate statement is: identity identifiers reached third-party-visible protocol fields via tool calls; impact depends on who received the request, how long logs are kept, and which other systems that email is bound to; the product has runtime intercepts, but whether context injection is gone and bypasses are closed must follow release notes and retests.

User-side actions are equally concrete: upgrade but keep spot checks; pause unattended visits to unfamiliar sites; search historical commands and repo metadata; separate emails; intercept at enterprise egress. Those five do not depend on memorizing a version number, and they apply to later cases of “a secret in context walked out through a tool.”

Coding tools fold reading files, changing code, and accessing the network into one task. Productivity rises while the cost of error shifts from a wrong answer to a wrong packet. Privacy that exists only in prompts will always chase new carry methods. Keep sensitive fields out of context, put outbound checks in front of tools, and audit both deny and allow. That is a boundary you can retest and revoke. Until those four points are written clearly in release notes, saying “mitigated” separately from “fixed” is itself responsible to users.