The Agents Rule of Two is a design rule from Meta for limiting prompt injection damage. Within one session, an agent should combine no more than two of three properties: it processes untrustworthy input, it reaches sensitive data or systems, and it can change state or communicate externally. If a task needs all three, add supervision.
The three properties
Meta labels them A, B and C.
A: the agent can process untrustworthy inputs. Web pages, inbound email, tickets, documents from outside your company, tool output from a third party.
B: the agent can access sensitive systems or private data. Internal repositories, customer records, a mailbox, a secrets store.
C: the agent can change state or communicate externally. Send a message, call a write API, merge code, make a purchase.
The logic is simple. Prompt injection needs a way in (A), something worth stealing or breaking (B), and a way to do it (C). Remove one leg and the attack chain gets much harder to complete.
The three safe pairs
A and B, no C. The agent reads untrusted content and private data but cannot act or send anything outward. A summarizer over your inbox that can only show text to you is an example. Meta notes you can also limit sending to trusted recipients or have a human approve drafts.
A and C, no B. The agent handles untrusted input and can act, but has no sensitive data or systems to leak or damage. A public support bot that can only post to a public thread is a rough fit.
B and C, no A. The agent has private access and can act, but only ever sees trusted input. An internal job that reads your own database and files your own tickets fits, provided every input source really is trusted. Meta suggests filtering sources, for example by who authored the content.
When you need all three
Meta's position is that an agent with A, B and C should not run autonomously. A human in the loop, or another reliable validation step, has to sit in front of the risky action. Starting a fresh session with a clean context window is another option, because it breaks the chain between untrusted content and the later action.
An agent may also move between configurations inside one session if the exploit chain is broken. For example, it could read untrusted pages with sending disabled, then drop the untrusted content before it touches internal systems.
How to use it in a design review
- List every input channel the agent reads and mark each trusted or untrusted. Be strict: a customer name field in a ticket is untrusted text.
- List every system and dataset it can reach.
- List every action it can take, including indirect ones such as rendering a link that a browser will fetch.
- Mark which of A, B and C the session holds. If it is all three, redesign or add an approval step.
What the rule does not cover
Meta says the framework does not address hallucinations, excessive privileges or misinformation. It also is not a complete defense: a compliant design can still fail if a user blindly confirms a warning. Treat it as a supplement to least privilege, not a replacement.
Where Safeguard fits
Safeguard's policies, gates and MCP Guardrail let you restrict which tools an agent may call, which helps you remove the C leg in practice. Agent identity and asset discovery help you list what each agent can reach. You can also run a free scan at gold.safeguard.sh/scan on code your agents touch.
Quick check
Is a read-only agent safe from prompt injection?
Not fully. A read-only agent with private data and untrusted input (A and B) cannot act, but its output can still mislead a person or leak data through rendered content, so check what it can display or link.
Does the rule replace least privilege?
No. Meta describes it as a supplement to common principles such as least privilege.
Sources
Last reviewed: 19 October 2026.
