The Lethal Trifecta in Email Support: Untrusted Content, Private Data, External Send

Take an AI support agent to a security review and you'll spend forty minutes explaining what it is before anyone can tell you whether it's safe. There's a shortcut. It has a name, security teams already know it, and once you say it out loud the rest of the conversation goes much faster.

The bad news is that saying it out loud also makes the risk impossible to wave away.

The framework, in one paragraph

In June 2025, Simon Willison named a configuration he called the lethal trifecta for AI agents: access to private data, exposure to untrusted content, and the ability to communicate externally. Any two of those are manageable. All three together mean an attacker can plant instructions in content the agent reads, have the agent fetch sensitive data, and have it send that data somewhere the attacker controls.

The elegance of the framing is that it doesn't require a bug. Nothing in the code has to be broken. The agent does its job correctly, and it does that job on behalf of the wrong person.

A year on, the framework has become the default vocabulary for agent security, and for a straightforward reason: it explains the incidents better than anything else on offer. When production AI systems get compromised, the post-mortem almost always resolves to the same three legs standing together.

An email support agent has all three by definition

This is the part that makes CISOs sit up, and it deserves stating plainly rather than softening. Every leg of the trifecta isn't just present in an AI email support deployment — it's a product requirement.

Leg one: untrusted content

Your support address is published. Anyone can write to it. There's no session, no key, no allowlist, and there cannot be, because the whole point of a support inbox is that strangers can reach you through it.

Willison made this point about email specifically when he introduced the term: a tool with access to your email is a perfect source of untrusted content, because an attacker can simply write to your assistant and tell it what to do. A support inbox is that property, industrialised. It's not one attacker emailing your assistant. It's an open channel processing thousands of messages a day from people you've never verified, where the content of each one lands in a model's context window within seconds of arrival.

Leg two: private data

An agent that can't see the customer's data can't resolve anything. It can acknowledge receipt and route the ticket, which is a mail-sorting tool with an AI budget attached.

Useful resolution means the order record, the billing history, the subscription state, the previous tickets, the CRM notes, and often the shipment tracking from a third party. The 60–80% autonomous resolution rate people quote in this category assumes exactly this depth of access. There is no version of the product where the agent knows less and resolves the same amount.

Leg three: external communication

Here's the one that makes email different from every other support channel, and it's worth dwelling on because people miss it.

In a chat widget, the response is rendered into a session belonging to an already-identified visitor. On voice, it goes down a phone line that was already connected. Email doesn't work that way. Email's entire function is composing a message and dispatching it to an address, and that address is a variable. The channel is an egress path. You don't have to attach a data-exfiltration capability to an email agent, because sending is the capability.

You can't remove a leg. That's the whole problem.

The standard security instinct is to break the chain by eliminating one of the conditions. It works well in other contexts, and it fails completely here, because each leg maps directly onto something the product exists to do.

• Remove untrusted content and you've closed the support inbox. What's left is an internal tool.
• Remove private data access and the agent becomes an FAQ bot that can't tell a customer where their order is. Resolution rates collapse into the single digits.
• Remove external communication and it can't reply. On email, that's the product.

So the honest framing isn't "how do we avoid the trifecta." It's "we are running the trifecta on purpose, and we need to bound what each leg can do."

That reframing is more useful than it sounds. It moves the conversation from a security posture nobody can actually hold to a set of concrete constraints someone can own.

The read-only trap

The most common proposal we hear when this comes up is to make the agent read-only. No writes, no actions, drafts only — a human presses send. It sounds like it clips a leg cleanly and it's often the first thing a security team asks for.

It doesn't clip anything. A read-only agent still reads untrusted mail and still holds private data, and the draft it produces still goes out over email once a human approves it. You've replaced an automated egress path with a human one, and the human is reviewing for tone and correctness, not scanning for a block of account data that shouldn't be in a shipping update. Review fatigue does the rest. After four hundred drafts that were all fine, nobody is reading the four hundred and first closely.

Human review is worth having. It's just worth being clear that it's a quality control, not a containment boundary, and the two get conflated constantly.

The Rule of Two, and what it means for support design

Meta's AI security team proposed a workable formalisation of this: an unsupervised agent may satisfy at most two of the three trifecta properties. Not all three, not without a human in the loop.

Read as a support-design principle, that's genuinely actionable. It says the question isn't whether your agent is safe in general. It's whether each individual workflow keeps all three legs live while running unsupervised, and if it does, whether a human sits in the path.

Apply that to a real queue and the picture separates fast.

An order-status query has untrusted content and private data, but its output is bounded: a shipment state sent to the address on the order. Constrain the destination to the verified account and you've functionally clipped the third leg. Two of three, unsupervised, fine.

A password or account-recovery request keeps all three legs at full strength and adds an authorisation decision on top. This is the workflow where a human gate isn't a nice-to-have. It's the design.

A refund sits in between, and where it sits depends on your own numbers. Under a low value threshold, with the money returning to the original payment method rather than any destination named in the email, the external leg is constrained by the payment rail itself. Above that threshold, or where the refund destination is variable, you're back to three legs and you need a person.

Most teams have never done this exercise workflow by workflow. They evaluate the agent as one object and get one answer, which is how a system ends up with password resets running under the same permission model as delivery questions. Doing it properly takes an afternoon and a whiteboard.

Containment: what to constrain on each leg

Prevention isn't available. Containment is, and it works leg by leg.

On untrusted content: reduce standing, not volume

You can't stop the mail arriving, and filtering it aggressively creates its own problems — the classifier that catches a determined attacker also catches customers who write "ignore my previous message." The more durable move is to strip authority from inbound content rather than trying to catch bad content. Nothing in an inbound email ever establishes identity, entitlement, or policy. A sender address is a claim. A statement about account tier is a claim. Everything the agent acts on comes from your own records. We go deeper into the mechanics in our piece on prompt injection through the support inbox.

On private data: scope per intent, not per agent

The common failure is one credential set covering everything the agent might ever need, with the model choosing correctly. That hands an authorisation decision to a probabilistic system.

Scope it to the resolved intent instead. A delivery query gets that customer's shipment record and nothing adjacent — no billing mutation, no other account, no refund endpoint. Then a misclassification produces a wrong answer instead of a wrong action, which is a category of failure you can live with. This is the same least-privilege logic the Five Eyes agencies pushed in their May 2026 joint guidance on agentic AI, and it's why our write-access integrations are gated per workflow rather than granted wholesale at connection time.

On external send: constrain the destination and inspect the payload

Two controls, both cheap. Replies go to the verified address on the account rather than a reply-to header supplied by the inbound mail. And outbound content gets checked against what the resolved intent should legitimately contain, so an answer about a shipping delay carrying a block of account data trips an alert before it leaves.

Worth remembering that rendered links and auto-fetched remote images are egress too. Real exploits have used both.

What this changes about escalation

Most escalation logic is built around confidence and sentiment. Low confidence, route to a human. Angry customer, route to a human. Both are reasonable and neither is a security control.

The trifecta suggests a third trigger that has nothing to do with how sure the model is: escalate when a workflow keeps all three legs live and the action is irreversible. A confident agent and an uncertain one are equally steerable by a well-crafted injection — confidence measures fit to the input, and the input is what's been tampered with. That's the failure mode people find counterintuitive, and it's why escalation design should account for blast radius alongside confidence.

Practically: money leaving, credentials changing, data deleted, or an address updated on an account. Those get a human or a second verification channel regardless of how clean the ticket looks.

Taking this to a security review

The framing is worth using in vendor conversations because it produces better answers than a generic questionnaire. If you ask "is your AI secure," you'll get certifications. Ask which leg the vendor constrains on each workflow and you'll find out in about ninety seconds whether they've thought about this at all.

Four things worth establishing, and they pair naturally with a broader security checklist for enterprise buyers:

1. Is data access scoped per resolved intent? A single credential set for the whole agent means the private-data leg is never constrained, on any workflow.
2. Where does the reply destination come from? If the answer is inbound headers rather than the account record, the external-send leg is wide open by default.
3. Which workflows run all three legs unsupervised? The vendor should be able to name them. If the answer is "none," they haven't looked.
4. What's logged when a tool call doesn't match the classified intent? This is the signal that catches a successful injection after the fact. Not logging it means never finding out.

Where the framework runs out

The trifecta is a lens, not a compliance standard, and it's worth being clear about what it doesn't cover.

It says nothing about accuracy. An agent can be perfectly contained and still confidently tell a customer the wrong return policy, which is a different problem with different fixes. It doesn't address the regulatory layer either, where disclosure and record-keeping obligations apply whether or not anyone is attacking you. And the containment story gets harder as customer-side AI agents start writing inbound support mail, because untrusted machine-generated content arrives in higher volume and looks structurally cleaner than the human kind.

What the framework does give you is a way to have a specific argument instead of a vague one. That's most of the value.

How Robylon is built against this

Robylon's email support agents resolve 60–80% of tickets autonomously, and the design assumption behind that number is that all three legs are live. The component reading inbound mail doesn't hold execution credentials. Tool access is scoped to the resolved intent rather than granted once per agent. Reply destinations resolve from the verified account record. Irreversible actions route through human-in-the-loop review, and every tool call is logged against the intent that triggered it.

That combination doesn't remove a leg, because nothing can. It makes each one narrow enough that a successful injection buys an attacker very little.

Ready to run email automation you can take to a security review? Robylon AI resolves 60–80% of customer emails autonomously with intent-scoped agents acting across Zendesk, Shopify, Stripe, Salesforce and 60+ other integrations. Start free at robylon.ai