Email Prompt Injection

What Is Email Prompt Injection?

Email prompt injection is the mail-specific form of indirect prompt injection: instruction-like language contained in an inbound message reaches an AI system because that system reads the message as part of a human or automated workflow. Triage assistants, thread summarizers, support-ticket classifiers, CRM ingestion jobs and executive-assistant agents all take mail content into model context by design. That is the delivery surface.

The defining property is the same as on every indirect path, but email sharpens it. Inbound mail is content authored outside the organization, and it stays external and untrusted even when it arrives through a trusted mail platform, an authenticated connector or a first-party API. Transport can be impeccable while the message body is hostile. The attacker never needs an account on the AI application, never needs to interact with the assistant, and often does not need to know that an assistant exists: sending a message to an address that a workflow reads is sufficient reachability.

Keep two questions apart from the first paragraph onward. Whether mail content influences the model is a model-behavior question. Whether that influence produces a security consequence is an architecture question, and it depends on whether a capability or data path exists and whether an application-side control is missing, overbroad or failing. Most influence should end as an odd draft. It becomes a vulnerability when the workflow lets influenced output send, forward, disclose or write.

The End-to-End Delivery Chain

Mail reaches a model through more stages than a diagram of "inbox to assistant" suggests, and each stage is both a place where trust can be mislabelled and a place where a control can live.

The key boundary is between trusted mail infrastructure or components and the untrusted content they carry. The organization may legitimately trust its mail infrastructure, connector and parser as system software, but that property does not transfer to the message. A trusted pipe does not sanctify its payload. Transport authenticity, delivery reliability and API authentication answer questions about the channel, and none says whether text inside the message may direct an AI workflow. Parsing, normalization and summarization must therefore preserve the content's provenance and trust labels throughout the chain.

The normalization stage deserves particular attention, because it decides what the model actually sees. Choosing the plain-text alternative, the processed HTML body, the full quoted history or a connector-generated summary produces materially different context from the same message. Whatever is chosen, the model reads task instructions and external message content in the same window and may treat both as directive. From there, model output is a proposal. The final authorization and execution gate over recipients, data class, action scope and destination is the last deterministic gate before a side effect. Deterministic controls can also constrain earlier stages through data minimization, parser and representation boundaries, capability scoping, recipient and destination policy, and egress controls.

Which Email Surfaces Become Model-Visible

A message is not one text either. Every integration exposes a different subset of the following surfaces to the model, and the defensive requirement is to know exactly which subset enters context and to keep each part's provenance attached.

Provenance has to survive the whole chain. A useful record links the model-visible span back to a stable message identifier, the thread position it came from, the representation that was chosen, whether the span came from the new body or from quoted history, and whether it originated in an attachment and through which extractor. Once transformation erases source identity, downstream policy cannot distinguish externally delivered text from application-authored instructions or model-generated drafts, and an investigator cannot reconstruct which segment influenced which proposal.

Authentication Is Not Instruction Authority

The mechanisms are worth stating precisely, because the imprecise version is the source of the mistake. SPF (RFC 7208) checks whether the sending host is authorized for the RFC5321 MAIL FROM domain and may separately evaluate HELO or EHLO. DKIM (RFC 6376) signs a hash constructed from selected canonicalized header fields plus a hash of the canonicalized message body, identified by a signing domain and selector; verification establishes only what that signature covers. DMARC (RFC 9989) evaluates whether authenticated SPF or DKIM identifiers align with the visible RFC5322.From or Author Domain. Its p, sp and np values express the Domain Owner Assessment Policy - a message-handling preference that can inform the Mail Receiver's local decision when DMARC does not pass. Final handling remains receiver-local policy. RFC 8601 defines Authentication-Results for recording authentication status, but the field is reliable downstream only when a trusted authentication service within the receiver's administrative trust boundary, or an explicitly trusted upstream service, produced it. An externally supplied instance is not authoritative merely because the header exists.

Even a DMARC pass is neither an explicit nor an implicit assertion about the message's value, safety or the trustworthiness of its domain owner. It does not create AI instruction authority. RFC 9989, published in May 2026, is the current DMARC specification and obsoletes RFC 7489 and RFC 9091.

Four situations break the shortcut in practice. An authenticated domain can be compromised, so the identity is real and the intent is not. A domain can be operated by an attacker who registers it and configures authentication correctly, which is trivial. Sending can be legitimately delegated to third-party platforms, so an aligned domain identity may cover content the domain owner never reviewed. And most commonly, an entirely legitimate sender writes text that must remain data: a customer quoting a phrase, a vendor forwarding a notice, a colleague pasting a document excerpt. None of these are authentication failures. They are cases where authentication was never the question.

Internal domains deserve the same treatment. A message aligned to the organization's own domain may still contain quoted external text, a forwarded customer message or an attachment from outside. Alignment tells you which domain identity was used, not who authored the sentence the model is reading.

Trust Boundaries in Mail Workflows

Several components in a mail workflow are legitimately trusted infrastructure. That property belongs to the components, not to the content passing through them, and the boundary has to be drawn at that distinction.

As everywhere on the indirect path, four questions have to be answered separately for every mail-derived step. Source trust: who actually authored this span, and how do we know? Instruction authority: may this text direct behavior - for inbound mail content the answer is no. Data confidentiality: what model-visible data may this content influence, reference or cause to leave? Action authorization: what is the application permitted to do as a result, for this principal, on this resource, toward this destination? Collapsing any of these into "the sender is authenticated" is the specific failure this surface produces again and again.

Conversation Threads, Quoting and Provenance

Threading is what makes email different from a single fetched document. A thread is an accumulating, partly external, partly internal artifact that the workflow re-reads on every turn, and provenance decays through it unless the design actively preserves it.

Quoted history is the core mechanism. Text an external party wrote weeks ago is carried forward in every reply, and each carry-forward moves it further from its origin. By the tenth message, instruction-like content from an outside sender sits in the middle of a conversation that feels internal, adjacent to colleagues' text, with nothing in the representation marking where the boundary runs. A model reading the thread sees one continuous document. If the application also sees one continuous document, old external text has silently been promoted into trusted conversation state.

Forwarding blurs identity in a related way. A forwarded message arrives with a new, possibly internal, authenticated sender, while its body contains a different party's content. Envelope identity, visible author identity and the author of the quoted content are three separate facts, and a forward collapses them visually. Mailing lists, shared aliases, ticketing gateways and connectors add another layer: they may rewrite headers, add wrappers, prepend banners or restructure the body, so the representation the model reads is not the representation the original sender composed.

Derived artifacts are the second-order problem. When an assistant summarizes a thread and that summary is stored, shown in a later session or fed back into context, the summary usually arrives without the boundaries of its sources. Instruction-like content from an external quote can survive into a summary as if it were a conclusion the assistant reached. The summary now reads as system-generated and internal, and its origin is gone.

Practical provenance for mail workflows keeps a stable message identifier and thread identifier for every span, records thread position and direction (inbound external, inbound internal, outbound), distinguishes new body text from quoted history at extraction time, marks attachment-derived spans with their source and extractor, and records lineage for every derived summary so that a summary can be traced back to the exact messages and segments it came from. The invariant is the same one that governs the web delivery surface: transformation must not erase source identity.

High-Exposure Email Workflows

No workflow is inherently vulnerable. Exposure comes from the combination of reading external mail and holding a capability or data path that influenced output could reach. The following patterns are worth attention because they usually combine both.

The useful review question for each is not "is this workflow risky" but "what can influenced output reach from here": which recipients, which records, which credentials, which network destinations, and which of those steps currently pass through a deterministic authorization decision rather than through the model's judgement.

Offensive Review Questions

An authorized mail assessment should follow the message from sender control to an observable effect without treating successful delivery or authentication as instruction authority. Each representation and action boundary is an independent success gate.

Worked Example: An AI Mail Assistant

A support engineer asks an assistant to review an inbound customer thread and organize the follow-up. The assistant can read the mailbox, draft replies, and - in this configuration - send and forward.

Both halves of the lesson matter. The influence was real and measurable: an external segment changed the assistant's plan. The security impact was zero, because the design treated model output as a proposal and evaluated recipients, data class, action type and provenance deterministically. Had the same assistant been wired so that proposed sends execute directly, the identical message would have produced a customer-data disclosure with no failure anywhere in the mail stack.

Downstream Actions and Data Disclosure

"The assistant did something with the email" hides the distinctions that determine severity. Each of the following is a different action with different side effects, a different blast radius and its own authorization requirement.

Two of these are worth singling out. Copying model-visible internal context into an outbound reply is disclosure that looks like normal work; nothing unusual happened at the action layer, the payload was simply wrong. And link following turns a passive read into an outbound request, which means the mail workflow inherits the entire egress problem of the web surface, including redirects and destination validation.

Approval and Destination Binding

"Human in the loop" is not a control by itself. An approval that shows a summary and offers a confirm button teaches people to confirm, and it authorizes nothing specific. An approval is a security control only when it binds a decision to an exact, immutable description of what will happen.

Binding matters because of a time-of-check to time-of-use gap. If approval is granted against one description and execution reads a later, mutable state, the approval no longer covers the action. Any change to recipients, attachments, parameters, destination or action type after the approval invalidates it and must force re-evaluation, and in most designs a fresh approval. Practically this means the approved object is the authorization record: execution acts on the approved description, not on a plan the model can still revise.

Approval also has to be rationed to stay meaningful. Requiring confirmation for every draft destroys attention; requiring it for the steps that change recipients, cross a data class, leave the organization or write to a shared record preserves it. The rest should be handled by policy without a human in the path at all.

Detection and Telemetry

Detection on the mail path combines deterministic records of what the system did with probabilistic signals about content. The records prove what happened; the signals suggest where to look. Neither replaces the other.

Be honest about limits. Content classifiers produce false positives on legitimate mail that discusses AI behavior, quotes policies or forwards security notices, so their output must rank attention rather than block traffic. Authentication evidence proves identity facts, not content intent. Telemetry can prove which segment was in context when a proposal was made; it cannot prove causation inside the model. And proposal-versus-action correlation only exists if the architecture separates the two - if it does not, the absence of that telemetry is itself the finding.

Prevention and Secure Architecture

The goal is not a model that cannot be influenced by a message. It is an architecture in which no message, however persuasive, can by itself cause a send, a disclosure or a write.

1. 01
   Parse with provenance

   Choose the body representation deliberately, mark quoted history and attachment-derived text, and attach stable message and span identifiers before anything reaches the model.

2. 02
   Label untrusted content in context

   Present inbound mail to the model as external untrusted content distinct from task instructions, and keep the label attached through summarization and planning.

3. 03
   Minimize model-visible data

   Do not place credentials, unrelated mailbox content or broad customer records beside inbound mail unless the task genuinely requires them.

4. 04
   Remove ambient authority

   No standing mailbox, CRM or calendar permissions for the agent. Capabilities should be task-scoped, short-lived and separately granted for read, draft and send.

5. 05
   Separate proposal from execution

   Let the model propose; let deterministic logic authorize principal, action, resource, recipients and destination.

6. 06
   Bind approval to the exact action

   Approve a specific immutable description, and re-evaluate whenever recipients, attachments, parameters or the action type change.

7. 07
   Validate destinations and egress

   Recipient sets, link targets and outbound endpoints come from policy, never from text found in a message.

8. 08
   Preserve provenance through summaries

   Derived summaries and thread memory carry lineage to their sources, so external content cannot be laundered into internal state.

The layers are complementary and none is sufficient alone. Labelling and classification reduce exposure but remain advisory and probabilistic. Authorization outside the model is the layer that turns an influenced plan into a non-event; every other layer exists to make that layer's job smaller and better observed. The Defense Hub organizes these controls by family.

Incident Response

Mail incidents have a specific evidence problem: mailboxes are mutable, automation keeps running, and derived summaries keep propagating while the investigation starts. Preserve first, then scope.

The closing determination matters more than it sounds. "Influenced but contained" and "influenced and executed" call for different severities, different notifications and different fixes. Recording which specific control held keeps the remediation targeted at the gap instead of producing a general conclusion that the assistant is untrustworthy.

Controlled Testing

Test with synthetic messages in isolated mailboxes that belong to the test environment, never with production customer mail and never by sending probes to third parties. The point is to exercise the architecture, not to discover phrasings that work.

For a conceptual walk-through of the same trust decisions, the Email Prompt Injection lab uses fictional messages to separate connector and sender evidence from instruction authority.

Vary the dimensions the design actually depends on: body representation (plain text versus processed HTML), placement in new body versus quoted history, thread depth, attachment-derived text, authenticated versus unauthenticated source domains, internal versus external senders, forwarded versus directly received messages, and proposals that name destinations outside the task. Coverage across these dimensions is what produces useful findings; a single crafted message tests one path.

Report the results as separate metrics. A composite score averages away exactly the distinctions that determine severity.

Read the combinations carefully. A high influence rate with a low unauthorized-action rate shows that action-level authorization and containment are holding - the control that limits impact is working. It does not describe a healthy or finished system: substantial model-integrity and workflow exposure remains, and every remaining control carries the full weight of it. The reverse combination, low measured influence with a meaningful unauthorized-action rate, is a serious exposure, because it means the few influences that occur are reaching effects unchecked.

Common Implementation Mistakes

Standards and Research Context

OWASP LLM01:2026 names untrusted external content as a delivery path for indirect prompt injection, and NIST's terminology frames indirect injection as execution through control of a resource rather than through user input - which is precisely what an inbound mailbox is. Greshake et al. demonstrated the pattern in real LLM-integrated applications in 2023. Microsoft's guidance on defending against indirect prompt injection and on least privilege for AI agents addresses the capability side that determines whether influence becomes impact.

Research aimed at enforcement outside the model applies directly to mail workflows. CaMeL separates control and data flow and applies capability-based policies so untrusted content cannot redirect privileged actions - the send and forward paths are exactly such actions. AttriGuard asks whether a proposed tool invocation is causally attributable to user intent or to an untrusted observation, which maps cleanly onto the question of whether a proposed recipient came from the user's task or from a quoted segment.

The email authentication standards are listed because this page makes factual claims about what they specify, not because they are prompt-injection controls. SPF, DKIM, DMARC and Authentication-Results belong to a separate identity and authentication layer. They reduce spoofing and support filtering and reporting; they were never designed to decide whether text may direct an AI workflow, and treating them that way is the central mistake on this surface. No email standard addresses prompt injection specifically.

Frequently Asked Questions