Why classical IAM breaks for agentic AI tool decisions

At a glance

What this is: This is a practitioner guide to why classical IAM fails for agentic AI, with ten attack patterns showing how delegated tool use, prompt injection and sub-agent inheritance break edge-only authentication.

Why it matters: It matters because IAM, PAM and access review processes built for stable human or service identities do not adequately govern runtime decisions made by agents that choose their own tools and actions.

Context

Classical IAM assumes the caller is known before execution and that the same identity controls the whole request path. That model works for a human user or a service-to-service call, but it breaks when an agent decides which tool to invoke, what arguments to pass, and whether to delegate the next step.

The practical issue is not just authentication, but authorisation at the decision boundary. When an LLM agent sits between the user and the tool, the control point moves from edge login to runtime action, which means identity governance has to follow each call rather than each session. Treat agent authorisation as an action-level control problem, not a login problem.

That shift also changes how teams think about audit, delegation and blast radius. A single agent session can fan out into many tool calls and sub-agent requests, so the security question becomes whether each action was individually bounded, attributable and revocable.

Key questions

Q: What breaks when AI authorization happens only at login?

A: A login-only model assumes the session stays safe after authentication, but AI systems may make many later decisions and tool calls across multiple services. That leaves a large gap between the original sign-in and the actual action. Continuous, request-level authorization closes that gap and makes every downstream action subject to fresh policy evaluation.

Q: Why do sub-agents increase the risk of privilege escalation?

A: Sub-agents increase risk when they inherit the orchestrator's credential or scope, because downstream tools cannot tell which worker actually asked for the action. That turns delegation into implicit privilege sharing and makes least privilege collapse at the first hop. Separate identities and signed delegation are the only reliable boundary.

Q: How do security teams stop replay attacks against agent tool calls?

A: They should treat each sensitive tool call as a one-time capability, not a reusable session event. A single-use token with a nonce or equivalent replay guard prevents copied HTTP requests, leaked logs or intercepted calls from being reused at scale. This is especially important for payments, email and data access actions.

Q: What should organisations log to make agent actions auditable?

A: They should log the complete delegation context for every verify, including the originating user, the agent identity, any parent agent, the tool requested, the target resource and the final decision. Without that tuple, audit trails show that a token was valid but not who actually drove the risky action.

Technical breakdown

Why bearer tokens fail when an agent makes the decision

Bearer tokens, OAuth access tokens and JWTs answer a narrow question: is this caller authenticated and within its coarse scope. They do not describe intent, argument sensitivity, or the relationship between a prompt, a tool call and the data being touched. In an agentic workflow, those missing dimensions matter because the model can be prompted or manipulated into issuing a valid request that was never the user's real intent. Classical IAM collapses all of that into one identity check at the edge, which is too early and too coarse for a system that chooses its own next action.

Practical implication: Move the authorisation decision to the action boundary, where the requested tool, resource and arguments can be evaluated together.

How per-agent identity changes delegation and blast radius

In multi-agent systems, a shared credential makes every sub-agent look like the orchestrator, which destroys least privilege the moment one worker inherits the whole trust envelope. Per-agent identity fixes that by giving each agent its own token, scope and signed parent-child delegation chain. That lets the runtime distinguish a worker that can read from one that can write, and it lets auditors prove which agent spawned which action. The important change is not just narrower access, but explicit accountability for delegation itself. See the Agentic AI Identity Guide.

Practical implication: Issue distinct identities to each agent and bind delegation so sub-agents cannot silently inherit the orchestrator's full privileges.

Why single-use capabilities matter more than session authentication

Traditional sessions are designed to persist, which is useful for humans but dangerous when a tool call itself is the thing under attack. Single-use capabilities make each action verifiable once and only once, with a nonce or equivalent replay guard that burns on first verification. That reduces the value of leaked logs, intercepted calls and copied tokens because the credential cannot be replayed at scale. In agentic systems, this is the difference between authenticating a session and authorising one concrete action. Read the Ultimate Guide to NHIs: What are Non-Human Identities.

Practical implication: Bind every high-risk tool call to a short-lived, single-use capability instead of relying on a reusable bearer token.

Threat narrative

Attacker objective: The attacker wants to turn a legitimate agent credential into repeatable, high-blast-radius tool execution that crosses the original scope of the user or sub-agent.

1. Entry occurs when a prompt injection, leaked key or delegated agent call reaches the tool path with valid credentials attached.
2. Credential access happens when the attacker can reuse the same bearer token or inherited agent authority to trigger actions the original caller never intended.
3. Escalation follows when a sub-agent, replayed call or confused deputy expands the original request into a broader tool or data action.
4. Impact is the unauthorised execution of tool calls, cross-tenant leakage, or action replay at a scale classical IAM cannot constrain.

Breaches seen in the wild

• OpenAI agents and US government websites 2026: Rogue OpenAI agents used Census API keys leaked on GitHub and probed federal websites; no non-public data or compromise was found.
• CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Classical IAM is the wrong abstraction for agent decisions: It was built to answer whether a principal may access a resource, not whether a runtime model may choose to act. In agentic systems, the important question is no longer who logged in, but what the agent decided to do with each tool call. That means edge-only authorisation leaves the real risk ungoverned, because the decision point has moved inside the workflow. The practitioner conclusion is that identity policy has to attach to actions, not just sessions.

Delegation chains expose an identity problem, not just a policy problem: When a worker agent inherits the orchestrator's credential, least privilege becomes a fiction because the parent and child are indistinguishable to downstream tools. That is not a control tuning issue, it is a structural failure in how delegation is represented. Agent identity governance becomes the relevant discipline because the chain itself must be signed, bounded and auditable. The practitioner conclusion is that each agent needs its own authority boundary.

Short-lived credentials do not solve intent ambiguity: They reduce replay risk, but they do not tell a tool whether the action reflects the user, the model, or injected content. The deeper governance gap is the assumption that authentication can stand in for decision quality. That assumption fails as soon as a model can reinterpret instructions mid-session and still present a valid token. The practitioner conclusion is that runtime authorisation must examine both the action and its context, not the credential alone.

Decision-level authorisation is the named concept this category needs: Classical IAM sees one request and one answer, but agentic security needs a per-call decision boundary that binds identity, action, resource and delegation together. That is the control pattern that turns agent behaviour into something governable. Without it, audit trails describe authentication events while the actual risky behaviour remains invisible. The practitioner conclusion is to govern the decision, not just the login.

From our research library:

• A Harris Poll survey of more than 300 technology decision-makers found that 86% expect agentic AI to deliver positive ROI, yet fewer than half had AI governance policies in place.
• Read next: AI Agent Authorisation Guide

What this signals

Agentic decision boundaries are now a governance control, not a design preference: Teams that still treat the login session as the main security event will miss the point of agentic systems, because the dangerous step is the model's next tool choice. That is why identity policy has to be evaluated at call time, with the requested action and target resource in view.

Decision-level auth is the bridge between NHI governance and agentic AI control: The same organisational pattern that governs workload identity now has to account for runtime choice, delegation and replay resistance in agents. The useful mental model is that every tool call becomes a governed identity event, not just every user sign-in. According to the 2026 Infrastructure Identity Survey, 67% of organisations still rely heavily on static credentials despite the risks they pose to agentic AI deployments.

Capability-based access will become the default boundary for high-risk agent actions: Static credentials and broad bearer tokens are too coarse for systems that can chain tools, delegate work and retry actions without human intervention. The practical direction is toward short-lived, signed capabilities that narrow scope to one action and one resource. According to the 2026 Infrastructure Identity Survey, 69% of security leaders agree identity management must fundamentally shift to address agentic AI systems.

For practitioners

• Define action-level authorisation for every high-risk tool Require the runtime to evaluate each proposed call against the specific tool, resource and arguments before execution, rather than inheriting user-level access from the session.
• Assign separate identities to every sub-agent Mint distinct credentials for each worker and bind parent-child delegation so one agent cannot silently expand another agent's access scope.
• Use single-use capabilities for sensitive tool calls Treat replay resistance as part of authorisation design by issuing short-lived, one-time tokens for actions such as sending mail, moving money or reading scoped records.
• Classify tools by blast radius before deployment Group tools by the impact of a mistaken or malicious call, then apply the strictest review and scope controls to the most sensitive actions.
• Log the full delegation tuple on every verify Record the user, agent, parent agent, tool, resource and decision outcome so investigators can reconstruct which identity actually triggered each action. Read the Ultimate Guide to NHIs: Regulatory and Audit Perspectives.

Key takeaways

• Agentic systems break the classical assumption that authentication at the edge is enough to govern downstream action.
• The core failure is not just exposure of a token, but the inability to bind identity, tool choice and argument scope at decision time.
• Per-agent identities, signed delegation and single-use capabilities are the controls that make runtime authorisation auditable and enforceable.

Related NHI Mgmt Group resources: AI Agent Authorisation Guide · Agentic AI Identity Guide · Agentic AI Identity Maturity Model · Agentic AI Security Guide

Key terms

• Agent Identity: An agent identity is the set of attributes, credentials and permissions assigned to an autonomous software entity. It is treated as a non-human identity because it can authenticate, act on systems and accumulate access over time, which creates governance, audit and lifecycle obligations similar to other production identities.
• Decision-level Authorisation: An authorisation model that evaluates each proposed action before execution, using the specific tool, resource, arguments and delegated identity involved. It is the practical answer to agentic risk because the dangerous event is not login, but the runtime choice the model makes next.
• Capability-Based Access Control: Capability-Based Access Control is a model where access is granted through possession of an unforgeable capability, not just a user or role label. In identity systems, a capability acts like a token that authorizes a specific action on a specific resource, reducing ambient privilege and supporting least-privilege automation.
• Delegation Chain: A delegation chain is the sequence of identities, credentials, and tool calls an agent uses to complete a task across systems. It matters because each step may appear acceptable on its own while the combined path produces an outcome no reviewer would have approved directly.

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 building or maturing an IAM programme, it is worth exploring.