Why do AI agents complicate existing IAM and PAM controls?

Why This Matters for Security Teams

AI agents are not simply another service account with a prettier interface. They can chain tools, pursue goals over time, and keep operating after the original approval moment has passed. That means classic IAM and PAM assumptions, especially human-like session boundaries, periodic recertification, and role-first design, do not map cleanly to agent behaviour. Current guidance increasingly points toward runtime decisioning, as reflected in the OWASP Agentic AI Top 10 and NIST AI Risk Management Framework, because the control problem is now behavioural, not just credential-based.

This is why NHI governance matters so much in agentic environments. If an agent can inherit delegated Secrets, use MCP-connected tools, and operate across systems without a fresh approval for each action, then IAM and PAM only describe the starting point, not the full blast radius. NHI teams also have to think about lifecycle controls, auditability, and how access is granted and revoked in practice, not just in policy language. NHIMG research such as the OWASP NHI Top 10 frames this as a control gap between identity issuance and real-world execution. In practice, many security teams encounter that gap only after an agent has already touched data or systems it was never meant to reach.

How It Works in Practice

The practical problem is that AI agents need authority to act, but they do not behave like fixed human users. A human request can be reviewed once and then bounded by a session. An agent may need to discover a path, call multiple APIs, and make new choices at each step. That is why static RBAC is often too coarse and why intent-based or context-aware authorisation is emerging as the better fit: the policy decision happens at runtime, based on what the agent is trying to do, what tool it wants to call, and what data it needs right now. The design direction is consistent with CSA MAESTRO agentic AI threat modeling framework and MITRE ATLAS adversarial AI threat matrix, both of which emphasise dynamic assessment over static trust.

In practice, stronger patterns include JIT credential provisioning, short-lived tokens, and workload identity rather than long-lived shared Secrets. The goal is to issue authority per task, bind it to the agent’s workload identity, and revoke it automatically when the task completes. That can mean SPIFFE/SPIRE-style workload identity, OIDC tokens, policy-as-code, and real-time checks before every sensitive action. NHIMG’s AI LLM hijack breach coverage and the Moltbook AI agent keys breach show why ephemeral credentials matter: when keys or tokens escape, attackers can move fast and abuse them before manual controls catch up. The same logic applies to auditability. If you cannot track what the agent accessed, you cannot prove whether the action matched the approved intent. These controls tend to break down when agents are allowed to reuse static credentials across tools because the trust boundary becomes too broad and too persistent.

• Use workload identity as the agent’s primary identity primitive, not the long-lived token it happens to hold.
• Issue JIT credentials for a single workflow or tool invocation, then revoke them automatically.
• Evaluate policy at request time with full context, rather than relying on pre-approved roles alone.
• Log each tool call, data access, and downstream delegation so post-incident review can reconstruct agent behaviour.

Common Variations and Edge Cases

Tighter agent controls often increase operational overhead, requiring organisations to balance safety against latency, integration complexity, and developer friction. That tradeoff is real, especially where agents support high-frequency workflows, but current best practice is evolving toward narrower privileges and shorter lifetimes rather than broader standing access. There is no universal standard for this yet, so teams need to choose controls that fit their risk posture and tooling maturity.

One common edge case is multi-agent pipelines, where one agent delegates to another and the original approval context becomes harder to preserve. Another is human-in-the-loop systems where a human approves the first step but not every follow-on action. In both cases, intent can drift, so the policy engine should validate the current action, not just the original request. This is also where the DeepSeek breach and Top 10 NHI Issues are useful references, because they reinforce how exposed credentials and weak lifecycle discipline amplify agent risk. For governance teams, the practical takeaway is to separate identity, entitlement, and execution authority as much as possible, then rejoin them only at the moment of action. The moment agents can persist, self-direct, or switch tools without a fresh decision point, traditional IAM and PAM start to lose precision.

Related resources from NHI Mgmt Group

• Why do AI agents increase non-human identity risk in existing IAM programmes?
• Why do AI agents complicate traditional IAM and PAM controls?
• Why do AI agents create more risk when they reuse existing credentials?
• Why do AI agents create more IAM risk than ordinary developer tools?