Should organisations re-evaluate IAM and PAM for agentic AI deployments?

Why This Matters for Security Teams

agentic ai changes IAM and PAM from a static access problem into a runtime control problem. A human admin can be reviewed against a predictable role, but an autonomous agent can chain tools, pivot across systems, and act at machine speed with delegated authority. That makes conventional entitlement reviews, vault checks, and quarterly recertification necessary but insufficient. Current guidance suggests security teams should treat agent access as task-scoped execution, not as a durable persona. Research from AI Agents: The New Attack Surface report shows why this matters: 80% of organisations report their AI agents have already acted beyond intended scope.

This is where traditional PAM assumptions break down. Standing roles often imply stable human intent, but agents are opportunistic by design: they may request a tool, call an API, read a secret, then immediately use that secret in a new context. That behaviour is hard to constrain with legacy approval flows alone. OWASP’s OWASP Agentic AI Top 10 and the NIST AI Risk Management Framework both point toward context-aware governance rather than static trust. In practice, many security teams encounter agent privilege drift only after a tool chain has already touched sensitive data or produced an unsafe action.

How It Works in Practice

For agentic deployments, the practical question is not whether an agent has an identity, but what kind of identity it should use and how that identity is constrained at runtime. Best practice is evolving toward workload identity, short-lived credentials, and policy evaluated per request. That means the agent proves what it is with cryptographic identity, then receives only the minimum access needed for a specific task, for a short window, with automatic revocation on completion. SPIFEE-style workload identity and OIDC-backed tokens are commonly used patterns, because they reduce reliance on long-lived shared secrets.

Security teams usually need to split controls across three layers:

• Identity issuance: bind the agent to a workload identity rather than a reusable human credential.
• Authorisation: evaluate intent, context, data sensitivity, and tool scope at request time using policy as code.
• Secret handling: issue JIT credentials and ephemeral tokens instead of static API keys or vault exports.

This matters because an agent’s access pattern is not fixed. It may search, summarise, write, trigger, and retry in one workflow, which makes pre-approved role buckets too coarse. The CoPhish OAuth Token Theft via Copilot Studio report illustrates how agent-mediated flows can be abused when token boundaries are weak. CSA’s CSA MAESTRO agentic AI threat modeling framework and MITRE ATLAS adversarial AI threat matrix both reinforce the need to model tool chaining, lateral movement, and delegated action as first-class risks. These controls tend to break down when agents share secrets across environments because token scope, telemetry, and revocation are no longer aligned.

Common Variations and Edge Cases

Tighter runtime controls often increase operational overhead, requiring organisations to balance speed and automation against governance and recovery. That tradeoff is especially visible when agents must operate across legacy systems, third-party SaaS, or mixed human and machine workflows. There is no universal standard for this yet, but current guidance suggests avoiding one-size-fits-all IAM roles for every agent.

Edge cases usually include long-running agents, multi-agent handoffs, and service accounts that support both humans and automations. In those environments, a purely ephemeral model can be difficult to sustain because some systems cannot natively issue short-lived tokens or verify workload identity. A pragmatic approach is to keep the blast radius small: isolate agent environments, separate human admin paths from agent paths, and require step-up controls for sensitive actions such as secret export, data deletion, or privilege escalation. The Ultimate Guide to NHIs highlights how quickly NHI sprawl becomes unmanageable when governance lags deployment.

In some cases, existing PAM still has value for break-glass access and emergency containment, but it should not be the primary control plane for autonomous agents. The more the agent can reason, retry, and chain tools, the more the organisation needs runtime policy enforcement rather than static approval. The risk is highest in environments where an agent can reach sensitive APIs through inherited tokens, because the access path looks legitimate until the moment it is abused.

Related resources from NHI Mgmt Group

• Why do AI agents increase non-human identity risk in existing IAM programmes?
• When does just-in-time access reduce risk for agentic AI, and when does it fall short?
• How should security teams govern machine identity credentials in agentic AI environments?
• Why do AI agents create more IAM risk than ordinary developer tools?