> ## Documentation Index > Fetch the complete documentation index at: https://ai.brokenguardrail.com/llms.txt > Use this file to discover all available pages before exploring further. # Agents Rule of Two > A design principle that limits an agent session to two of three risky properties, cutting the prompt injection exfiltration chain by construction The most cited framing of data leak risk in AI agents is Simon Willison's [The Lethal Trifecta](https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/). Meta's [Agents Rule of Two](https://ai.meta.com/blog/practical-ai-agent-security/) turns that threat into a practical countermeasure. This page lays out the risk the former identifies and the defense the latter prescribes, then adds three considerations for applying them to a real agent platform. ## The Lethal Trifecta When an AI agent holds all three of the following capabilities at once, an attacker can trick it into stealing private data. * Access to private data * Exposure to untrusted content * A means of communicating externally The cause lies in the nature of LLMs themselves. An LLM follows the instructions in its context, but it can't reliably tell whether an instruction came from the operator or was planted in a web page or email it read. Everything ultimately reaches the model as a single token sequence. Writing prohibitions into the prompt guarantees nothing, because a nondeterministic system won't obey them every time. This attack is not hypothetical. It has been reported repeatedly against production systems, including Microsoft 365 Copilot and the official GitHub MCP server. Vendors fixed each case by closing the exfiltration path, but now that MCP lets users assemble their own tool combinations, whether a given combination satisfies all three conditions is the user's own responsibility. The original article concludes that **the only reliable defense is to avoid configurations where all three come together**. ## Agents Rule of Two Meta converted this analysis into an implementable principle: until prompt injection can be reliably detected and refused, an agent must satisfy no more than two of the following three properties within a single session. 1. Process untrusted inputs 2. Access sensitive systems or private data 3. Change state or communicate externally If a task requires all three, don't allow autonomous operation. Insert trusted validation, such as human-in-the-loop approval. What you're protecting is the break in the attack chain where an instruction injected through the first property reaches data through the second and carries it out through the third. As long as that break holds, you can even switch configurations one way mid-session, for example disabling external communication before accessing internal systems. Satisfying the Rule of Two complements existing principles like least privilege rather than replacing them. Meeting it still leaves other risks, such as excessive permissions and agent malfunction. ## Three considerations for operation Both principles are simple, but applying them to a real agent platform raises more questions. Three points deserve particular attention. ### Enforce at a deterministic layer Start from the premise that prompt injection can't be prevented completely. That is exactly where the Rule of Two earns its value: it's a deterministic rule that doesn't depend on the model's judgment. But you can't uphold it by glancing at a tool list and counting to two. An agent can attempt unauthorized communication with commands like `curl`, so the third restriction has to be implemented as an allowlist at the network layer. A credential-injecting proxy goes further, letting the agent hold no credentials at all, so even poisoned instructions have nothing to leak. The rule only works once it's enforced at an execution layer the agent cannot route around. You should also account for how attacks are shifting. As prompt filtering products matured, attacks moved away from easily detected instruction overrides toward manipulation shaped like legitimate instructions. Industry standards now reflect this. Prompt injection, once first on the OWASP LLM Top 10, was renamed Agent Goal Hijack in the OWASP Top 10 for Agentic Applications 2026 and redefined not as a single malicious input but as an attack that hijacks the agent's goals and plans themselves. An agent with hijacked goals believes it is still pursuing the user's objective while autonomously executing multi-step actions toward the attacker's. The more a design relies on inspecting and sanitizing the first property's inputs, the harder this shift hits it. The Rule of Two's idea of defending through configuration rather than inspection holds up well here too. ### Don't rely on human-in-the-loop alone When a task needs all three properties, human-in-the-loop approval is the validation mechanism that comes up first. But approvals that fire too often cause approval fatigue, and users end up clicking yes without judging anything. That is validation in form only. The design has to allow autonomy for behavior whose safety is assured and reserve approval for irreversible actions like external transmission and deletion. Human approval isn't the only validation mechanism either. In high-risk domains such as AI browsers, a guardian agent configuration is becoming standard: a small agent, separated from the main one, verifies the legitimacy of proposed actions before execution. The User Alignment Critic in Gemini in Chrome is a working example. A separate model judges whether each planned action serves the user's original goal, and if it deviates, rejects it and forces a replan. The key is to isolate this verification agent from untrusted content. It receives only trusted inputs, namely the action's metadata and the user's original instructions, and never sees raw content fetched from the web. If the verifier can be poisoned through the same path, the layered defense itself collapses. The verification agent can still become a target, so never treat its approval as the sole basis for a decision. Combine it with deterministic policy for the final call, and fail closed when it doesn't respond. ### Design the second property to include attribution The Rule of Two governs the combination of capabilities within a session. It says nothing about who those permissions belong to. An agent built on a shared machine user leaks confidential data to a legitimate user asking a legitimate question, even with the first and third properties fully closed off. That is the territory of the [Confused Deputy Problem](/risks/confused-deputy-problem). Conversely, when authority is correctly bound to the requester, even a successful prompt injection can't push the agent beyond that requester's permissions. Who can see the agent's output also determines effective access. The scope of the second property is only settled once it covers delegation of the requester's authority and the visibility of the output destination. ## References * [The lethal trifecta for AI agents: private data, untrusted content, and external communication](https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/) * [Agents Rule of Two: A Practical Approach to AI Agent Security](https://ai.meta.com/blog/practical-ai-agent-security/) * [Architecting Security for Agentic Capabilities in Chrome](https://security.googleblog.com/2025/12/architecting-security-for-agentic.html) * [OWASP Top 10 for Agentic Applications for 2026](https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/) * [AI Security Challenges in 2026](https://hi120ki.github.io/blog/posts/20260103/) * [Action Items for Agent Platform Security](https://hi120ki.github.io/blog/posts/20260223/)