The rule breaks when it assumes that missing one risky property meaningfully contains agent behaviour. In practice, untrusted input plus state change, or overbroad permissions alone, can still produce destructive outcomes. Governance has to focus on runtime authority and approval boundaries, not on whether an agent appears to have only two of three properties.
Why the “two of three” rule fails as an AI agent control
The rule of two sounds persuasive because it seems to force balance, if one bad condition is missing, the agent should be safer. The problem is that agent harm is driven by how authority is exercised at runtime, not by how many risky traits you can count. A single untrusted instruction plus write access can be enough, and excessive standing privilege alone can be enough.
That is why governance needs to ask whether the agent can change state, move money, delete data, invoke tools, or delegate onward authority. If the answer is yes, the control boundary has to sit on the action itself, not on a checklist of three properties.
Agent identity and authorisation therefore need to be explicit rather than assumed. Practical guidance is to apply least privilege to AI agents and treat approval gates as part of the operating model, not as a documentary control after the fact.
What actually breaks in practice
The “two of three” framing fails because the dangerous combination is often not the one people expect. An agent can receive untrusted input, then act with legitimate credentials, or it can have broad permissions without needing any malicious prompt at all. Either path can produce destructive outcomes without satisfying the rule’s neat three-part logic.
In other words, the rule confuses structural variety with effective containment. Runtime authority, scope of tool access, and the ability to commit side effects matter more than whether the agent appears to lack one theoretical property.
That is also why zero standing privilege and per-action decisions are more reliable than static labels. If an agent can be verified for each request under zero trust, the boundary is enforced where harm occurs, not where the policy wording is easiest to tick off.
How to govern agents without relying on the rule of two
The safer model is to classify what the agent is allowed to do, then constrain authority to the smallest possible action set. Approval should be tied to material decisions, especially data deletion, external communication, financial transfer, privilege escalation, and cross-system writes. If those actions are possible, the agent is already in a higher-risk class regardless of how many “risk factors” are missing.
This is especially important for agents that operate across multiple tools or environments, because a safe-looking surface can still hide broad downstream effect. A workflow that only reads and drafts may be acceptable; a workflow that can execute, publish, or mutate records needs tighter human or policy mediation.
That operational distinction is captured well in the AI Agent Authorisation Guide, which treats task-scoped access, just-in-time privilege, and human approval as the control points that matter.
Risk and Threat Considerations
Governance that depends on a counting rule creates a false sense of containment. The main risk is that teams approve agents because one risk property appears absent, while the remaining two are still sufficient to enable harmful action, persistence, or lateral movement through legitimate access paths.
Failure mechanism: An attacker supplies or influences input, then relies on standing privileges, tool access, or delegated authority to trigger state change through an otherwise trusted agent path. The agent does not need to “look fully malicious” for the compromise to succeed.
Impact: Destructive writes, data exposure, unauthorised transactions, credential misuse, and hard-to-trace downstream actions can occur under valid identity and policy context, which makes detection and rollback slower.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 addresses the attack and risk surface, while NIST AI RMF, NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Directly addresses runtime privilege misuse by agents. |
| ASI02 — Tool Misuse | Covers harmful outcomes from agent tool access and execution authority. | |
| ASI01 — Agent Goal Hijack | The rule fails when attacker-influenced instructions redirect agent behavior. | |
| Recommendation — Enforce per-action authorization and remove standing agent privilege. Restrict tools to the smallest action set needed for the task. Harden prompts and approval gates against goal hijacking. | ||
| NIST AI RMF | Govern | AI governance and accountability are central to agent authority decisions. |
| Recommendation — Define accountable approval boundaries for agent actions and oversight. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | The issue is excessive agent authority and overbroad permissions. |
| IA-5 — Authenticator Management | Agent authority depends on credential and token lifecycle control. | |
| Recommendation — Limit agent permissions to the minimum required for each task. Rotate and constrain agent credentials so they do not outlive their purpose. | ||
| NIST Zero Trust (SP 800-207) | Policy Decision Point | The answer depends on enforcing authorization at request time, not by static trust. |
| Recommendation — Evaluate each agent action dynamically before allowing execution. | ||
Practitioner Guidance
What to prioritise: Treat runtime authority as the primary control surface. If an agent can write, delete, send, approve, or delegate, scope those powers first, then decide whether the workflow still needs to exist at all.
What to verify: Check whether approval is enforced at the moment of action, not just at onboarding. The control should survive prompt injection, tool chaining, and partial compromise of the agent’s context.
Common mistake: Do not use a “missing one bad property” rule as a proxy for safety. A single broad permission or an unreviewed side effect can outweigh the comfort of a tidy classification.
Practitioner takeaway: The right question is not whether an agent fails a three-part test, it is whether any allowed action can cause material harm before a human or policy boundary can stop it.