Data Exfiltration Through Support Email: Attack Patterns and Controls

A support agent that reads inbound email, pulls up account records, and sends replies has everything an attacker needs sitting in one place. Untrusted text goes in one end, private data sits in the middle, and a send action waits at the other. Nobody has to breach anything here — the normal workflow is the path out.

That's an uncomfortable sentence to write about a product category we build in. It's also the honest starting point for any security conversation about autonomous email support, and the teams who take it seriously ship better systems than the ones who treat exfiltration as a filtering problem.

Three properties that turn a helpful agent into a leak

Security researchers have a useful shorthand for this combination: an AI system becomes dangerous when it can read untrusted content, access private data, and communicate externally. Any two of the three is usually manageable. All three together means an attacker who controls the input can, in principle, steer the output.

An AI email support agent has all three by design. It has to read whatever arrives in the inbox, because that's the job. It has to look up the customer's order, subscription, or claim, because a reply without account context is useless. And it has to send email to people outside the company, because that's what support is.

You can't remove any of the three without removing the product. So the work isn't elimination. It's constraining how far each property can reach.

Picture a hypothetical mid-market SaaS company running email support through an agent connected to Salesforce and Stripe. A ticket arrives from a free-tier signup: a formatting complaint, three paragraphs long, with a block of text near the bottom styled to render invisibly in most clients. That block tells the agent an internal audit is underway and asks it to append a summary of recent enterprise accounts to its reply, sending a copy to a second address for the audit team.

Every step after that is the agent doing its job. It reads the ticket. It has CRM read access. It sends email. If nothing in the architecture stops it, the failure isn't a bug — it's the system working exactly as specified.

What exfiltration actually looks like in an inbox

Most people picture data theft as a database dump. In support email it's quieter than that, and it usually arrives looking like a normal ticket.

Instructions dressed as customer text

The base pattern is prompt injection: text in the ticket that the model treats as direction rather than content. A message might contain a block of text framed as a system note, an internal policy update, or a formatting instruction, positioned so the model reads it as coming from the operator rather than the sender.

The variants get creative. Attackers hide the text in a long forwarded chain, in an email signature, in HTML that renders invisibly in most clients. The point isn't any single trick. It's that the boundary between “content the agent should reason about” and “instructions the agent should follow” is a boundary the model has to infer, and inference can be pushed on.

Recipient drift

The cleanest exfiltration doesn't need the agent to break policy about what data it can access. It only needs the agent to send a legitimate reply to the wrong address.

Ticket bodies contain a lot of addresses. Reply-to headers, CC lists, forwarded chains, text like “please copy my accountant at...” A ticket that arrives with a spoofed reply-to and an in-body request to loop in a second address is asking the agent to make a routing decision on attacker-supplied data. If the agent honors it, the account summary goes out correctly formatted, correctly toned, and to the wrong person.

Beacons in rendered content

Email clients fetch remote images. Link tracking is normal. Both of these are channels.

If an agent can be induced to include a link or image reference whose URL carries data in its parameters, the data leaves the moment the recipient's client renders the message. Nobody reads a suspicious email. There's no obvious payload. The exfiltration is a GET request in someone's image cache.

The slow leak

Volume-based detection assumes the attacker is in a hurry. A patient one won't be.

Fifty tickets across three weeks, each extracting one plausible field — a partial address here, a plan tier there, an order date — reconstruct a customer list without a single anomalous event. Each individual reply is a correct, on-policy answer. Only the aggregate is an incident, and aggregate is precisely what per-ticket controls don't see.

Tool-chain pivots

This is the one that worries us most, and it's the least discussed.

An agent with write access doesn't need email to move data. If it can update a CRM note, attach a file to a shared record, add a comment in a project tool, or trigger a templated notification, each of those is an outbound channel with different logging and different review. Data that never leaves through the mail server can still leave. The more capable the integration layer, the more exits exist.

Why email is a harder problem than chat

Chat has a session. A conversation starts, happens, and ends, and the context boundary is reasonably clear. Email has none of that discipline.

Threads persist for months. Messages get forwarded to people who were never party to the original conversation. A single reply can carry the full quoted history beneath it, which means a leak in message four is still leaking in message nineteen. Distribution lists mean the recipient set isn't always knowable at send time. And attachments arrive as opaque blobs that something has to open and read.

Email is also asynchronous, which sounds harmless and isn't. An agent replying at 3 a.m. to a ticket that arrived at 2:58 a.m. has no human in the loop by default, and the reply is already delivered by the time anyone looks.

Controls, roughly in the order they matter

Filtering is where most teams start and it's the weakest layer. A classifier that flags suspicious ticket text is worth having, but it's a probabilistic control against an adversary who gets unlimited attempts and can see your responses. Put architecture first.

Constrain the send path

The highest-value control is the narrowest one: an agent should be able to reply to the verified requester on an existing ticket, and that's it.

• Reply-only-to-thread: the recipient is derived from the authenticated ticket record, not from headers or body text in the inbound message.
• No agent-initiated CC or BCC. Adding a recipient is a human action or it doesn't happen.
• Domain allowlisting for any account where the customer relationship is B2B and the legitimate recipient set is known.
• New-recipient gating: if an address hasn't appeared on the account before, the message queues for review rather than sending.

Most exfiltration patterns die at this layer, because most of them depend on the agent sending somewhere it shouldn't.

Scope retrieval, not just credentials

Least privilege at the credential level is table stakes and insufficient. The agent's service account shouldn't have blanket read on the CRM, but even scoped credentials leave room if any single ticket can retrieve arbitrary records within scope.

The tighter design binds retrieval to the ticket. The agent handling a query from a verified customer can read that customer's records. Not the neighboring account, not a similar order ID, not a lookup by email domain. When a query would return data for an identity other than the one on the ticket, that's a hard stop rather than a confidence-weighted judgment call.

Field-level restriction matters too. Very few support workflows need full payment details or complete audit history. Return what the response actually requires.

Worth checking how your retrieval layer handles ambiguity, because that's where scoping quietly breaks. A customer writes in about “the order from last Tuesday” and the lookup returns three near-matches across two accounts. A well-scoped system returns nothing and asks. A loosely-scoped one returns all three and lets the model pick, which means the model has now seen data belonging to someone who didn't email you. Whether it repeats that data in the reply is then a matter of luck.

Close the covert channels

Sanitize what goes out, not just what comes in:

• Strip remote image references from generated replies, or restrict them to a known asset domain.
• Rewrite or drop URLs the agent didn't source from an approved set. A link the model invented is a link nobody vetted.
• Normalize outbound HTML so invisible text, zero-width characters, and off-canvas positioning can't survive into the sent message.

These are cheap and they eliminate a whole family of attacks that would otherwise be invisible in your logs.

One more that teams miss: quoted history. If the agent's reply appends the full thread beneath it, anything the agent said in message two travels with message twelve. Trim aggressively, and be deliberate about whether internal notes, prior escalation reasons, or system-generated context ever end up in the quoted block. We've seen more accidental disclosure come from that than from anything an attacker engineered.

Gate the actions that move data

Read and write should not live behind the same trust boundary. Every write-capable tool the agent can reach needs its own gate, sized to blast radius: a status update is low-stakes, a bulk export is not.

Bulk operations, cross-account operations, anything touching more records than a single ticket justifies — those want a human. So does any action the agent has been asked to take by text in the ticket rather than by the workflow's own logic. That distinction is worth building explicitly, because “the customer asked me to” is exactly the reasoning an injected instruction produces. Our note on when to resolve versus route to a human covers the design of those thresholds in more depth.

Instrument for the aggregate

You will not catch the slow leak in real time. You can catch it in review, if you logged the right things.

What that requires: every retrieval the agent performed, every field returned, every recipient on every outbound message, and a stable identifier that lets you group activity by requesting identity rather than by ticket. Then you're looking for patterns across time — one sender opening many tickets that each touch a different record, unusual field access on low-complexity tickets, replies to addresses that don't match account history. Our guide to audit trail design for AI email goes through the event schema.

Detection here is genuinely retrospective. Design for the investigation you'll run in three months, not the alert you hope fires tonight.

Where all of this falls down

A few honest limits, because a controls list that claims completeness is a controls list you shouldn't trust.

Injection defense is not solved. No prompt engineering, guardrail model, or input classifier reliably stops a determined attacker with unlimited attempts. Everything above is about reducing what a successful injection can reach, not preventing injection.

Allowlisting has real cost. Consumer support at scale can't allowlist recipient domains, and B2B teams with legitimate multi-party threads will find reply-only-to-thread annoying about twice a week. That's a genuine tradeoff and worth making, but pretending it's free is how controls get switched off six weeks after launch.

And the biggest gap: a support inbox is full of people you can't authenticate. Someone emailing from a personal address about an order is a stranger with a plausible story. Verification design is its own problem, and no send-path control fixes a case where the agent correctly replies to a requester who successfully impersonated the account holder.

How we approach this at Robylon

Robylon's email agents derive the reply recipient from the ticket record, not from inbound headers or body text, and adding a recipient is a human action. Retrieval is bound to the verified identity on the ticket. The write-access integrations that let agents take real action — issuing a refund in Stripe, updating a Salesforce record, changing an order in Shopify — sit behind per-action gates with configurable approval thresholds, and every retrieval and outbound recipient is logged for after-the-fact review.

None of that makes the system immune. It makes the successful attack smaller and the investigation possible, which is the realistic goal. If you're evaluating vendors on this, our security checklist for enterprise buyers has the questions worth asking.

The one question we'd put at the top of any evaluation: show me what happens when a ticket asks the agent to send account details to a second address. The answer tells you more about the architecture than any certification will.

Ready to deploy email automation your security team will actually sign off on? Robylon AI resolves 60–80% of customer emails autonomously with agents that take action across Zendesk, Salesforce, Stripe, and 60+ other integrations — behind per-action gates and full audit logging. Start free at robylon.ai