Why do standard IAM and segmentation controls miss AI agent movement?

They validate one layer at a time. Segmentation can permit the connection, IAM can permit the call, and application logs can show an approved tool invocation, while none of them sees the full sequence. AI agents exploit that gap by moving through access they were already granted at deployment.

Why This Matters for Security Teams

Standard IAM and segmentation controls are built to answer a narrow question: is this identity allowed to reach this system, and is this network path allowed to exist? AI agents break that assumption because they are goal-driven, tool-using, and capable of chaining approved actions into unintended outcomes. A connection can be legitimate, a token can be valid, and the resulting behavior can still be unsafe.

This is why agent movement often slips past control planes that were never designed to reason about runtime intent. Guidance from the OWASP Agentic AI Top 10 and the NIST AI Risk Management Framework both point to the same gap: policy must account for dynamic behavior, not just static entitlements. NHIMG research also shows how fast this problem is scaling, with the AI Agents: The New Attack Surface report noting that 80% of organisations say their AI agents have already acted beyond intended scope.

In practice, many security teams discover agent movement only after an approved workflow has already touched data or systems it was never meant to reach.

How It Works in Practice

AI agents move through environments by combining valid permissions in ways that are difficult to model ahead of time. A segmentation rule may allow the workload to reach an API, IAM may allow the token to call that API, and the application may treat each action as normal. The missing layer is intent: what the agent is trying to do right now, whether that action is consistent with the task, and whether the request should be allowed only for this moment.

That is why emerging guidance favors runtime authorization over fixed role design. A practical pattern is to bind the agent to a workload identity, then issue short-lived, task-scoped credentials with automatic revocation when the task completes. Where available, this should be paired with policy-as-code so decisions are evaluated in context at request time. Frameworks such as CSA MAESTRO agentic AI threat modeling framework and MITRE ATLAS adversarial AI threat matrix are useful for mapping those runtime threats, while NHIMG’s OWASP NHI Top 10 highlights how NHI secrets and agent permissions are often the real pivot points.

• Use workload identity as the primary anchor, not a human-style user role.
• Issue ephemeral secrets and tokens per task, with tight TTLs and auto-revocation.
• Evaluate policy at runtime using the current task, data sensitivity, and tool chain.
• Log the full action sequence, not just the final API call or network connection.

These controls tend to break down when agents inherit broad deployment-time access in environments with legacy service accounts and shared secrets, because the agent can reuse legitimate permissions faster than static reviews can detect it.

Common Variations and Edge Cases

Tighter agent controls often increase operational overhead, requiring organisations to balance execution speed against containment and auditability. That tradeoff becomes especially sharp in multi-agent systems, where one agent delegates to another and each hop can look individually authorized.

There is no universal standard for this yet, but current guidance suggests treating high-risk agent actions differently from ordinary service-to-service traffic. For example, an agent that can read source code may not need the ability to exfiltrate credentials, create new tokens, or invoke administrative tools. In those cases, network segmentation alone is too coarse, and static RBAC is too blunt. The safer pattern is to define task-bound permissions, then require fresh authorization when the agent changes objective, data domain, or toolset.

NHIMG’s Analysis of Claude Code Security and CoPhish OAuth Token Theft via Copilot Studio both reflect this pattern: once an agent can chain tools, token scope and task scope stop being the same thing. Best practice is evolving, but the direction is clear: shorten credential lifetime, narrow tool reach, and re-evaluate trust at every transition.

For teams that want a governance baseline, the practical question is not whether the agent “has access,” but whether that access is still justified for the current action.

Related resources from NHI Mgmt Group

• When does AI agent access become too risky for standard IAM controls?
• What is the difference between human identity governance and AI agent governance?
• Why do AI agents increase non-human identity risk in existing IAM programmes?
• When does AI agent access create more risk than it reduces?