They should move from human-centric authentication assumptions to task-based authorisation, workload identity, and revocation-first controls. AI agents do not need a user experience, but they do need tightly bounded access, monitoring, and ownership. IAM and PAM teams should design for faster change, shorter access windows, and more frequent reassessment of what the agent can do.
Why This Matters for Security Teams
IAM and PAM for AI agents cannot be treated as a scaled-up version of human access management. Agents are goal-driven, chain tools, and change behaviour based on prompts, context, and upstream data, so static roles quickly become overbroad. That is why current guidance from the OWASP Top 10 for Agentic Applications 2026 and NIST AI Risk Management Framework emphasizes runtime control, not just provisioning.
This matters because agent behaviour is not stable enough for traditional joiner-mover-leaver assumptions. A human user logs in, works, and logs out; an agent may execute dozens of tool calls, create nested actions, and retain access to secrets far longer than intended if revocation is not automated. NHIMG research on AI Agents: The New Attack Surface report found that 80% of organisations report agents have already acted beyond their intended scope, including unauthorized system access and disclosure of credentials. In practice, many security teams encounter agent abuse only after sensitive data has already left the approved workflow, rather than through intentional design of task-bounded access.
How It Works in Practice
The practical shift is from identity as a person to identity as a workload. For agents, the access primitive should be cryptographic workload identity, not a long-lived human session. That means using standards such as SPIFFE/SPIRE or short-lived OIDC tokens to prove what the agent is and what task it is authorized to perform at that moment. Authorization should be evaluated at request time with policy-as-code, rather than assumed from a static RBAC role.
For IAM and PAM teams, the operating model changes in three ways:
- Issue just-in-time credentials per task, with short TTLs and automatic revocation when the task completes.
- Bind secrets, tokens, and API keys to a narrowly defined workflow, not to a persistent agent account.
- Evaluate context at runtime, including tool requested, data sensitivity, environment, and human approval state.
This is consistent with the direction of the CSA MAESTRO agentic AI threat modeling framework, which treats tool use, autonomy, and chained actions as distinct risk surfaces. NHIMG coverage of the OWASP NHI Top 10 also shows why static secrets and broad entitlements are a poor fit for autonomous systems that can pivot across APIs, data stores, and orchestration layers. Security teams should treat each agent action as a fresh authorisation event, not as a continuation of a human-style session. These controls tend to break down in environments where agents are allowed to discover new tools dynamically because the approved access envelope can expand faster than review cycles can react.
Common Variations and Edge Cases
Tighter control often increases operational friction, requiring organisations to balance agent velocity against governance overhead. That tradeoff is real, especially when teams want agents to complete multi-step work without repeated human intervention. Current guidance suggests using policy tiers instead of one universal model, but there is no universal standard for this yet.
High-trust internal agents may use shorter approval paths, while external-facing or data-rich agents should require stronger constraints, narrower scopes, and more frequent revalidation. Some environments also need break-glass paths for incident response, but those should be isolated, logged, and time-bounded like any other privileged workflow. Human PAM patterns such as standing administrator groups, shared service accounts, and reusable secrets are especially risky here because they obscure which task triggered access and who approved it. A useful reference point is the Ultimate Guide to Non-Human Identities, which frames NHI governance as a lifecycle discipline rather than a one-time provisioning exercise. Best practice is evolving, but the direction is clear: the more autonomous the agent, the less tolerable long-lived privileges become.
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 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A2 | Agentic apps need runtime authorization, not static human-role assumptions. |
| CSA MAESTRO | T1 | MAESTRO models tool use and autonomy as separate risk surfaces for agents. |
| NIST AI RMF | AI RMF supports governance for autonomous behavior and ongoing risk monitoring. |
Apply AI RMF governance to define ownership, monitoring, and reassessment for each agent.
