Agents Rule of Two
The Agents Rule of Two states that within a single session an agent should hold no more than two of three properties: [A] processing untrustworthy input, [B] access to sensitive systems or private data, [C] the ability to change state or communicate externally. An agent that needs all three should not run autonomously — it runs under supervision, with human approval on the actions that complete the triple.
Meta published the rule on 2025-10-31 in Agents Rule of Two: A Practical Approach to AI Agent Security, crediting Chromium’s security policy for the structure and Simon Willison’s lethal trifecta for the property set.
Relationship to the Lethal Trifecta
The two framings name the same condition and differ in what they hand the engineer. The trifecta is diagnostic: it explains why a class of attacks works. The Rule of Two is a design constraint: it tells a system designer which property to remove, and it supplies a defined fallback — supervision — for the case where none can be removed.
That fallback is where the rule earns its keep and also where it is weakest. “Operate under supervision” is a real answer only when the supervising human can see the action that matters. In the deployment shapes where all three properties are unavoidable, the human is usually the one who is absent.
Origin in coding agents
A coding agent in continuous integration holds all three properties by construction. It reads issue bodies and pull-request descriptions written by anyone (A), it holds repository credentials and a model API key (B), and it pushes commits and calls out to the network (C). The Microsoft Defender research on the Claude Code GitHub Action (2026-06-05) leads its recommendations with the Rule of Two for exactly this reason, and it puts that formulation ahead of the trifecta as its primary framing.
The interactive shape is different. A developer at a terminal supplies the supervision the rule calls for, which is why the same harness produces a different risk profile depending only on where it runs. See Generative Coding Deployment Shapes for the per-shape breakdown.
Applying It
Removing a property is the whole technique, and each removal has a standard implementation:
| Property to remove | Implementation | Cost |
|---|---|---|
| A — untrusted input | Restrict the agent to repository content from trusted branches; exclude fork pull requests, issue bodies, and external comments | The agent stops doing triage work, which is often the point of deploying it |
| B — sensitive access | Credentials held by a proxy outside the agent boundary; scoped, short-lived, one key per workflow | Requires the credential proxy infrastructure to exist |
| C — state change and egress | Default-deny egress allowlist; agent proposes a diff rather than pushing it | Loses the unattended-completion property that motivated the deployment |
The rule does not resolve the tension it exposes. Every removal costs the capability that made the deployment attractive, which is why organizations reach for supervision as the default answer and why the quality of that supervision — not its presence — is the thing an assessor should test.
Limits
The rule has three limits. It is per-session and says nothing about a property acquired across sessions through persistent memory or a written configuration file, which is the memory-poisoning path. It treats the three properties as binary when each is a gradient — a narrowly scoped token still satisfies B. And it offers no test for whether supervision is real, so a workflow that satisfies the rule on paper by routing every action through an approval prompt no one reads has satisfied nothing.
The rule is a narrowing of least agency rather than a replacement for it. Least agency says strip every capability you can, which requires a capability inventory to act on; the Rule of Two gives an architect a bounded test that can be applied without one. D3 treats it as the design-constraint restatement of the lethal-trifecta test.