What breaks when organisations try to retrofit IAM controls onto AI agents?

Why Traditional IAM Fails for Autonomous AI Agents

Retrofit IAM assumes a person or service has a relatively stable identity, a known session pattern, and permissions that can be reviewed against expected behaviour. AI agents break that model because they are autonomous, goal-driven, and able to chain tools, carry context across steps, and operate in multiple environments. A role may describe the launch point, but it does not describe the agent’s full action path. Current guidance in OWASP Agentic AI Top 10 and the NIST AI Risk Management Framework both point toward runtime governance, because static permissions alone cannot express intent, scope, and state together.

That is why this issue is not just “over-permissioning.” It is a control mismatch. IAM can say what an agent may access, but not why it is doing so, whether the action is still aligned to the task, or whether the current step is safe after the previous step changed context. NHIMG research shows how quickly this becomes a real incident pattern: in the SailPoint report on AI agents, 80% of organisations said agents already acted beyond intended scope. In practice, many security teams discover this only after an agent has already touched data or systems that were never part of the original design.

How It Works in Practice

The practical fix is to move from static IAM to runtime, context-aware authorisation. That means combining workload identity, intent checks, short-lived credentials, and policy evaluation at the moment of action. Rather than granting an agent broad standing access, security teams should issue just-in-time credentials for a specific task, bind them to the workload identity, and revoke them automatically when the task ends. In agentic environments, that identity should represent what the agent is as a workload, not just what secret it currently holds.

This is where CSA MAESTRO agentic AI threat modeling framework is useful, because it forces teams to reason about orchestration, tool use, and privilege boundaries instead of treating the agent like a normal user. For implementation, many teams align policy-as-code engines with runtime decisions, then integrate them with cryptographic workload identity patterns such as SPIFFE or OIDC-backed service tokens. That lets policy reflect live context such as the requested tool, the data classification, the environment, and the task objective.

NHIMG has documented how brittle static secret handling becomes in agentic systems. The Moltbook AI agent keys breach and the DeepSeek breach both reinforce the same lesson: long-lived secrets create a large blast radius when agents can act quickly and repeatedly. These controls tend to break down when agents span SaaS, cloud, and internal tools in one workflow, because authorization context is lost between systems.

• Issue ephemeral Secrets per task, not reusable keys for the whole agent lifecycle.
• Evaluate policy at request time, not only at provisioning time.
• Authorize by intent and data sensitivity, not just by role membership.
• Revoke access automatically when the goal, session, or context changes.

Common Variations and Edge Cases

Tighter control often increases operational overhead, so organisations have to balance containment against the friction of frequent token issuance, policy checks, and audit logging. That tradeoff is real, especially for multi-agent workflows where one agent delegates to another or hands off partial state. There is no universal standard for this yet, but current guidance suggests that the more autonomous the system, the more aggressive the move toward ZSP and JIT credentials should be.

Edge cases appear when agents run across mixed trust zones. A model may be harmless in a sandbox but dangerous once it can reach production APIs, customer records, or CI/CD pipelines. In those cases, fixed RBAC becomes a coarse approximation, not a control. The better pattern is to combine the OWASP NHI Top 10 with zero trust principles and the NIST AI Risk Management Framework, so that every tool call is checked against current context, not inherited trust. The same applies when secrets are embedded in workflows: the Azure Key Vault privilege escalation exposure illustrates how privilege can expand unexpectedly once a secret or role is reused beyond its intended boundary.

For agentic systems, the hard part is not only authentication. It is making sure the authorisation decision still matches the agent’s current intent, environment, and scope after every step.

Related resources from NHI Mgmt Group

• What breaks when organisations rely only on native AI safety controls?
• Why do AI agents increase non-human identity risk in existing IAM programmes?
• Why do AI agents create more IAM risk than ordinary developer tools?
• How can organisations prevent AI agents from becoming overprivileged?