Prompt Injection via Email: Your Support Inbox Is the Biggest Attack Surface

In June 2025, researchers at Aim Security demonstrated that one email could make Microsoft 365 Copilot leak internal company data. No link clicked. No attachment opened.

The vulnerability, catalogued as EchoLeak (CVE-2025-32711), drew a CVSS score of 9.3 and a server-side patch from Microsoft, who found no evidence of exploitation in the wild. The bug got fixed. The class of problem underneath it did not, because it isn't really a bug. It's what happens when you point a language model at an inbox.

Most AI security writing right now is about chatbots and coding agents. Almost none of it is about the support queue, which is odd, because the support queue is the softest target in the building.

The inbox is the only channel where strangers write directly into your model's context

Think about how untrusted content reaches an AI system in the other channels you run. A chat widget needs a session on your site. An API needs a key. Internal documents need someone inside the company to put them there. Every one of those paths has a gate in front of it, however weak.

Support email has no gate at all. The address is printed on your website, in your order confirmations, on the back of the box. Anyone on earth can compose arbitrary text, send it to that address, and have it land inside your agent's context window within seconds. It costs them nothing and it takes no privileges.

That's an open port with a human-friendly name.

Security teams have a word for the version of this that matters most here: indirect prompt injection. The attacker isn't the person operating the agent, and isn't even talking to the agent directly in the way a jailbreaker talks to ChatGPT. They're planting instructions in content the agent will read later, on behalf of somebody else, while doing an ordinary job. Support email is a delivery mechanism designed and maintained by you, at your expense, for exactly that purpose.

What prompt injection actually is, minus the mystique

A language model handling a support ticket sees one flat sequence of tokens. Your system prompt is in there. So is the retrieved knowledge-base article, the customer record you pulled from the CRM, the previous six messages in the thread, and the email that just arrived. Nothing in that stream carries a flag saying this part is data and this part is orders.

Sectigo's Jason Soroko put the architectural version of this well in coverage of the 2026 OWASP list: instructions and data travel down the same channel, and there's no equivalent of a parameterised query to separate them. That comparison is worth sitting with. SQL injection was solved because someone built a way to say "this string is a value, never a command." No such mechanism exists for natural language, and every mitigation we have lowers probability without ever reaching zero.

OWASP published its 2026 GenAI/LLM Top 10 on 4 August 2026, and prompt injection held the number-one slot for the third consecutive edition. What's interesting is how it held it. The 2026 ranking mixed practitioner votes with roughly 6,639 documented real-world incidents, weighted 75/25. On raw incident count, prompt injection barely registers. OWASP reads that gap as a defence effect: mature teams already spend heavily fighting it, so fewer clean exploits reach public databases.

Which is another way of saying the low incident count is a report card on defenders, not a measure of the risk. Teams that haven't done the work don't get to borrow that number.

Where injected instructions hide in a support thread

The email body is the obvious place, and it's the least interesting one. Anything written plainly enough for a human to notice is also the easiest thing to catch. The paths that matter are the ones where what a mail client renders and what a parser ingests are two different things.

• Hidden HTML. White text on a white background, zero-size fonts, hidden divs, and HTML comments all disappear for the human reader and survive intact for the model. EchoLeak used exactly this class of trick.
• Attachments and embedded images. A PDF invoice or a screenshot of an error goes through OCR or a vision model, and whatever text comes out lands in context. We covered the operational side of this in handling email attachments with AI; the adversarial side is the same pipeline read backwards.
• Quoted history and forwards. Customers forward chains. Those chains contain content written by people who were never your customer, and your agent reads all of it to reconstruct context.
• Signatures and auto-appended footers. Low-attention real estate that nobody reviews and every parser reads.
• Form-to-email tickets. If a contact form generates a support email, the form's free-text field is now an injection vector wearing a nice UI.
• Slow accumulation across a thread. Nothing in message one looks wrong. Nothing in message four looks wrong either. The combination, sitting in a context window together on message five, does something neither did alone.

The common property across all six: by the time the model reads them, they're in the same context window as your system prompt, with equal standing.

What the attacker is actually after

Three goals, roughly in descending order of drama and ascending order of how often they happen.

Exfiltration is the headline case. The agent has read access to order history, account records, and the CRM. It also has the ability to send email. An injection that gets the agent to include private data in a reply routed somewhere the attacker controls is a complete data breach with no malware involved anywhere in the chain.

Unauthorised action is the one that scales with your integration depth. The more an agent can do — refunds, address changes, plan modifications, credential resets — the more an injection is worth. This is why OWASP moved Excessive Agency from sixth to third in the 2026 list, its biggest jump. Capability and blast radius are the same quantity measured twice.

Policy override is the boring one, and it's the one that will cost most teams real money. No exfiltration, no CVE, no incident report. Just a steady stream of people who've worked out which phrasing gets your agent to approve a refund outside policy, and who tell each other. It never shows up in a threat model because it doesn't look like an attack. It looks like your refund rate drifting up three points a quarter.

What the chain looks like end to end

Imagine a mid-sized retailer whose email agent handles order queries and issues refunds under £50 without review. A message arrives that reads, to any human who opens it, as an ordinary complaint about a delayed parcel. Underneath the visible text sits a block of hidden markup the mail client never renders.

The agent parses the message. It retrieves the order record, as it should. It also ingests the hidden block, because nothing in the pipeline distinguishes rendered text from markup, and that block is written to read like an operator note rather than a customer request — the sort of thing a system might legitimately append to a ticket. The agent, having no way to tell the difference, treats it with the same weight as the actual policy in its system prompt.

What happens next depends entirely on decisions made before the email ever arrived. If the refund tool is scoped to the resolved intent and this ticket resolved as a delivery query, the tool isn't reachable and the attack dies quietly in a log line. If the agent holds one credential covering every action it might ever take, the attack succeeds and the only trace is a refund that looks slightly odd on a report nobody reads until quarter-end.

Same model. Same email. Same prompt. Completely different outcome, decided by an architecture choice made months earlier.

Why filtering doesn't close this

The instinct is to build a classifier that catches injection attempts before they reach the model. Do build one. Just don't believe it's the control.

Microsoft had a dedicated cross-prompt-injection classifier in front of Copilot. EchoLeak chained its way past it, along with link redaction and content security policy, using a sequence of individually unremarkable bypasses. Natural language has an unbounded paraphrase space, and a filter tuned to catch instruction-shaped text has to win every single time while the attacker only needs one phrasing.

Tighten the filter and you hit the other wall. Real customers write things that look exactly like injection. They write "ignore my previous email, the issue is different." They paste error logs full of imperative statements. They forward a message from your own billing system that contains instructions. A filter aggressive enough to stop a determined attacker will bury your queue in false positives, and in practice we've seen injection heuristics flag far more frustrated customers than actual adversaries.

Filters reduce volume. Architecture reduces consequence. Only one of those is a control.

The design that holds: bound what a compromised agent can reach

Start from an assumption that feels defeatist and isn't: at some point, some email will successfully steer your model. Design the system so that when it happens, the attacker inherits very little. This is also, broadly, where the Five Eyes agencies landed when CISA, the NSA, and their counterparts in the UK, Australia, Canada and New Zealand published Careful Adoption of Agentic AI Services on 1 May 2026 — restrict scope, enforce least privilege per request, and require human approval for high-impact actions.

Separate the reader from the doer

The component that reads untrusted email should not be the component that holds credentials to your order system. One model parses and classifies, producing a structured intent with typed fields. A separate execution layer takes that structure and calls tools. Prose never reaches the tool-calling boundary, so an instruction embedded in prose has nothing to steer once it gets there.

This costs you some flexibility. It's worth it.

Scope tools to the intent, not to the agent

Most deployments give the agent one credential set covering everything it might ever need, then rely on the model to choose correctly. That puts a probabilistic system in charge of an authorisation decision, which is the wrong job for it.

Scope narrower. A ticket classified as an order-status question gets read access to that customer's shipment record and nothing else — no refund endpoint, no address mutation, no access to a different account. If the classification is wrong, the failure is a bad answer rather than a bad action.

Never let the email establish identity

A sender address is a claim, not a credential, and everyone in security knows this until an AI agent is doing the reading. Any statement inside an email about who the sender is, what tier they're on, or what they're authorised to do carries exactly zero weight. Identity resolves through your own systems: the authenticated session, the verified account, the signed portal link. Anything the agent needs to know about the customer comes from the record, never from the message.

Control where the reply can go

Exfiltration needs an exit. Constrain it. Replies go to the verified address on the account, not to a reply-to header supplied in the inbound mail. Outbound content gets checked against what the resolved intent should legitimately contain, so a shipping-status answer carrying a block of account data trips something. Where your platform renders links or fetches remote images, treat both as egress paths, because that's what EchoLeak used them as.

Two more things belong here without needing their own headings. Irreversible actions — money out, credentials changed, data deleted — should sit behind a human gate or a second verification channel no matter how confident the model is, which is a design question we go deeper on in our guide to when AI should resolve versus route to a human. And every piece of content in the context window should carry provenance, so that when you investigate later you can answer the only question that matters: which text caused this action.

What to log, and what should page someone

You can't investigate what you didn't record, and injection incidents are reconstructed almost entirely from logs. Full guidance sits in our piece on audit trails for AI email support, but the injection-specific signals are worth naming.

The highest-value alert by a distance: a tool call that doesn't match the classified intent. An email classified as a delivery query that somehow produced a refund call is either a serious classification failure or a successful injection, and both need a human within the hour.

Below that, worth watching:

• Outbound replies containing data not tied to the verified account on the thread
• Reply-to or destination addresses that diverge from the sender's verified address
• Instruction-shaped content detected in inbound mail — logged as signal, not necessarily blocked
• Repeated near-identical inbound structure across many senders, which is what a campaign looks like from the inside

Set a retention window long enough that you can reconstruct a slow-burn attack that unfolded over weeks. Thirty days is not long enough.

Where this is genuinely unsolved

Anyone selling you a complete answer here is selling you a filter with confidence.

Multimodal injection is ahead of most defences: instructions embedded in images and screenshots reach a vision model without ever existing as text you could scan. Long-thread accumulation is hard because re-verifying an entire context window on every turn is expensive, and the attacks that matter are patient. And the ground is about to move again as customer-side AI agents start writing support email on their behalf, which flips untrusted machine-generated content from an edge case to the default input.

The honest position is that this is a containment problem, not a prevention problem. You're not trying to make injection impossible. You're trying to make a successful injection boring.

If you want the structural version of why that's true, the risk has a name that security teams already recognise. An email support agent reads untrusted content, holds private data, and sends messages outside the organisation, which is precisely the configuration described in the lethal trifecta as it applies to email support.

Four questions worth putting to your vendor

Vendor security pages are written by marketing teams and mostly list certifications, which tell you nothing about this specific risk. These four do, and the quality of the answer matters more than the answer itself. A vendor who has thought about injection will engage with the detail. A vendor who hasn't will reach for the word "secure."

1. Does the component that reads inbound email hold the credentials that take action? If yes, every other control is downstream of a single point of failure. Ask for an architecture diagram, not an assurance.
2. Is tool access scoped per resolved intent, or granted once per agent? The second answer is far more common than vendors like to admit, and it's the difference between a bad reply and a bad transaction.
3. Where does the reply address come from? If the answer involves headers on the inbound message rather than the verified account record, you have an exfiltration path by default.
4. What gets logged when a tool call and a classified intent disagree? This is the single most diagnostic signal in the system. A vendor who doesn't log it has never investigated an incident.

None of this requires you to be a security engineer. It requires you to keep asking "and then what can it reach" until the answers stop being vague.

How this shapes Robylon's email architecture

Robylon runs email support agents that resolve 60–80% of tickets autonomously, and that number only means something if the resolutions are also safe ones. The separation between the model that reads inbound mail and the layer that executes across 60+ write-access integrations is deliberate: intent classification produces structured output, and the execution layer acts on structure rather than on prose. Tool access is scoped per resolved intent. Identity comes from the account record. Irreversible actions route through human-in-the-loop review before anything leaves the building.

None of that makes injection impossible. It makes the reachable damage small, which is the only claim anyone should be making in this category right now.

Ready to deploy email automation that's designed for an adversarial inbox? Robylon AI resolves 60–80% of customer emails autonomously with scoped, auditable agents that act across Zendesk, Shopify, Salesforce, Stripe and 60+ other integrations. Start free at robylon.ai