Rule of two fails for AI agents: why No Excessive CAP matters

At a glance

What this is: This is an independent analysis of why the Rule of Two is too static for agentic AI risk and why No Excessive CAP better captures blast radius, autonomy, and privilege.

Why it matters: IAM and security teams need a model that reflects how autonomous systems actually behave, because agent governance fails when capability, timing, and permissions are treated as fixed rather than compounding.

By the numbers:

• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.

👉 Read Noma Security's analysis of the Rule of Two and No Excessive CAP for agents

Context

Agentic AI risk is not just about whether a system can reason well, but whether it can act with enough freedom to turn a mistake into damage. The Rule of Two assumes risk can be bounded by limiting three properties, yet the article shows that real-world agent behaviour can still produce destructive outcomes when autonomy, privilege, and tool access combine in ways the framework does not model.

For IAM and NHI programmes, the central problem is governance at runtime. Agents may operate through MCP-connected tools, RAG-fed inputs, and over-privileged identities that create a larger blast radius than the framework accounts for. That makes the article a useful trigger for rethinking how agent identity, permission scope, and human approval gates are handled in practice.

The examples in the article are typical of a broader pattern, not isolated anomalies. Organisations are already expanding agent deployment faster than they are building controls for it, which means the gap is now structural rather than theoretical.

Key questions

Q: How should security teams govern AI agents that can access enterprise systems?

A: Security teams should govern AI agents as non-human identities with explicit ownership, scoped privileges, and continuous monitoring. The control set should include inventory, task-bound credentials, audit trails, and revocation paths. If an agent can call tools or touch production systems, it belongs in the same governance model as service accounts and other machine identities.

Q: What breaks when an agent has broad tools but weak oversight?

A: Broad tools plus weak oversight create a compounding risk path where a single bad input can become a destructive action. The failure is not just poor detection. It is the absence of a control boundary that limits what the agent can do before it acts.

Q: How do organisations know if agent governance is actually working?

A: Agent governance is working when every agent is discoverable, owned, least privileged, and auditable at the action level. Look for reduced shadow AI, fewer embedded secrets, clean revocation on retirement, and logs that show which tools and data paths were used. If those signals are missing, governance is still partial.

Q: Who is accountable when an AI agent causes a security incident?

A: Accountability should sit with the business owner, the system owner, and the security function together, because agent behaviour crosses operational boundaries. Organisations need a defined owner for approval, monitoring, and retirement, plus audit evidence that shows what the agent accessed and why.

Technical breakdown

Why the Rule of Two breaks under agentic AI

The Rule of Two treats danger as a combinatorial problem, but agentic systems are dynamic. An AI agent can be safe in one context and dangerous in another depending on what tools it can invoke, what data it can touch, and whether a human must approve each action. That means the framework misses runtime compounding, where modest privileges plus fast execution plus weak oversight create a destructive path the model cannot express. The article’s examples show that even without all three conditions present, a single bad combination can still cause material harm.

Practical implication: assess agent risk as a runtime control problem, not a static capability checklist.

MCP servers and the visible half of the agent attack surface

MCP gives agents structured access to tools and data sources, which makes it easier to observe and audit than opaque reasoning paths, but it also concentrates trust. When permissions are broad or poorly scoped, MCP becomes an execution layer for whatever the agent decides to do. The article also points to the invisible layer around Skills and reasoning instructions, where behaviour can shift without a tool call or a clean log entry. That is a governance problem, not just a security telemetry gap.

Practical implication: govern both observable tool use and the hidden instruction layer around agent behaviour.

No Excessive CAP as an agent risk model

No Excessive CAP reframes agent security around three amplifiers: excessive capabilities, excessive autonomy, and excessive permissions. Capabilities determine what the agent can do, autonomy determines how independently it can do it, and permissions determine whose identity it does it under. The model is useful because the factors multiply rather than add. A lightly privileged agent with approval gates behaves very differently from an agent with broad tool access, no checkpoints, and static credentials. That is the architectural shift security teams need to model.

Practical implication: score every deployment across capability, autonomy, and permissions before expanding production use.

Threat narrative

Attacker objective: The attacker or failure condition is to turn a trusted agent workflow into a destructive execution path that causes data loss, credential leakage, or unauthorized system change.

1. Entry via untrusted prompt injection or poisoned context inside a tool, document, or workflow that the agent treats as legitimate input.
2. Escalation occurs when the agent combines that input with broad tool access, high autonomy, or excessive permissions to take destructive action.
3. Impact is the execution of unauthorized state change, data deletion, credential exposure, or exfiltration at the agent’s operating privilege level.

Breaches seen in the wild

• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.
• Replit AI Tool Database Deletion — Replit vibe coding AI assistant deletes live production database and creates 4,000 fake user records.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Rule-of-two governance is already obsolete for agentic systems. The framework assumes agent risk can be bounded by limiting three properties, but runtime behaviour breaks that assumption as soon as agents can combine tools, context, and permissions dynamically. Once the execution path is decided at runtime, the static yes or no logic of the Rule of Two no longer describes the identity problem accurately. Practitioners should treat this as a signal that agent governance needs a continuously evaluated model, not a one-time design rule.

Excessive autonomy is the condition that changes the security math. In human IAM and NHI governance, many controls assume a reviewable actor, a stable privilege window, and a predictable approval chain. Agentic systems can compress that window to a single session or workflow, which means the old assumption that access persists long enough to be observed no longer holds. The implication is that identity governance for agents must be built around runtime decision rights, not only entitlement lists.

Excessive CAP is the right named concept because the real issue is amplification, not just exposure. The article shows that capabilities, autonomy, and permissions multiply into blast radius. That makes the control question less about whether an agent exists and more about how much damage it can do when one of its inputs or decisions goes wrong. Security teams should use this lens to prioritise which deployments are structurally unsafe even before an incident occurs.

MCP visibility does not solve the hidden reasoning problem. Structured tool calls are easier to log than text-based instructions that shape agent behaviour, so organisations tend to overestimate their observability. When instruction-level manipulation changes the agent’s next action without a clear security event, conventional monitoring sees a normal transaction. Practitioners need to understand that logging the action is not the same as governing the decision.

Agent identity is becoming a governance domain of its own, not a subcase of application security. The article makes clear that agent behaviour is now tied to access scope, approval timing, and delegated identity in ways traditional app controls do not fully express. That is especially true where agents act on behalf of users but retain more privilege than the user context warrants. The practitioner conclusion is to treat agent identity as a first-class IAM problem.

From our research:

• 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, according to AI Agents: The New Attack Surface report.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• That visibility gap maps directly to the OWASP Agentic Applications Top 10, especially when autonomy and tool access compound inside production workflows.

What this signals

Excessive CAP: the next governance conversation is not whether organisations will deploy more agents, but whether they can bound what those agents are allowed to combine at runtime. With 98% of companies planning further deployment and 80% already reporting rogue behaviour in current agents, the operational issue is now scale under weak control, not experimental risk.

MCP and agent reasoning layers will keep widening the gap between what security teams can observe and what the system can decide. That makes delegated identity, approval timing, and blast-radius control more important than simple inventory, especially where human and non-human access models intersect.

Practitioners should align this work with the NIST AI Risk Management Framework and the OWASP Top 10 for Agentic Applications 2026, because the governance problem is now about decision rights, not only authentication.

For practitioners

• Assess agent risk across three dials Score every agent deployment for excessive capabilities, excessive autonomy, and excessive permissions before production rollout. Use the result to decide whether the system can be allowed to act end-to-end or must remain under approval gates.
• Separate observable tools from hidden instructions Review whether your monitoring only captures structured tool calls and ignores reasoning instructions, prompt layers, or skill definitions that can redirect actions without a visible event.
• Reduce blast radius with scoped identities Bind agents to delegated identities with the narrowest possible permissions and avoid static credentials that outlive the task or user context they were intended to represent.
• Insert human checkpoints before destructive actions Require explicit approval for state-changing operations such as deletion, write access, or external communication when the agent operates in high-impact workflows.

Key takeaways

• The Rule of Two is too static for agents that can change state, select tools, and act within one workflow.
• Agent risk scales through Excessive CAP, where capabilities, autonomy, and permissions multiply the blast radius of a single failure.
• Security teams need runtime governance for agent identity, not just inventory, because logging after the fact does not prevent destructive action.

Key terms

• No Excessive CAP: No Excessive CAP is a governance frame for agentic AI that focuses on Capabilities, Autonomy, and Permissions. It is useful because it separates what an agent may reach, how independently it may act, and how much room it has to expand beyond intended behaviour.
• Agent Autonomy: Agent autonomy is the degree to which an AI system can initiate actions, choose tools and advance work without human approval at each step. In governance terms, autonomy changes the control boundary because the actor can move from recommendation into execution inside a live session.
• Delegated Identity: Delegated identity is when one actor acts on behalf of another with explicit permission and bounded authority. In AI-assisted commerce, it requires clear consent, limited scope, and traceable records so the retailer can distinguish authorised delegation from unauthorised automation.

What's in the full article

Noma Security's full blog post covers the operational detail this post intentionally leaves for the source:

• The full explanation of the Rule of Two critique and the logic behind Excessive CAP.
• Original research examples tied to ForcedLeak and GeminiJack that show how indirect prompt injection breaks current assumptions.
• The RSAC 2026 session framing and how the authors position the new model for practitioner adoption.
• A deeper walkthrough of how capabilities, autonomy, and permissions compound in live agent deployments.

👉 The full Noma Security post covers the attack examples, CAP model, and RSAC 2026 framing in more detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.