AI agent identity risk exposes the limits of legacy IAM models

At a glance

What this is: This is an analysis of AI agent identity risk showing that legacy IAM models cannot keep pace with agent-driven SaaS access, OAuth trust, and machine-speed action chaining.

Why it matters: It matters because IAM, PAM, and NHI programmes now have to govern agent behaviour, not just logged-in accounts and approved integrations.

By the numbers:

• 99.4% of organizations experienced at least one SaaS or AI security incident in 2025, according to Vorlon’s 2026 CISO report.
• 86% of security teams still cannot see what their AI agents are actually doing, according to Vorlon’s 2026 CISO report.

Context

AI agent identity risk is the governance gap that appears when software can authenticate, call tools, and move data without waiting for a human operator to step through each action. Legacy IAM was built for people and conventional application flows, so it often tracks access grants better than it tracks runtime behaviour across SaaS, integrations, and emerging protocol chains such as MCP.

Vorlon’s article argues that the real engine room is the sequence of authenticated actions between AI agents, SaaS systems, OAuth tokens, and third-party tools. That makes the question for practitioners less about whether an agent exists and more about whether identity controls can observe, constrain, and revoke what it does once those trusted connections are live.

The article is framed around agentic ecosystem security, but the underlying issue is broader than one product category: when machine-speed execution enters identity governance, traditional review, inventory, and approval models start to lag the risk they were designed to control.

Key questions

Q: What breaks when agentic AI is governed like a normal application account?

A: Security controls break down because agentic systems do not behave like fixed-function applications. They can choose actions at runtime, combine tools in unexpected ways, and move faster than periodic review cycles. That means static roles, annual recertification, and one-time approvals do not fully describe the risk or contain the behaviour.

Q: Why do OAuth tokens increase lateral movement risk in SaaS environments?

A: OAuth tokens increase lateral movement risk because they can remain valid after the initial user session, bypass MFA, and preserve scoped access until revoked. In SaaS environments, that makes a single consented app a durable bridge into email, files, logs, and admin-adjacent data. Identity governance must treat token scope and revocation as first-class controls.

Q: How can security teams tell whether agent access is actually under control?

A: Look for evidence that the team can trace every tool call, secret use, and cross-system action back to a named owner and a valid approval path. If an agent can reach messaging, browser, and infrastructure tools without a revocation chain, access is not truly governed. Control exists only when the runtime can be stopped as fast as it can act.

Q: Should organisations treat AI-generated code as a separate governance category?

A: Yes, because AI-generated code introduces a trust problem that sits between development, application security, and identity governance. Teams need policy for what AI may generate, how outputs are validated, and how identities and secrets are handled in the resulting code. Without that, responsibility for unsafe behaviour becomes fragmented across teams.

Background and context

Why AI agent authentication changes the identity control plane

AI agents do not only log in, they initiate a chain of authenticated actions across SaaS applications, APIs, and connected tools. That matters because the control plane is no longer just verifying identity at sign-in, it is governing what the actor can do after trust has already been established. In practice, OAuth tokens, delegated access, and integration trust become the path of least resistance. If the agent can call a tool, fetch records, and write output without a human in the loop, then the identity event is not the login alone. The security problem is the runtime sequence that follows.

Practical implication: Treat post-authentication behaviour as part of the identity boundary, not as an application-only concern.

MCP and trusted integrations create chained access paths

MCP connects agents to tools and data sources, which makes it a useful abstraction for orchestration but also a concentration point for identity risk. The challenge is not that every MCP connection is unsafe, but that each trusted hop extends the effective blast radius of the original identity decision. Once an agent can move from Salesforce to another third-party tool, the risk becomes transitive: one trusted integration can carry authority into multiple systems. That is why inventory alone is insufficient. Security teams need to understand which actions are authorised, which are inherited, and which are simply assumed safe because they sit behind a trusted connector.

Practical implication: Map delegated trust across every agent-to-tool and SaaS-to-SaaS hop before you assume the integration is benign.

Why legacy IAM visibility breaks at machine speed

Legacy IAM models assume that access can be reviewed, observed, and corrected on a human timescale. AI agents compress that timeline by authenticating, acting, and handing off data in rapid succession. The result is an observability mismatch: the control may know the token exists, but not what the agent did with it across multiple systems. That is why dormant integrations and authorised identities become attractive abuse paths. When behaviour is distributed across services, the most important signal is no longer just who authenticated, but what the authenticated actor changed, exported, or triggered in the downstream environment.

Practical implication: Shift monitoring from static entitlement lists to runtime action sequences and data movement patterns.

NHI Mgmt Group analysis

Agentic identity risk is an IAM problem, not just an AI problem. The article shows that once software can authenticate and act across tools, identity governance inherits runtime behaviour it was not designed to supervise. The practical consequence is that access decisions can no longer stop at provisioning, because the risk lives in the sequence of tool use after trust is granted.

Legacy IAM assumptions about reviewability are breaking under machine-speed execution. Access reviews presume privilege persists long enough to be observed, certified, and remediated. AI agents can acquire and spend trust inside a short action chain, which means the governance model is chasing behaviour after the fact. Practitioners need to recognise that the defect is temporal as much as structural.

Trusted integrations have become the modern identity blast radius. Vorlon’s framing of SaaS, AI agents, and integrations as one attack surface is directionally correct because authority now moves laterally through delegated trust rather than only through direct compromise. That creates a named governance concept worth tracking: runtime trust spillover, where one approved connection expands the practical reach of the original identity decision. Security teams should govern the spillover, not just the account.

Human-centric controls cannot be the default for autonomous behaviour. The article’s own data points to a visibility gap between what teams believe is authorised and what agents actually do. That gap is why agentic activity must be evaluated through runtime policy, data context, and revocation speed rather than through human workflow assumptions. Identity programmes that do not distinguish operator intent from system execution will keep underestimating risk.

Agentic ecosystem security is becoming a standard governance requirement. The combination of SaaS integration density, AI agent autonomy, and opaque downstream tool use means the next phase of IAM will look less like account administration and more like operational control of machine-mediated authority. That is a material shift for IAM, PAM, and NHI governance teams, which should align controls to where action happens, not where login happens.

What this signals

Runtime trust spillover: Once an agent can inherit trust from one SaaS connection and use it across another tool or data path, the governance problem shifts from account inventory to delegated authority containment. Programmes that still anchor on static entitlements will miss where the real exposure accumulates.

Agentic identity governance should now be designed around action visibility, not just approval records. The operational question is whether a team can see, explain, and stop what an agent did after it authenticated, because that is where abuse becomes consequential.

For practitioners

• Inventory agentic trust chains Map every AI agent, OAuth grant, SaaS integration, and third-party tool that can act on behalf of the business, then classify which links can move data or trigger actions without human review.
• Separate login visibility from action visibility Add monitoring for the actual operations performed by agents, including record reads, writes, exports, and downstream tool calls, instead of relying only on sign-in or token issuance logs.
• Constrain high-risk delegated actions Set policy limits around customer records, PCI, PHI, and other sensitive data categories so agentic workflows can be blocked or quarantined when they exceed approved boundaries.
• Build revocation paths for dormant integrations Ensure tokens, connected apps, and agent credentials can be revoked quickly when behaviour changes, a vendor is breached, or an integration begins exporting data unexpectedly.
• Test blast-radius containment Run scenarios that start with a trusted agent account and verify how far it can move across SaaS and third-party tools before containment actions take effect.

Key takeaways

• AI agents expose a governance gap that legacy IAM was never built to supervise, because the risky behavior happens after authentication rather than at it.
• Vorlon’s report says almost every organisation saw at least one SaaS or AI security incident in 2025, while most teams still lacked visibility into agent behavior.
• Practitioners should govern delegated trust, runtime actions, and rapid revocation together, or agentic access will keep expanding the blast radius of ordinary credentials.

Key terms

• Agentic risk: Agentic risk is the security and governance exposure created when an AI system can make decisions, use tools, or take actions with limited human intervention. The risk is not only access to data, but the possibility that the system will pursue an unsafe path once it has access.
• Runtime Trust Spillover: The expansion of effective authority when one trusted agent or integration passes its access into another system or tool chain. The original permission may be valid, but the practical blast radius grows as the actor moves through delegated connections and inherited trust.
• Delegated Authority Model: A delegated authority model defines who is allowed to approve, review, or execute control-related decisions across the enterprise. It helps ensure requests reach the correct responsible party, especially when control owners, managers, and process owners sit in different teams, regions, or systems.
• Machine-speed governance: Identity and access control that operates fast enough to keep up with automated or agentic execution. The concept matters because a control that works for humans but cannot respond within the session, task, or policy window is not actually governing the actor.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.