The Lethal Trifecta Is Now a Checklist Item: Why Agent Architecture, Not Prompt Filtering, Is the Real Security Fix

Simon Willison gave the problem a name, and the name stuck. The "lethal trifecta" describes any AI agent that combines access to private data, exposure to untrusted content, and the ability to communicate externally. If your agent has all three, an attacker can use prompt injection to read private data and exfiltrate it. No novel exploit required. The security implications are structural, not incidental, and the fix is architectural. Bolting a classifier onto a trifecta-violating agent is buying time, not safety.

Key Takeaways

• The lethal trifecta (private data + untrusted content + outbound communication) is a design-time problem. If all three legs exist in the same trust boundary, prompt injection becomes a data-exfiltration primitive.
• Prompt filtering and input classifiers are consistently bypassed by adaptive attacks. A 14-author cross-lab paper tested 12 published defenses and found none reliable against motivated adversaries.
• Architectural patterns like capability tracking, taint propagation, and process-level isolation remove the exploit path before detection is even needed. Production adoption of these patterns remains near zero.
• For high-stakes data classes (health, financial, legal), even Meta's "Rule of Two" (allow at most two of the three legs) may be too permissive. Provable data isolation, not session-scoped heuristics, should be the bar.
• Privacy engineering and security engineering are the same discipline in agent architecture. You cannot bolt privacy onto a system whose trust boundaries already permit exfiltration.

What Is the Lethal Trifecta, Exactly?

It is three capabilities that, individually, are useful and common, but in combination create an exploit primitive. Willison defined them in June 2025: access to private data, exposure to untrusted content where malicious text or images could become available to the LLM, and the ability to externally communicate in a way that could be used to steal data. The point is compositional. Each leg on its own is fine. Two legs are risky. All three together, and an attacker can chain a prompt injection through untrusted content into a read of private data and an exfiltration via outbound communication. The LLM does the attacker's work for them.

This is not a theoretical concern. The June 2025 "EchoLeak" vulnerability in Microsoft 365 Copilot (CVE-2025-32711) was exactly this pattern: hidden instructions in an ordinary-looking email caused Copilot to pull private data and embed it in a link that leaked to an attacker's server. Zero clicks. No user interaction. The email was the untrusted content. Copilot had access to private data. Copilot could embed outbound links. Trifecta complete.

Why Don't Prompt Filters Solve This?

Because the attacker moves second. A classifier or input filter is a static defense against a dynamic adversary. You train a filter on known injection patterns, ship it, and the attacker probes your filter, finds the gap, and rewrites the payload. This is not speculation. A 14-author paper from researchers across multiple frontier labs (published October 2025) examined 12 published defenses against prompt injection and jailbreaking, subjected them to adaptive attacks, and found none that held up reliably. Willison noted he does not share the authors' optimism that reliable defenses will be developed any time soon.

The dynamics here are familiar to anyone who has worked in application security. Signature-based detection (WAFs, antivirus) loses to polymorphic payloads. Heuristic detection (anomaly scoring, behavioral analysis) produces false positives that erode trust in the system. The defender has to be right every time. The attacker has to be right once. Putting a classifier in front of a trifecta-violating agent is the same category of mistake as putting a WAF in front of a SQL-injection-vulnerable application and calling it fixed.

We see this in our own systems. Prompt injection is a real attack surface for any product that processes user-provided or externally-sourced text. We treat it as such. But we also know, from operating in production, that the classifier is not where you want your last line of defense. The classifier is a signal source. The architecture is the defense.

What Does Meta's "Rule of Two" Actually Recommend?

Meta published the "Agents Rule of Two" in October 2025, stating that until robustness research allows reliable detection and refusal of prompt injection, agents must satisfy no more than two of the three trifecta properties within a session. Willison called it "the best practical advice for building secure LLM-powered agent systems today in the absence of prompt injection defenses we can rely on."

The framing is useful. It gives engineers a concrete design constraint: pick two. If your agent reads private data and ingests untrusted content, strip its ability to communicate externally. If it needs to send emails and process untrusted web pages, do not give it access to your CRM. This is a real improvement over the status quo, where most agent harnesses cheerfully combine all three.

But "two out of three" is a budget, not a proof. And for certain data classes, the budget is still too generous.

Is "Two Out of Three" Enough for High-Stakes Data?

No. Consider a health-data agent that has access to patient records (leg one) and processes untrusted clinical documents (leg two) but has no outbound communication (leg three removed). The attack surface is reduced, but the remaining two legs still permit data corruption: a malicious clinical document could cause the agent to misclassify a diagnosis or alter treatment recommendations in memory. Exfiltration is blocked, but integrity is not.

Or take a financial agent with access to transaction data (leg one) and outbound communication (leg three) but no untrusted content (leg two removed). Now you need to guarantee that no untrusted content ever enters the agent's context. Every data source, every API response, every tool output must be trusted. In practice, "no untrusted content" is a claim about the entire supply chain, and supply chains are leaky.

This was demonstrated concretely when a package called postmark-mcp shipped fifteen clean versions to build legitimacy before quietly adding exfiltration code. A separate campaign injected backdoored builds of a popular LLM proxy library into PyPI. When the supply chain itself is the untrusted content, every downstream agent inherits the trifecta whether you designed for it or not.

Removing a leg migrates risk rather than erasing it. Each removed leg creates a new high-value target (a token resolver, a sandbox boundary, an allowlist) that must itself be hardened. For health, financial, and legal data, the bar should be provable data isolation across process boundaries, not session-scoped heuristics about which legs are active.

What Does an Architectural Fix Look Like?

The most concrete proposal so far is CaMeL, published by a major frontier lab's research division in April 2025. CaMeL moves beyond model training or simple filters to an architectural defense that applies established software security ideas: capability tracking, control flow integrity, and taint propagation. The idea is that once an agent ingests untrusted tokens, those tokens are "tainted," and the system deterministically blocks any tainted data from reaching an outbound channel without human approval.

On the AgentDojo benchmark, CaMeL successfully defended against 67% of prompt injection attacks across various models, often reducing successful attacks to zero for specific model configurations. The tradeoff: CaMeL typically requires around 2.7 to 2.8 times more tokens compared to standard LLM tool use. That is a real cost. But compare it to the cost of a successful exfiltration of your customers' private data.

Willison has also proposed treating exposure to untrusted content as a "taint event": once an agent ingests attacker-controlled tokens, the rest of that turn should be assumed compromised. This suggests a deterministic mitigation where taint tracking plus policy gating blocks or requires human approval for any action with exfiltration potential. Not a classifier. Not a filter. A hard architectural boundary.

Why Hasn't Anyone Shipped This?

Because it is expensive, complex, and breaks the ergonomics that make agents feel useful. As of mid-2026, no production-grade CaMeL implementation exists, and not a single mainstream agent harness has adopted these patterns. The gap between the security research community (which has converged on architectural fixes) and the product engineering community (which ships agent features as fast as possible) is wide and growing.

The practical tactical patterns being deployed now are stopgaps. A May 2026 analysis from Sophos describes volume thresholds on outbound requests, web categorization and domain allowlisting, and egress allowlisting bound to canary tokens. These are described, correctly, as blast-radius reduction measures while architectural fixes mature. They help. They are not the fix.

How Should You Think About This If You're Building an Agent System Today?

Start with the trifecta as a literal checklist. For every agent you build or deploy, answer three questions:

1. Does this agent have access to private data? (User files, database queries, API credentials, conversation history.)
2. Does this agent process untrusted content? (Web pages, emails, user-uploaded documents, tool outputs from third-party APIs, MCP servers, packages from public registries.)
3. Can this agent communicate externally? (Send emails, make HTTP requests, write to external APIs, generate links, produce outputs that will be rendered in a browser.)

If the answer to all three is yes, you have the lethal trifecta. No amount of prompt filtering changes that. You need to break at least one leg architecturally, meaning at the process level, with separate credentials, separate network policies, and separate trust boundaries.

What Specific Patterns Should You Implement?

Here is what we think is practical today, based on what we have learned operating our own systems:

Separate processes with no shared credential surface. The data-access layer, the untrusted-content-ingestion layer, and the outbound-communication layer should run in separate processes. They should not share API keys, database credentials, or session tokens. If the untrusted-content process is compromised, it should have no credential that lets it reach private data or send outbound traffic. This is standard principle-of-least-privilege, applied to agent components rather than microservices. It is not novel. It is just rarely done.

Taint tracking at the data layer. If a piece of data originated from or was influenced by untrusted content, mark it. Propagate the mark. Block tainted data from reaching outbound channels without explicit human approval. This is conceptually identical to taint tracking in Perl or PHP, applied to LLM context windows instead of web request parameters. The implementation is harder because LLM context is unstructured text, but the principle is the same.

Egress filtering that is default-deny. Your agent should not be able to make arbitrary outbound requests. Allowlist the domains and endpoints it can contact. Bind the allowlist to specific tool invocations. Log every outbound request. Alert on deviations. This is table stakes in traditional application security. It is almost never done in agent deployments.

Human gates on high-consequence actions. Any action that could exfiltrate data (sending an email, making an API call to an external service, generating a URL) should require human confirmation if the agent's context includes untrusted content. Yes, this adds friction. The alternative is EchoLeak.

Why Are Privacy Engineering and Security Engineering the Same Discipline Here?

Because the threat model is identical. A privacy failure in an agentic system (user data leaks to an unauthorized party) and a security failure in an agentic system (an attacker exfiltrates data via prompt injection) are the same event, reached via the same mechanism. The fix is the same too: architectural isolation that makes the exfiltration path impossible, not just improbable.

Most trifecta commentary treats this as a security problem. It is equally a privacy problem. If your agent can read a user's private messages and also process an attacker-controlled email and also generate outbound links, you do not have a security vulnerability. You have a privacy architecture that permits exfiltration by design. The distinction matters because privacy-by-design is a regulatory requirement in most jurisdictions, and OWASP's June 2026 report tracks 42 regulatory instruments across 10 jurisdictions that apply to agentic AI systems. DORA gives a four-hour notification window for major incidents. NIS2 requires 24-hour early warning. You do not want to be filing those notifications because your agent architecture permitted a class of exfiltration that was well-understood and preventable.

OWASP's report makes a point worth sitting with: the central security weakness of these systems may not be a bug that a future release fixes. It may be structural. Prompt injection maps to six of the ten categories in OWASP's Top 10 for Agentic Applications. If the vulnerability is structural, the fix must be structural too.

What Does This Mean for "Filtering Vendors" vs. "Architecture Vendors"?

They are structurally different products. A classifier or prompt firewall is inherently reactive: it observes inputs, compares them to known-bad patterns, and blocks matches. Adaptive attacks bypass classifiers because the attacker can iterate faster than the defender can retrain. A monitoring system on the same agent produces alerts after the fact, which is useful for forensics but not for prevention.

Architectural isolation removes the exploit path before detection is even needed. If the outbound-communication process has no credential to access private data, there is nothing to exfiltrate regardless of what the attacker injects. The classifier does not need to catch the injection because the injection cannot reach the data.

This is not an argument that classifiers are useless. They are a signal source. They contribute to defense in depth. But a classifier in front of a trifecta-violating agent is analogous to an intrusion detection system in front of a server running as root with no firewall. The defense is real. The architecture is still broken.

We build with this distinction in mind. At Selina, content is encrypted, and files and transfers via SelinaSEND are end-to-end encrypted. Memory is NOT end-to-end encrypted (a slice of each request reaches a frontier provider at inference, and we state that plainly). Non-content operational metadata is kept for a short retention window. We route requests across a stack of frontier models, routed per task, and we treat every inference call as a potential exposure surface. This shapes how we architect data access, not as an afterthought, but as the primary design constraint. The point is not that we have solved the trifecta (we have not; nobody has). The point is that the trifecta is an architectural problem and we treat it as one.

What Should the Industry Do Next?

Ship the architectural patterns. CaMeL demonstrated feasibility. The token cost overhead is real (roughly 2.7x) but will decrease as inference costs continue to fall. The Sophos analysis frames three defensive lines: preventing injection via input filtering (which adaptive attacks consistently bypass), architectural separation via dual-LLM and taint-tracking patterns (not yet adopted by mainstream harnesses), and assuming breach of the LLM while containing blast radius through process boundaries, credential isolation, egress filtering, human gates, and audit.

The industry is currently stuck between line one (filtering) and line three (assume breach). Line two is where the real work is, and almost nobody is doing it in production.

The scale of the problem is growing. A study of a major web crawl repository found prompt injections embedded in public web pages, ranging from harmless pranks to SEO manipulation to data exfiltration attempts, with a 32% increase in malicious attempts between November 2025 and February 2026. Every agent that crawls the web is ingesting untrusted content. If it also has access to private data and can communicate externally, it is a target.

The lethal trifecta is no longer a warning. It is a checklist. Run it against every agent you build. Break at least one leg architecturally. And do not let a classifier convince you the architecture is fine.

If you want to see how we approach this in practice, start a free 7-day trial, no card required.

Michael C.

Founder & Principal Engineer, Selina Labs

Michael builds Selina, a privacy-first AI that remembers you across conversations. He ships security-sensitive AI in production — real attacks, real fixes, measured in minutes and dollars — and writes about privacy, security, and LLMs from that seat. Top Rated Plus and expert-verified on Upwork.

• www.upwork.com
• x.com
• medium.com
• selinalabs.io