Traditional IAM assumes access can be reviewed and governed as a stable entitlement. Agentic identity breaks that assumption because authority may be exercised in a session-specific, context-driven way. Teams need controls that monitor action selection and tool use, not just login success and token status.
Why This Matters for Security Teams
Traditional IAM is built around stable human roles, predictable sessions, and access reviews that assume the same person will use the same permissions in broadly the same way. agentic identity breaks that model. An agent may act through multiple tools, change intent mid-session, and chain actions that were never granted as a single entitlement. The practical risk is not just “too much access”, but access exercised in ways no reviewer anticipated.
NHIMG research shows why this gap is already operational, not theoretical: in AI Agents: The New Attack Surface, SailPoint reports that 80% of organisations say their AI agents have already acted beyond intended scope. That is a governance failure, but it is also an IAM failure, because static entitlements do not explain runtime behaviour. Current guidance from the NIST AI Risk Management Framework and the OWASP Agentic AI Top 10 points toward runtime controls, not just identity proof at login.
In practice, many security teams discover the problem only after an agent has already touched data, invoked tools, or propagated credentials into systems that no access review ever explicitly approved.
How It Works in Practice
Agentic systems need identity controls that match their execution model. That usually means shifting from static RBAC toward intent-based or context-aware authorisation, where each tool call is evaluated at request time. Instead of asking only “who logged in”, the control plane asks “what is the agent trying to do, with which data, under which policy, and for how long”.
That shift is usually paired with just-in-time provisioning and ephemeral secrets. Short-lived credentials reduce the blast radius when an agent behaves unexpectedly, especially when the workload can branch across tools or services. Workload identity is the better primitive here: cryptographic proof of what the agent IS, not just a reused secret that proves it got authenticated once. Standards-oriented implementations often use OIDC-bound workload tokens or SPIFFE/SPIRE identities, then evaluate policy through engines such as OPA or Cedar at the moment of each action.
NHIMG’s Ultimate Guide to NHIs is useful background for the broader non-human identity model, while OWASP NHI Top 10 helps translate the agentic risk into controls teams can actually implement. The practical pattern is: authenticate the workload, constrain the tool, scope the data, shorten the credential lifetime, and revoke automatically when the task ends.
These controls tend to break down when agents are allowed to compose new tool paths dynamically across loosely governed SaaS, data platforms, and browser automation because the effective permission set expands faster than policy can be reviewed.
Common Variations and Edge Cases
Tighter runtime control often increases engineering and governance overhead, requiring organisations to balance safety against deployment speed. That tradeoff is most visible in environments with many tools, nested agents, or long-running workflows where per-action authorisation can add latency or operational complexity.
There is no universal standard for agentic authorisation yet. Current guidance suggests treating high-risk actions differently from low-risk ones: write access, credential export, external network calls, and data exfiltration checks should be stricter than simple read-only retrieval. In some environments, a hybrid model works best, with baseline RBAC for coarse access plus runtime policy for sensitive actions. In others, especially where agents can spawn subtasks or call external APIs, static roles become too blunt to be useful.
Operational edge cases also matter. Shared agent pools, multi-tenant copilots, and delegated tools can blur attribution unless every action is tagged to a specific workload identity and task context. The CSA MAESTRO agentic AI threat modeling framework is helpful here because it pushes teams to map agent goals, tool access, and failure modes together rather than treating identity as a standalone control. For teams facing visible scope creep already, AI Agents: The New Attack Surface remains a sharp reminder that governance gaps show up first as unauthorised action, not as a broken login.
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, OWASP Non-Human Identity Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A1 | Agentic systems need runtime controls beyond static IAM entitlements. |
| OWASP Non-Human Identity Top 10 | NHI-03 | Short-lived credentials reduce exposure when non-human access is misused. |
| CSA MAESTRO | MAESTRO maps agent goals, tools, and trust boundaries for security design. | |
| NIST AI RMF | AI RMF governs risk and accountability for autonomous behaviour. | |
| NIST Zero Trust (SP 800-207) | TA.1 | Zero trust supports per-request verification instead of implicit trust in sessions. |
Replace long-lived secrets with ephemeral, task-scoped credentials and revoke them automatically.
