Prompt injection in email agents: a fake mailbox fault becomes permission

An email agent can be steered into a harmful mailbox operation without being told to ignore its instructions. Research by Jiangrong Wu and colleagues describes an attack that presents an attacker's goal as the routine fix for a mailbox fault, and the agent acts on the fault as if it were real.

The work is revised research, and it does not report a customer breach. Version 2 of “Your Mailbox Is Mine: Prompt Injection Attacks Against Real-World LLM Email Agents” was submitted on 19 September 2026 and accepted at NDSS 2027. The authors used researcher-owned accounts and synthetic mail. Promptective has not independently reproduced the results. See what prompt injection is and our prompt injection examples.

A forged fault inside ordinary email content

Email prompt injection is indirect prompt injection with a specific carrier: the untrusted instruction arrives in the mailbox the agent manages.

The attack, which the authors call Email-Specific Prompt Injection, combines two elements inside email content the agent processes:

• A forged operational claim that looks like a mailbox or protocol notice, such as a storage quota warning or a synchronisation failure.
• A maintenance narrative that presents the attacker's operation as the necessary remedy before the user's original request can continue.

The agent does not check the claim against the mail service. It reads the claim as state, concludes the mailbox is degraded, and treats the attacker's operation as the way to clear the obstruction. The authors report that successful traces follow this pattern: the model treats the forged state as current, decides the user's task is blocked by it, and performs the operation as remediation. A forged premise changes the context in which the agent evaluates its own actions, so the operation appears as maintenance.

Content claims and authenticated state are different evidence

An email body is untrusted input. Mailbox state is a fact about the mail service, and it should come from the service's own authenticated evidence: the response to a real API or protocol request, checked at decision time. The toolkits the authors evaluated validate parameters and permissions, and they do not perform a runtime check of mailbox state, so a forged claim in an email is available to the model as service truth.

Even a genuine mailbox fault does not authorise arbitrary remediation. A real quota problem does not authorise forwarding private messages to an external address. State verification answers whether the fault exists. Action authorisation answers whether this operation, on this resource, for this user and purpose, is permitted.

What the evaluation measured, and in which denominator

480 controlled attack trials. The study crosses four attack scenarios, six language models and five payloads across four agent frameworks: LangChain, LlamaIndex, aiwaves-cn/agents and Griptape. The authors report 353 successes, an attack success rate of 73.54%.

870 black-box instances across 63 anonymised applications. The real-world evaluation covers the application-model dimension (63 applications with six models, 378 instances) and the application-service dimension (compatible applications across ten public email services, 492 instances). The authors report that all 63 applications were hijacked, with 1.84 to 1.89 attempts on average for the first success.

Neither figure is a population-wide compromise rate. The controlled trials measure attack effectiveness in a configured test setting, and the instance counts measure reach across the applications the authors could deploy.

What the authors disclosed, and what remains unverified

The authors state that they disclosed their findings to 67 vendors. They report formal acknowledgement from 22 of them, covering all four frameworks and 18 applications, and the assignment of 16 CVE identifiers. They withheld the identifiers to avoid pointing attackers at unpatched deployments, and they state that the vulnerabilities remained unremediated at publication.

Those acknowledgements, identifiers and remediation statements are author-reported. The identifiers are not published, so they cannot be independently confirmed, and no present-day patch status has been verified.

What the defence results show

Prompt-level defences left attack success rates above 60%. Two action-level defences did better: Progent at 26.67% and AlignmentCheck at 37.50%. The authors' prototype, EmailStateGuard, recorded no successful attack in the 480 evaluated trials by authenticating the claimed mailbox state against trusted mailbox resources and checking whether the operation is authorised at the tool-call boundary.

Zero observed successes against a prototype under its evaluated conditions is not a guarantee of protection. It covers one attack family and one test setup.

What security teams can apply

1. Treat email content as input, never as state. A message can claim anything about the mailbox. It cannot make the claim true.
2. Authenticate state claims before acting on them. Ask the mail service for its own view of quota, delivery and message state.
3. Authorise each consequential action separately. Bind approval to the exact operation, resource scope, recipient and purpose.
4. Keep high-impact operations behind explicit controls. Separate reading from sending, and require confirmation before data leaves the account.

The SiYuan MCP case shows the same lesson at a different boundary: the tool arguments were visible before approval, and the application still needed enforced policy to reject a sensitive file path. Our guide to securing LLM agents with tools covers the control layers.

How this applies to Promptective

Promptective puts organisation policy at supported AI interaction and action boundaries. It detects prompt injection, secrets, PII, unsafe content and policy violations, then combines the finding with the proposed operation before returning an explicit outcome: allow, audit, sanitise, require approval or block.

For an email agent, the decisive checkpoint is the proposed mailbox operation and its arguments. An integration must enforce the policy decision before executing that operation, including withholding it when approval is required. Security receives a content-minimised policy record; the owning application controls approval and execution. The study did not evaluate Promptective or a Promptective mailbox integration.

A mailbox fault is a claim until the service confirms it. An operation is not authorised because a message says it is maintenance.

See Promptective in action

Sources

• Your Mailbox Is Mine: Prompt Injection Attacks Against Real-World LLM Email Agents, version 2, Jiangrong Wu and colleagues, submitted 19 September 2026; accepted at NDSS 2027. Accessed 24 September 2026.
• Full paper, version 2, sections VI and VII.