How do PAM and IGA need to change in the agentic AI era?

They need a shared authorization model that treats agent access as governed entitlement, not a special-case exception. PAM should control the highest-risk paths, while IGA should certify the underlying permissions graph that makes those paths possible. Without that alignment, the controls will describe different versions of the same risk.

Why Traditional PAM and IGA Stop Matching Agentic AI Risk

Agentic systems do not fit the old split where PAM protects privileged accounts and IGA certifies human roles. An AI agent can chain tools, call APIs, request elevation, and repeat actions at machine speed, which means the risk is defined by runtime intent, not by a static role catalog. That is why current guidance suggests treating agent access as a governed workload identity with explicit authorization paths, not as an exception bolted onto human-centric controls. NHI Management Group’s reporting on the OWASP NHI Top 10 and the NIST AI Risk Management Framework both reinforce that autonomous behavior changes the control boundary.

SailPoint’s research on AI agents as the new attack surface found that only 52% of companies can track and audit the data their AI agents access, which leaves a large compliance and investigation gap. In practice, many security teams discover the mismatch only after an agent has already touched sensitive data or used an overbroad entitlement that no one expected it to exercise.

How PAM and IGA Need to Work Together in Practice

The practical shift is to treat PAM as the enforcement layer for high-risk actions, while IGA becomes the system of record for the permissions graph that makes those actions possible. PAM still matters for step-up approval, session control, secret issuance, and break-glass access. IGA still matters for certification, access review, segregation of duties, and entitlement hygiene. The difference is that neither control can remain isolated when the workload is autonomous.

For agentic ai, best practice is evolving toward intent-based authorization at runtime. The system should evaluate what the agent is trying to do, which tool it is invoking, which dataset it will touch, and whether the request is consistent with the agent’s assigned task. That requires short-lived, task-scoped credentials rather than long-lived static secrets. It also requires workload identity as the identity primitive, so the agent proves what it is through cryptographic identity, not merely through a stored password or token. Frameworks such as the CSA MAESTRO agentic AI threat modeling framework and the OWASP Agentic AI Top 10 point in the same direction: policy must be evaluated in context, not pre-assigned once and forgotten.

• Use IGA to certify which underlying entitlements the agent may ever request.
• Use PAM to issue just-in-time access only for the approved action and revoke it when the task ends.
• Bind approvals to workload identity, service identity, or signed execution context.
• Log every tool call, data access, and privilege escalation path for later review.

NHIMG’s CoPhish OAuth Token Theft via Copilot Studio coverage shows how quickly agent pathways can be abused once delegated tokens and tool access are exposed. These controls tend to break down in highly dynamic environments where agents can self-assemble workflows across SaaS, cloud, and internal APIs because the entitlement graph changes faster than certification cycles can keep up.

Common Variations and Edge Cases Security Teams Need to Plan For

Tighter controls often increase operational overhead, so organisations have to balance speed against assurance. That tradeoff becomes more visible when developers, analysts, and citizen builders are all deploying agents that inherit different scopes, approval paths, and data access patterns. There is no universal standard for this yet, so guidance should be treated as emerging rather than settled.

One common edge case is delegated access through service accounts or shared API tokens. Another is human-in-the-loop approval that looks strong on paper but does not limit what the agent can do after approval is granted. A third is agent chaining, where one agent passes work to another and the cumulative privileges exceed any single approval. The most defensible approach is to model these flows as separate entitlements and verify them continuously, not only at joiner-mover-leaver events. NHI Management Group’s Ultimate Guide to NHIs is useful here because it frames non-human access as a lifecycle problem, not a one-time provisioning task.

Current guidance suggests using policy-as-code and real-time decisioning for the highest-risk actions, especially where the agent can reach production systems, regulated data, or privileged automation. This is also where NIST and OWASP guidance converges with implementation practice: if IGA cannot explain the entitlement, PAM should not be asked to defend it. If PAM cannot constrain the action at runtime, IGA certification alone is not enough.

Related resources from NHI Mgmt Group

• What makes agentic AI an NHI governance issue?
• Why do PAM and IGA struggle to control agentic AI identities?
• How should organisations govern AI agent tool access as connectors change?
• Should organisations unify NHI, IGA, and PAM workflows?