How do IAM and PAM teams split responsibility for AI agent access?

Why This Matters for Security Teams

IAM and PAM cannot be split cleanly for AI agents if the organisation still thinks in human-user terms. Agent identities are programmatic, their actions are goal-driven, and their access can change mid-task as tools, prompts, and context shift. Static role assignments often over-grant access up front, while PAM controls that depend on a human session miss the real control point: runtime authorisation and revocation.

This is why guidance from OWASP Agentic AI Top 10 and NIST AI Risk Management Framework matters here. They both point security teams toward context-aware controls, not static entitlements, because autonomous systems can chain tools and expand scope in ways a conventional access review will not predict. NHIMG’s research on 52 NHI Breaches Analysis shows how quickly exposed machine identities turn into broader compromise when lifecycle ownership is unclear.

In practice, many security teams discover the split between IAM and PAM only after an agent has already retained access beyond the intended task window.

How It Works in Practice

The cleanest operating model is to treat IAM as the owner of identity, scope, and policy boundaries, while PAM governs elevation, time limits, and emergency access. For agents, that means the identity is tied to a workload or service principal, not a person, and permission decisions are evaluated at request time rather than pre-approved for an entire role. Current guidance suggests combining workload identity, policy-as-code, and short-lived credentials so access can be granted for a task and automatically revoked when the task completes.

That model usually includes:

• Workload identity as the base primitive, such as OIDC-backed service identities or SPIFFE-style attestation.
• IAM-defined scopes for what the agent may attempt, including resource classes, environments, and API boundaries.
• PAM-issued elevation for sensitive actions, with explicit TTLs and automatic revocation.
• Real-time policy evaluation using tools such as NIST AI Risk Management Framework aligned controls and runtime policy engines.
• Continuous logging of task, context, and escalation events so review can follow the agent lifecycle.

NHIMG’s Ultimate Guide to NHIs and the AI LLM hijack breach illustrate the practical risk: if an agent can hold long-lived credentials, a single prompt or tool chain can turn a narrow task into broader lateral movement. The operational split is therefore not “IAM sets access, PAM handles emergencies.” It is “IAM defines the standing policy envelope, PAM supplies just-in-time elevation, and both systems share the same lifecycle state.” These controls tend to break down when agents reuse cached tokens across jobs because revocation no longer maps cleanly to a single execution context.

Common Variations and Edge Cases

Tighter elevation control often increases friction for developers and platform teams, requiring organisations to balance speed against the cost of repeated approvals and shorter token lifetimes. That tradeoff becomes sharper in agentic environments where tasks are frequent and partially autonomous. Best practice is evolving, but there is no universal standard for how much runtime context PAM should inspect before granting elevation to an AI agent.

One common edge case is delegated action: an agent may need to act on behalf of a human, but that does not mean it should inherit the human’s standing privileges. Another is multi-agent orchestration, where one agent brokers access for others. In those cases, IAM should still define the base trust boundary, while PAM controls any step-up access separately for each agent and each task. CSA MAESTRO agentic AI threat modeling framework is useful here because it frames the problem as chained, composable risk rather than isolated user sessions.

NHIMG’s Moltbook AI agent keys breach and DeepSeek breach reinforce the same point: long-lived access plus automation creates a persistence problem, not just an authentication problem. If the environment relies on shared secrets, cached sessions, or broad delegation across sandboxes, the IAM/PAM split becomes too coarse to contain agent behaviour.

Related resources from NHI Mgmt Group

• When does AI agent access create more risk than it reduces?
• What is the difference between governing human access and governing AI agent access?
• Why is JIT access important for AI agent management?
• How should security teams govern AI agents that use OAuth access?