The Lethal Trifecta: Closing Agentic AI's Data-Exfiltration Gap

Three conditions, present at the same time, explain almost every “AI agentic gone wrong” story that involves data leaving somewhere it shouldn’t: the agent can read private data, it’s exposed to content an attacker can influence, and it has some way to get information out. Security researchers have started calling this the lethal trifecta. None of the three conditions is avoidable on its own — agents exist to read private data, act on external content, and communicate results — which is exactly why the fix can’t be “remove one of the three.” It has to be observability and control at the layer where the trifecta actually resolves into an action: the credential.

What the lethal trifecta actually is

Strip away the incident-report language and the pattern is always the same three ingredients:

1. Access to private data. The agent holds a credential that can read something sensitive — customer records, internal documents, a mailbox, a codebase.
2. Exposure to untrusted content. The agent processes text it didn’t author and can’t fully vet — a web page, a support ticket, a tool result, a document another user uploaded.
3. A path to exfiltrate. The agent has some way to move information outward — send an email, post to a webhook, write to a public record, call another tool that ends up externally visible.

Any two of these are usually fine. An agent that reads private data and can send email, but never touches untrusted content, is just a normal automation. An agent that reads the public web and can talk back to the user, but never touches private data, has nothing sensitive to leak. It’s the combination of all three that turns a single crafted sentence — buried in a ticket, a document, or a tool’s own output — into an instruction the model follows, because nothing in its context marks that sentence as untrusted.

Why the login handshake doesn’t touch this

It’s tempting to read the lethal trifecta as an authentication problem and reach for a stronger handshake. It isn’t, and a stronger handshake won’t fix it. OAuth, MCP’s connection auth, and the A2A handshake all answer the same question well: is this agent who it claims to be? None of them are designed to answer the question the trifecta actually turns on: given that this agent is legitimately authenticated, should this specific call — with this argument, informed by this specific piece of untrusted content — be allowed to happen right now?

That’s a structurally different check, and it has to run after the handshake, on every call, not once at connection time. We’ve made the same point about MCP tool poisoning: a valid token and a wise decision are not the same thing. The lethal trifecta is the general case of that specific failure — it doesn’t require a poisoned tool description, just an agent doing its job with the ingredients present.

Where observability has to live

Prompt-layer defenses — instructing the model to ignore embedded instructions, filtering obviously suspicious text — help, but they’re advisory. They ask the model to police itself against content specifically designed to defeat that policing, and they leave no record when it fails. The layer that can’t be talked out of enforcing anything is the one outside the model: the point where the agent’s decision becomes a real credentialed call to a real system.

That’s also the only layer where the three legs of the trifecta are all visible at once, in the same place, at the same time:

• What data this call can reach — the scope on the credential being used.
• What triggered it — which agent, which task, and increasingly, which upstream tool result or document the decision traces back to.
• Where the result can go — whether this specific call is an exfiltration path (an outbound webhook, an email send, a public write) or a contained read.

Agentic actions rarely fail in isolation, either — one call triggers another agent, which triggers a third. We’ve written before about why observability and traceability aren’t the same thing for multi-agent AI: observability tells you a call happened, traceability tells you which upstream decision — and which piece of untrusted content — caused it. For a lethal-trifecta incident, traceability is the difference between “an email went out with customer data in it” and “ticket #4821’s pasted error message contained the instruction that made agent B send that email, three hops after agent A read the ticket.”

The business case: closing the trifecta at the chokepoint that already exists

Fullmakt sits in the path of every agent-to-API call as a credential broker, which puts it at exactly the layer the lethal trifecta needs watched. That’s not a coincidence of positioning — it’s the reason the broker pattern exists in the first place:

• Scoped, short-lived credentials, resolved at call time. An agent never holds a standing key wide enough to satisfy an attacker’s whole wishlist. Even if untrusted content successfully steers a call, the credential behind it — scoped to the task, not the integration — limits how much private data that one call can actually reach.
• Policy evaluated per call, on the exfiltration leg specifically. The same policy engine that gates MCP and A2A calls can flag or hold outbound operations — an email send, a webhook post, a write to a new destination — for approval, instead of letting the third leg of the trifecta execute silently just because the first two were already in place.
• A tamper-proof, queryable trail across every hop. Every call Fullmakt brokers is logged with who, what, and under which scope, chained so it can’t be quietly edited after the fact. When a trifecta incident is suspected, “which call moved data out, and what upstream content triggered it” is a query against that log, not a week of stitching together disconnected service logs.
• Human-in-the-loop approval for the calls that matter. Exfiltration-shaped operations — the ones that complete the trifecta — can be routed for a person’s sign-off before they execute, rather than discovered afterward.
• Instant revocation. If a credential turns out to have been used as an exfiltration path, cutting it off is a policy change, not a redeploy, and it doesn’t touch any other agent’s traffic.

The commercial argument is the same one that applies to any control placed at a chokepoint you already own: Fullmakt already sits between every agent and every API for issuance and audit, so adding trifecta-aware policy — flagging calls where private-data access, untrusted-content exposure, and an outbound path line up — doesn’t mean new infrastructure. It means using the gate that’s already there, before the third leg of the trifecta turns a read into an incident.

FAQ

What is the “lethal trifecta” in AI agent security? It’s the combination of three conditions in one agent: access to private data, exposure to untrusted content the agent processes, and a way to send information outward. Present all three together and a single crafted piece of content can turn a legitimate, authenticated agent into an exfiltration path.

Does a strong login handshake (OAuth, MCP, A2A) prevent the lethal trifecta? No. A handshake proves the agent’s identity at connection time. The trifecta plays out afterward, inside individual tool calls the agent makes while doing its job — it requires a per-call policy check, not a stronger connection-time proof of identity.

Is the lethal trifecta the same thing as prompt injection? Prompt injection is the mechanism that usually completes the trifecta — the untrusted content that steers the agent’s decision. The trifecta is the broader condition: injection only becomes dangerous when private-data access and an exfiltration path are also present on the same agent.

How does credential scoping help if the model itself gets fooled? Scoping doesn’t stop the model from being fooled — it limits the damage when it is. A credential scoped to exactly the task’s data means even a successfully steered call can only reach what that credential was ever authorized to touch, instead of whatever the underlying service account can reach.

What’s the single most useful control against this pattern? Policy enforcement on the exfiltration leg specifically — treating outbound operations (sends, posts, writes to new destinations) as the point to check or hold for approval, since that’s the step that turns “the agent read something it shouldn’t have” into “the agent leaked something.”

Most lethal-trifecta incidents don’t involve a hack, a stolen credential, or a broken handshake. They involve an agent doing exactly what it was built to do — read data, process content, act on it — with all three ingredients present and nothing checking the combination. Break that combination at the credential layer, on every call, and the trifecta stops being lethal.