Why do traditional customer IAM controls break down when AI agents act on behalf of users?

Why Traditional Customer IAM Breaks Down for AI Agents

Customer IAM was built around a human sitting in a session, making visible choices, and staying within predictable interaction patterns. AI agents change that model. They can chain tool calls, retry actions, reorder steps, and complete work faster than any manual review loop can follow. That makes static roles, long-lived sessions, and coarse approval gates a poor fit for autonomous execution.

The risk is not only overprivilege. It is also loss of attribution, weak containment, and audit trails that show who authenticated but not what the agent decided to do next. The OWASP NHI Top 10 and OWASP Agentic AI Top 10 both reflect the same operational reality: once an agent can invoke tools on behalf of a user, the security model must follow the workload, not just the person.

NHIMG research shows the maturity gap is already measurable, with The 2024 Non-Human Identity Security Report finding that 88.5% of organisations say their non-human IAM lags human IAM or is only on par with it. In practice, many security teams encounter agent abuse only after the first abnormal tool chain has already completed, rather than through intentional governance design.

How It Works in Practice

The control model needs to shift from static entitlements to runtime decisions. For agents, that usually means workload identity, short-lived credentials, and policy evaluation at the moment a task is executed. Current guidance suggests treating the agent as a distinct non-human principal with its own identity lifecycle, rather than as a proxy user session.

At a practical level, teams often combine several controls:

• Use workload identity as the primary identity primitive, such as OIDC-based proof or SPIFFE-style identities, so the platform can verify what the agent is before it gets access.
• Issue just-in-time, ephemeral credentials per task, with tight TTLs and automatic revocation when the task ends.
• Evaluate policy in real time with policy-as-code tools, so authorisation can consider task context, data sensitivity, environment, and destination system.
• Separate user intent from agent execution, so a user approval does not become a blanket permission for unlimited downstream actions.

This approach aligns with the direction of the NIST AI Risk Management Framework and the CSA MAESTRO agentic AI threat modeling framework, both of which emphasise governance, mapped risk decisions, and operational controls that keep pace with system behaviour. The operational lesson is reinforced by NHIMG case coverage such as the CoPhish OAuth Token Theft via Copilot Studio and Amazon Q AI Coding Agent Compromised reports, where delegated execution became the attack surface.

These controls tend to break down when agents are granted broad SaaS admin scopes or when one identity is reused across many tasks because policy no longer reflects the actual action being attempted.

Common Variations and Edge Cases

Tighter agent controls often increase integration and governance overhead, so organisations must balance safer execution against the need for low-friction automation. That tradeoff becomes especially visible when agents support customer service, finance operations, or developer tooling, where too much friction can cause teams to bypass controls entirely.

One edge case is delegated customer action, where the agent is allowed to operate within a human’s authority. Best practice is evolving here, but current guidance suggests the agent should receive narrowly scoped, time-bound access tied to a specific task, not the user’s full standing permissions. Another edge case is multi-agent orchestration, where one agent calls another. In that model, policy must track provenance across the chain, or accountability disappears as soon as the first tool hop occurs.

The strongest warning sign is reliance on static secrets or long-lived refresh tokens. NHIMG research on AI credential abuse and exposed keys shows why this matters, and the LLMjacking: How Attackers Hijack AI Using Compromised NHIs analysis highlights how quickly exposed credentials are targeted. External threat guidance from NIST AI Risk Management Framework and the MITRE ATLAS adversarial AI threat matrix supports the same conclusion: if the agent can act, it must be governed like an active workload, not a passive customer session.

Related resources from NHI Mgmt Group

• Why do traditional privacy controls break down when AI agents move from data collection to data use?
• Why do AI agents and automated accounts need separate identity controls from human users?
• 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?