TL;DR: Agentic AI systems are generating 148 times more authentication requests than human users and 60% of enterprises are expected to use AI agents within a year, creating authorization blind spots that legacy RBAC and OAuth cannot absorb, according to PlainID and CSA. Static permissions and context-blind access checks are no longer adequate when agents act at machine speed.
At a glance
What this is: This is an analysis of why agentic AI breaks static access control models and creates a new authorization blind spot for enterprise IAM.
Why it matters: It matters because security teams now have to govern agent identities, delegated actions, and runtime context across AI, NHI, and human programmes without relying on human-speed controls.
By the numbers:
- 60% of enterprises are expected to utilize AI agents within the next year.
- AI agents can generate 148 times more authentication requests than human users.
👉 Read PlainID's analysis of why agentic AI needs dynamic access control
Context
Agentic AI changes access control because the identity making the request is no longer a passive application account following a fixed path. It can choose actions, change behaviour based on runtime input, and fan out across systems in ways that legacy IAM did not model.
That creates an authorization gap for IAM, NHI governance, and emerging agentic AI programmes. Static roles, broad delegated permissions, and human-paced review cycles do not account for an identity that can generate new requests, expand its own task scope, and interact with multiple systems in a single session.
PlainID frames the problem as a mismatch between machine-speed behaviour and static controls. That is the right starting point, because the governance question is no longer whether access exists, but whether the system can decide appropriately in the moment.
Key questions
Q: How should security teams govern access for AI agents that change tasks at runtime?
A: Security teams should govern AI agents with task-scoped permissions, runtime policy checks, and logging that ties each action back to the initiating context. The key is to stop treating agents like static service accounts or human users. When the task changes, the authorisation decision should be re-evaluated before the next sensitive action occurs.
Q: Why do static IAM roles create risk for agentic AI?
A: Static IAM roles create risk because they assume the identity's purpose is known in advance and will not change mid-session. Agentic AI can alter its behaviour, expand its scope, or chain into new tools during execution. That makes fixed permissions too broad and too blunt for safe governance.
Q: What breaks when delegated access is used for autonomous agent workflows?
A: Delegated access breaks down when the organisation cannot tell whether a downstream action still matches the original approved intent. In autonomous workflows, the token may be valid but the action may no longer be appropriate. That creates an accountability gap, especially when sub-agents inherit or reuse authority without fresh checks.
Q: How can organisations tell whether AI agent controls are actually working?
A: Organisations should look for evidence that access decisions are being re-evaluated at runtime, that delegation chains are fully attributable, and that unexpected tool use is flagged before data leaves the authorised scope. If agents can access sensitive systems without a contextual check, the control is not working as intended.
Technical breakdown
Why static RBAC fails for agentic AI identities
Role-Based Access Control assumes the access pattern can be predicted in advance and mapped to a stable job function. Agentic AI does not behave that way. An agent may start with one objective, then change tools, targets, or sub-tasks as new context arrives. If the permission set is static, the security model becomes over-broad by design. The result is not just excess access, but a mismatch between the access model and the runtime behaviour of the identity. In practice, this is why coarse role design becomes a control failure for agents even when it looks acceptable on paper.
Practical implication: define agent permissions around task scope and runtime context, not durable human-style roles.
OAuth and delegated access in autonomous workflows
OAuth is often used to delegate access across applications, but it was not designed to judge whether an agent’s current action is still aligned with the original request. That matters when an agent can take an instruction, expand the request chain, and use delegated authority in ways the issuer never reviewed. The technical issue is not the token itself. It is the absence of contextual authorisation at the moment of use. Once delegated access becomes a standing pathway for an agent, the control surface shifts from authentication to intent and runtime authorisation.
Practical implication: add contextual policy checks before token use, not just at token issuance.
Agent delegation chains and accountability gaps
As agents spawn sub-agents or delegate work to other systems, the identity chain stops looking like a single actor and starts resembling a distributed decision graph. Traditional IAM can record that a valid identity acted, but it often cannot reconstruct which step in the chain changed scope, who authorised it, or which agent caused the final outcome. That creates an accountability problem as much as a security problem. When delegation becomes recursive, the organisation needs visibility into both the initiating identity and every downstream execution path, or the audit trail becomes too weak to support investigation or governance.
Practical implication: instrument delegation chains so each agent action remains attributable to a specific initiating context.
Threat narrative
Attacker objective: The attacker wants to turn a legitimate agent identity into a compliant mechanism for unauthorized access, data exposure, or privilege misuse.
- Entry occurs when an AI agent is granted legitimate access to enterprise data and tools through static permissions or delegated authorization.
- Escalation happens when the agent expands its task scope at runtime, using broad permissions to reach additional systems or sensitive datasets.
- Impact follows when the agent exfiltrates data, performs unauthorized actions, or obscures accountability through chained delegation.
Breaches seen in the wild
- Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
- AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Static access control is the wrong mental model for agentic AI. RBAC and long-lived delegated permissions were built for identities whose access needs are stable enough to predefine. That assumption fails when an agent can change tasks, tools, and execution paths at runtime. The implication is that access control for agents must be treated as a dynamic decision problem, not a role assignment problem.
Confused deputy is now an identity governance problem, not just an application flaw. The article's scenario shows a trusted agent being manipulated into misusing its own authority. That is not simply a prompt-injection issue. It is a governance failure where broad authority and weak context checks allow the wrong party to steer a valid identity. Practitioners need to recognise that delegated authority can become the attack surface itself.
Runtime authorisation blind spot: traditional IAM checks that only validate whether an identity is allowed to act, not whether the action is still appropriate at the moment of execution, fail under agentic behaviour. That assumption was designed for request/response workflows. It breaks when the identity can independently shift from one action to another without a human review gate. The implication is that governance must move from periodic permission review to runtime decisioning.
Accountability weakens as agent delegation becomes recursive. When sub-agents and chained actions enter the picture, the security team can no longer rely on a single owning identity to explain the full event. That complicates investigation, recertification, and policy enforcement across AI, NHI, and human governance programmes. Practitioners should treat delegation lineage as a first-class control objective.
From our research:
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), 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.
- For a broader framework view, OWASP Agentic AI Top 10 helps teams translate agent risk into control priorities.
What this signals
Agent governance is becoming a runtime control problem. The enterprise risk is no longer just that AI agents exist, but that many organisations cannot reliably see what they accessed or why. With 80% of organisations reporting agent behaviour beyond intended scope, the practical signal is clear: governance needs continuous policy evaluation, not annual review cycles.
The category is also converging with broader identity management work. Teams that already manage workload identity, delegated access, and privileged access will recognise the same pattern here, but at higher speed and lower visibility. A useful reference point is the Ultimate Guide to NHIs, especially where machine identities and lifecycle controls intersect.
Runtime authorisation gap: this is the point where identity policy, auditability, and agent oversight meet. If your programme cannot answer what an agent touched, which context approved it, and how delegation was chained, the programme will struggle once agent populations scale toward the next planning cycle.
For practitioners
- Map agent permissions to task scope, not job titles Replace broad, static role grants with narrowly bounded permissions tied to the specific action the agent is allowed to perform and the data it is allowed to touch. Review every agent path for unnecessary inheritance.
- Add runtime policy checks before sensitive actions Evaluate the request in context at the point of use, including data sensitivity, request volume, time of action, and whether the current action still matches the original intent.
- Track delegation lineage across sub-agents Log the initiating identity, each handoff, and every downstream tool call so investigators can reconstruct who caused the final action even when execution is distributed.
- Separate agent governance from human access reviews Do not force agent behaviour into review cadences designed for people. Build controls that can detect scope drift, chained execution, and unexpected resource access in real time.
Key takeaways
- Agentic AI breaks the assumption that access can be safely defined once and reviewed later.
- The evidence points to widespread scope drift, with most organisations already seeing agents act beyond intended boundaries.
- IAM teams need runtime authorisation, delegation lineage, and context-aware controls if they want agent governance to hold up in production.
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 address the attack and risk surface, while NIST AI RMF 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 | Agentic AI runtime behaviour and tool misuse are central to this article. | |
| NIST AI RMF | The article is about governance for autonomous AI behaviour and accountability. | |
| NIST Zero Trust (SP 800-207) | PR.AC-4 | Continuous verification and least privilege are directly challenged by agentic access patterns. |
Use agentic AI threat modeling to map runtime decision points, tool use, and scope drift before deployment.
Key terms
- Agentic AI: Software that can decide what to do next, select tools, and execute actions with limited or no human intervention. In identity governance, it behaves like a dynamic non-human identity whose access must be controlled in motion, not just at provisioning time.
- Runtime Authorisation: An access decision made at the moment an action is about to occur, based on current context rather than only on a prior grant. For agentic systems, runtime authorisation is the difference between checking who the agent was and checking whether the action still makes sense now.
- Confused Deputy Problem: A failure mode where a trusted identity is manipulated into using its legitimate authority on behalf of an attacker. In agentic AI, it appears when the system follows a malicious instruction and uses valid permissions to perform an action the organisation never intended.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or governance in your organisation, it is worth exploring.
This post draws on content published by PlainID: Challenging the Status Quo: Why Agentic AI Demands a New Approach to Access Control. Read the original.
Published by the NHIMG editorial team on 2025-10-03.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org