Why can't smarter system prompts solve the lethal trifecta problem?
Because the problem isn't that the agent "isn't smart enough" — it's that LLMs fundamentally lack a hard structural boundary, like a database has, that clearly separates "this is an instruction" from "this is data." A System Prompt is just one input among many, ending up as tokens the model interprets the same way it interprets email content or webpage text. If an attacker makes malicious content look enough like a legitimate instruction, the model may follow it. The strongest published detection method achieves roughly 97% accuracy against known attack patterns — meaning about a 3% miss rate — but for a risk that only needs to succeed once to exfiltrate everything, any non-zero failure rate isn't a real safety Margin.
This is why the lethal trifecta framework targets architecture rather than prompting: instead of trying to teach the model to never be fooled, it makes some link in the chain physically impossible to complete — a deterministic defense, not a probabilistic one.
Shouldn't the human-approval steps in IBM Bob and Notion AI have blocked these attacks?
That's exactly what makes these two incidents worth paying attention to — both systems had human-approval mechanisms in place, but the approval mechanism itself had a flaw. IBM Bob's issue was that once a user set "always allow" on a seemingly harmless command, the agent chained that approval onto a series of subsequently more dangerous operations — a mismatch between what was approved and what actually got executed. Researchers described this as the human-in-the-loop check becoming "security theater": the approval action genuinely happened, but what it verified didn't match the high-risk operation that actually needed verifying. Notion AI's issue was a timing flaw: AI-made edits were already written to storage before the user pressed approve, meaning the data change may have already occurred even if the user ultimately clicked reject.
The lesson here is that for human approval to be genuinely effective, what gets approved and when has to precisely correspond to the actual risky action — not just a checkbox that exists in form but not in substance.
Meta's "Rule of Two" sounds like it would limit an agent's functionality — what's the actual tradeoff?
That tradeoff genuinely exists, and Meta acknowledges in its own framework description that strictly following the Rule of Two can cost some user experience — but that's a deliberate design choice, not a flaw. For example, an agent that helps a user manage their inbox, if it simultaneously has the ability to read the inbox (private data) and auto-reply (external communication), becomes a structurally high-risk design the moment it reads an email carrying a malicious instruction (untrusted content) — all three properties are now satisfied. To break this combination, you could change auto-reply to "draft first, send only after user confirmation" — the agent still appears to have all three capabilities on the surface, but the "external communication" leg now requires human involvement to actually complete, effectively redrawing the two-of-three boundary within a single session.
This means the Rule of Two isn't asking developers to cut a feature — it's asking them to figure out which of the three capabilities can have a human or architectural gate inserted into it. Where that gate goes determines how much convenience users give up in exchange for how much deterministic safety they get.
How can an organization turn the lethal trifecta checklist into a process that's actually enforced, rather than a document written once and shelved?
The key is embedding the checklist into existing procurement and launch-review workflows, rather than creating a separate document people can choose to skip. A practical approach is adding a required field to every agent project's architecture design document: for each possible execution path, explicitly mark whether it has private data access, untrusted content exposure, and external communication. If any single path satisfies all three, the document must include a concrete mitigation plan before it can pass launch review — similar to how security reviews have long required a penetration test report attached, turning an abstract sense of risk into a specific checkpoint that can actually fail.
Another detail that's easy to overlook is that auditing frequency can't be a one-time event at launch. Agent systems commonly accumulate new capabilities after launch — an agent that could originally only read data might, months later, gain the ability to send notifications, and that addition could quietly push it from "two properties" to "three" without ever passing through the original architecture review. The checklist needs to be tied to every change request that adds a new permission or tool, not just a one-time assessment at project kickoff. Without that ongoing mechanism, a lethal trifecta checklist easily becomes a document that was "safe on launch day, unclear whether it still holds six months later."
In June 2025, independent researcher Simon Willison named a pattern he'd observed recurring across incident after incident: whenever an agent simultaneously has access to private data, exposure to untrusted content, and the ability to communicate externally, data exfiltration becomes nearly inevitable. He called this combination the "lethal trifecta." The framework matters not because it uncovered some new vulnerability, but because it converted a vague, hard-to-communicate risk into something you can directly check off against a list.
The first property is access to private data — the agent can read confidential documents, internal databases, a user's inbox, or hiring records. This is the access range that makes an agent useful in the first place; an agent that can't touch any data at all is nearly worthless. The second is exposure to untrusted content — the agent processes external input such as emails, webpages, or documents uploaded by others, any of which might hide a carefully crafted attacker instruction. The third is the ability to communicate externally or cause side effects — the agent can send emails, call outside APIs, write to databases, or take any action that changes state inside or outside the system. Some security teams have refined this further, pointing out that the real property is the capacity to create side effects, not literally "external communication": an instruction that quietly renames every project in a workspace is the same class of problem as one that exfiltrates data to an attacker's server.
None of the three properties is a problem on its own: an agent that can only read private data but never touches external content and can't act externally is safe; an agent that processes external content but can't reach any private data has nothing to steal even if it's injected; an agent that can communicate externally but only ever sees fully trusted, controlled input has no exploitable opening either. Only when all three hold at once can an injected instruction complete the full chain — read a fake instruction, access real data, ship it out. This is also why the security community broadly agrees that smarter system prompts or detection classifiers alone can't fully solve the problem — the strongest published detection method achieves roughly 97% accuracy against known attack patterns, which sounds high, but still means about 3% of attacks get through, and for a risk like data exfiltration that only needs to succeed once, that miss rate isn't good enough.
In January 2026, security research team PromptArmor publicly disclosed two independent incidents within five days, both fitting the lethal trifecta pattern exactly. The first involved IBM's coding agent Bob: an attacker hid instructions disguised as "phishing training" inside a README file in an open-source project. When Bob read it, it began repeatedly requesting the developer's approval for a seemingly harmless command; once the developer, worn down by the repeated prompts, clicked "always allow," Bob chained subsequent, more dangerous operations onto that now-approved command, eventually downloading and executing malware without any further human approval. The second involved Notion AI: a timing flaw in its document-editing feature meant AI-made edits were written to storage before the user's approval was captured. An attacker used indirect Prompt Injection to get Notion AI to read a disguised document and exfiltrate a user's confidential hiring-tracker data; Notion confirmed and shipped a fix after the disclosure. Neither attacker needed to bypass a login or find a code exploit — both were simply the natural outcome of all three lethal-trifecta properties being present at once.
In October 2025, Meta's AI security team publicly published a practical framework built on top of the lethal trifecta, called the "Rule of Two": an agent, within a single session, may satisfy at most two of the three properties — never all three. This can be implemented through three concrete configurations: let the agent process untrusted content and communicate externally, but give it no access to private data at all (running in a sandbox, so an injection has nothing to steal even if it succeeds); or let the agent access private data and process untrusted content, but require every outbound send to be confirmed by a human reviewing the draft first; or let the agent access private data and communicate externally, but strictly limit it to fully trusted, controlled input sources. Each configuration sacrifices some flexibility, but all three ensure that even if an injection occurs, the attack chain is physically broken at some point — rather than relying on a classifier to guess whether a piece of text looks suspicious.
If your organization is deploying agents with data access, the lethal trifecta checklist turns a vague risk into something you can audit and sign off on item by item — list whether each agent satisfies all three properties on any single execution path; if the answer is yes to all three, that's a structurally vulnerable design that needs priority attention, not something to investigate only after an incident. This also bears directly on accountability: a document stating clearly "we knew this agent had a lethal trifecta and accepted the risk because of mitigation X" represents an entirely different level of governance responsibility than deploying without ever assessing it — the former is informed risk acceptance, the latter is negligence that can be held accountable. Breaking any one leg of the trifecta costs some flexibility or user experience, but compared to a single real data exfiltration incident, that trade is usually well worth it.