Why agentic AI breaks people-first IAM assumptions

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Pomerium's blog post: Legacy IAM assumptions built for human users fail when AI agents behave like runtime decision-makers with rapidly changing access needs.

Why it matters: IAM, PAM, and NHI teams need to rework enforcement and audit models because agentic systems can outpace human review cycles, blur accountability, and expand access scope during a single task.

Context

Enterprise identity programmes were built around the assumption that the authenticated subject is a person. That model depends on predictable work patterns, stable entitlements, and a named owner who can be reviewed, offboarded, and held accountable.

Agentic AI changes the problem because the access pattern is no longer human-paced or human-shaped. When an identity can request new permissions at runtime, delegate work, and chain actions across services, the governance model has to move from periodic review to continuous enforcement.

The article's core point is not that machines need slightly more access control than people. It is that the old IAM design centre, which treats identity as a stable user record, no longer matches how AI agents actually consume credentials and invoke services.

Key questions

Q: How should organisations govern AI systems that can change scope at runtime?

A: They should treat runtime behaviour as part of the compliance boundary. That means inventorying every model, tool, and integration, then checking whether the system still acts within its intended purpose after deployment. Static approval is not enough when an agent can expand scope through chained actions or delegated workflows.

Q: Why do AI agents complicate traditional access reviews?

A: AI agents complicate access reviews because they can accumulate permissions across tools and environments faster than manual certification cycles can observe. A review process built for stable human accounts does not fit an executor that can act across systems, create new access paths, and complete work before the next review window begins.

Q: What are the signs that agent identities are poorly governed?

A: Common signs include shared service accounts, long-lived OAuth grants, unclear ownership, and logs that cannot distinguish agent actions from human actions. If the audit trail cannot answer who delegated the work and what scope applied, the identity model is already failing. That is a governance problem, not just a logging problem.

Q: What should security teams do after an AI agent token is exposed or redirected?

A: Immediately assume the agent's standing authority is compromised and review every service the token could reach. Revoke the session, rotate the affected credentials, inspect tool-call history for abnormal actions, and validate whether any helper service redirected traffic or stored copied credentials. Containment has to start before the agent completes another tool call.

Technical breakdown

Why static sessions fail for agentic AI

Traditional IAM issues a session after authentication and then trusts that session until expiry. That is workable for a person interacting at human speed, but it breaks when an agent makes hundreds of API calls per minute and can spawn sub-agents mid-task. The control problem is not just volume. It is that the access pattern changes inside the same execution window, so the original authorisation context stops describing what the principal is actually doing. Human-oriented anomaly detection also struggles because the behaviour is not merely unusual, it is structurally non-human.

Practical implication: move enforcement from session issuance to per-request policy checks.

Why role-based access control loses precision

RBAC depends on being able to map a stable job or function to a permission set in advance. Agentic systems do not stay stable long enough for that mapping to remain accurate, because they request new permissions at runtime and may delegate work to sub-agents that inherit the broader chain of authority. That means the effective privilege set can expand during the task, not before it. Once scope is negotiated on the fly, the role model becomes a coarse approximation rather than a reliable governance mechanism.

Practical implication: treat delegated AI access as dynamic authorisation, not as a fixed role assignment.

How identity context must travel across service hops

The article's strongest architectural point is that every hop in an agent chain needs explicit identity propagation. If Agent A invokes Service B, which then invokes Service C, the system has to preserve who delegated the action and what the allowed scope is at each step. Without that continuity, the audit trail fragments and accountability collapses into a sequence of opaque service calls. In practice, this is the difference between knowing that a workload moved data and knowing which delegated principal was authorised to do it.

Practical implication: design for propagated identity and immutable request-level logging across the full delegation chain.

Threat narrative

Attacker objective: The attacker wants to turn delegated machine identity into broad, hard-to-audit service access that persists long enough to affect multiple systems.

1. Entry begins when an attacker gains or abuses the credentials, service accounts, or OAuth grants used by an AI agent.
2. Escalation occurs when the agent can request new permissions at runtime or chain calls through sub-agents faster than human review can intervene.
3. Impact follows when the compromised agent uses its delegated access to touch multiple services with a trust model that still assumes a human is behind the session.

Breaches seen in the wild

• Azure Key Vault Contributor escalation 2024: Datadog found Azure Key Vault Contributor could add itself to access policies and read every secret, key and certificate in a vault.

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

People-first IAM is now an assumption mismatch, not just a scale problem. The article shows that the core IAM design centre still expects a person, even when the principal is an AI agent that can request, chain, and change access mid-task. That is a structural mismatch between governance model and runtime behaviour. The implication is that identity architecture must be judged against actor behaviour, not legacy user assumptions.

Static privilege design cannot describe agentic scope. Role mapping works when access can be predicted from a job function, but it fails when runtime decisions determine which tools and data the principal touches. That failure is not an implementation defect alone. It is a broken premise about how authorisation can be defined in advance. Practitioners should treat agent privilege as a moving boundary, not a fixed entitlement set.

Identity context becomes the control plane for machine accountability. The article correctly ties delegated authority, request-level policy, and immutable logging together because agentic systems cannot be governed by trust in the workload itself. If the enforcement point sits inside the agent, it can be bypassed by the very compromise it is supposed to contain. Practitioners need identity-aware enforcement outside the agent boundary.

Ephemeral credentials reduce theft value, but only if enforcement is external to the agent. Short-lived tokens lower the payoff of prompt injection and credential exfiltration, yet they do not solve the deeper governance issue if the agent can still self-authorise within a broad runtime envelope. The real shift is toward continuous verification at the access layer. Teams should reframe identity security around issuance, propagation, and request-time decisioning.

Agentic AI makes non-human identity governance a first-class IAM discipline. The fastest-growing identity population is no longer a side case for service account managers. It is now a core design problem for IAM, PAM, and lifecycle governance because the principal can act autonomously across multiple services. That convergence means NHI controls, zero trust enforcement, and access governance have to be designed as one programme, not separate silos.

What this signals

Identity context has to become part of the enforcement path, not just the audit path. The practical failure mode here is not that agents exist, but that many identity programmes still treat access decisions as static events. Once a principal can re-scope itself during execution, governance has to shift to request-time verification and propagated identity across service hops.

Agentic AI pushes NHI governance into IAM mainstream. Service accounts, OAuth grants, and machine credentials are no longer back-office exceptions. They are now the access substrate for a growing share of enterprise work, which means lifecycle management, delegation control, and request-level policy need to sit in the core identity programme.

Runtime behaviour is the new boundary for least privilege. If an agent can call additional tools on demand, least privilege cannot be set only by job title or onboarding form. Practitioners should design for scoping that survives delegation chains and for controls that evaluate the specific request, not the assumed role.

For practitioners

• Define each agent as a first-class principal Assign unique identities to AI agents instead of sharing service accounts or inherited human credentials. Tie delegated authority to the specific principal so access can be enforced, audited, and revoked without ambiguity.
• Shift enforcement to the request layer Place policy checks outside the agent and evaluate every action at the point of access. Use infrastructure controls that can deny an individual request even when the agent itself is compromised or misled.
• Issue short-lived credentials only Remove static API keys and long-lived OAuth grants from execution environments. Prefer ephemeral, cryptographically signed tokens that expire quickly and do not remain available for reuse after the task completes.
• Propagate identity across every hop Preserve delegated identity through each service call so downstream systems can see who authorised the action and what scope applied. Without that chain, audit evidence becomes fragmented and accountability breaks down.
• Separate audit logging from the agent runtime Write immutable logs from infrastructure the agent cannot modify. Record the principal, delegated scope, and request outcome so compliance reviews rely on evidence outside the workload's control.

Key takeaways

• The article shows that people-first IAM assumptions fail when the authenticated subject can act like an agent rather than a user. That changes identity from a static record problem into a runtime authorisation problem.
• Pomerium cites evidence that 18% of security leaders have high confidence in their current identity systems for managing agent identities, and the article also points to 71% of enterprises experiencing an identity-related breach in 2025.
• The practical answer is to enforce identity at request time, keep agents on unique credentials, and preserve delegated context across every hop so accountability does not disappear.

Key terms

• Agentic Identity: An agentic identity is a non-human identity used by an autonomous system that can act, call tools, and access data with execution authority. It needs the same governance discipline as other privileged identities, plus runtime context, ownership mapping, and revocation paths.
• Delegated Authority Model: A delegated authority model defines who is allowed to approve, review, or execute control-related decisions across the enterprise. It helps ensure requests reach the correct responsible party, especially when control owners, managers, and process owners sit in different teams, regions, or systems.
• Continuous Verification: A Zero Trust practice that re-evaluates trust during the session instead of relying on a single successful login. The control is stronger when context signals are available in real time and when the identity programme can act on those signals without creating excessive exceptions.
• Propagated Identity: Propagated identity is the preservation of principal context across each service hop in a delegated workflow. It ensures downstream systems know who initiated the action, who delegated it, and what scope was authorised, which is essential when agent chains cross multiple services.

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 identity security programme, it is worth exploring.