Legacy IAM breaks when it assumes slower, human-paced access patterns. Agentic systems need identity, authorization, and policy enforcement to happen continuously and at runtime, not just at login. If controls cannot verify integrity, scope, and expiry at each interaction, agents can retain excessive access, create governance gaps, and widen the attack surface.
Why This Matters for Security Teams
Legacy IAM was built for people who log in, work, and log out. agentic ai workloads behave differently: they can chain tools, retry actions, and make new decisions mid-task. That means authorization cannot be a one-time event at session start. Guidance from the OWASP Agentic AI Top 10 and NHI research at OWASP Agentic Applications Top 10 both point to the same issue: static entitlements do not reflect runtime intent.
The operational risk is not only excess access. Agents can inherit tokens, trigger downstream APIs, and persist privilege longer than intended if expiry and revocation are not enforced continuously. That creates a wider blast radius than most legacy access reviews assume. In practice, many security teams encounter the breakage only after an agent has already accessed data or systems beyond its intended scope, rather than through intentional policy testing.
How It Works in Practice
For agentic workloads, the identity primitive should be the workload, not a human proxy. Current guidance suggests using workload identity, short-lived credentials, and policy evaluation at request time so the system can verify what the agent is, what it is trying to do, and whether the current context allows it. The SPIFFE workload identity specification is relevant here because it anchors identity in cryptographic proof, not in a long-lived secret copied into an agent runtime.
That changes the control model in three ways. First, authorisation becomes intent-aware: an agent asking to read a file, invoke a tool, or write to a ticketing system should be evaluated against current policy, not a pre-approved login session. Second, credentials should be issued just in time and revoked as soon as the task ends, which reduces the value of leakage. Third, secrets should be short-lived and scoped tightly enough that replay and lateral movement become harder, even when the agent is compromised. Research from AI Agents: The New Attack Surface report shows why this matters: only 52% of companies can track and audit the data their AI agents access, leaving a large blind spot for investigation and compliance.
- Use workload identity for the agent runtime, not shared human credentials.
- Issue ephemeral tokens per task, with automatic expiry and revocation.
- Evaluate policy at each tool call, API request, or data access event.
- Log the agent’s intent, target resource, and decision outcome for auditability.
Legacy IAM usually breaks down when agents operate across multiple tools and identities in parallel because the control plane cannot keep pace with dynamic, machine-speed decision making.
Common Variations and Edge Cases
Tighter runtime controls often increase engineering overhead, requiring organisations to balance least privilege against orchestration complexity. That tradeoff is real, especially where agents must work across SaaS apps, internal APIs, and external connectors. Best practice is evolving, and there is no universal standard for how much autonomy should be granted to each class of agent.
Some environments can still use role-based access control for coarse segmentation, but RBAC alone is not enough when the same agent can shift from analysis to execution in seconds. In those cases, policy-as-code and contextual checks, as described in the NIST AI Risk Management Framework, should sit alongside identity controls. NHI case studies such as Moltbook AI agent keys breach and CoPhish OAuth Token Theft via Copilot Studio show how quickly exposed or over-scoped credentials can be abused once an agent is treated like a normal user session.
The main exception is tightly sandboxed, single-purpose automation with no external tool access and no persistent memory. Even then, organisations should assume the scope can expand later. These controls tend to break down when an agent can call unvetted tools or inherit legacy service accounts because the access path becomes too dynamic for static IAM to govern safely.
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, CSA MAESTRO and OWASP Non-Human Identity Top 10 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 | A2 | Static IAM fails when agent actions are not known in advance. |
| CSA MAESTRO | M1 | MAESTRO covers runtime trust and control for autonomous agents. |
| NIST AI RMF | AI RMF addresses governance, accountability, and operational risk for AI systems. | |
| OWASP Non-Human Identity Top 10 | NHI-03 | Short-lived secrets and rotation are central to limiting agent credential abuse. |
| NIST Zero Trust (SP 800-207) | PR.AC-1 | Zero Trust requires continuous verification, not one-time session trust. |
Assign owners, assess agent risk continuously, and document controls for each autonomy tier.
Related resources from NHI Mgmt Group
- What breaks when organisations rely on legacy DLP for AI workflows?
- What breaks when organisations rely on detection-only controls for agentic AI?
- What breaks when organisations rely only on pre-deployment testing for agentic AI security?
- What breaks when organisations rely only on managed AI platforms for high-volume workloads?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 26, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
