AI agent identity risk is outpacing enterprise IAM controls

At a glance

What this is: This is an analysis of how AI agents inherit and exercise identity in enterprise environments, with a focus on why current IAM assumptions fail once agents can act on behalf of users across multiple tools.

Why it matters: It matters because practitioners now have to govern delegated, long-lived, and difficult-to-observe access paths that sit between human IAM, NHI controls, and emerging agentic workflows.

👉 Read Reveal Security's analysis of what security leaders should understand about AI agents

Context

AI agents are software entities that can make decisions and take actions on behalf of a user, which means they inherit identity, permissions, and accountability concerns that were built for people or fixed workloads. The first governance mistake is to treat them as just another automation layer, when the article shows they operate inside user-authorised contexts and can act with the user’s badge.

For IAM teams, the problem is not only access sprawl but also the mismatch between human review processes and machine-speed execution. Once an agent has OAuth, SAML, or platform-native permissions, it can retain and exercise access long after the original task or user intent has changed, which creates a governance gap across human IAM, NHI controls, and lifecycle management.

The article’s examples across endpoint agents, first-party SaaS agents, and the productivity-tool middle layer show that visibility and revocation are uneven. That makes agent identity a programme issue, not a point-product issue, because the same delegated access can span multiple control planes without a clean ownership boundary.

Key questions

Q: How should security teams govern AI agents that can access enterprise systems?

A: Security teams should govern AI agents as non-human identities with explicit ownership, scoped privileges, and continuous monitoring. The control set should include inventory, task-bound credentials, audit trails, and revocation paths. If an agent can call tools or touch production systems, it belongs in the same governance model as service accounts and other machine identities.

Q: Why do AI agents create new risk in non-human identity management?

A: AI agents create risk because they operate as software identities with delegated authority, but many organisations do not track them with the same discipline applied to users or service accounts. They can connect quickly, persist across teams, and accumulate permissions that are hard to review. That combination increases the chance of unnoticed access drift and credential exposure.

Q: What breaks when agent access is treated like a normal service account?

A: You lose visibility into why a specific call was allowed, which context justified it, and whether the action still made sense at the time it executed. Agents can behave differently from ordinary service accounts because they make multiple decisions inside one workflow. Governance has to follow the action chain, not just the identity label.

Q: Who is accountable when an AI agent uses delegated access incorrectly?

A: Accountability should follow the delegated authority chain, not stop at the agent label. The relevant owners are the teams responsible for the human identity, the service identity, the workflow, and the policy that allowed the action path. If those responsibilities are not explicit, incident review will be incomplete and remediation will focus on the wrong layer.

Technical breakdown

Why agent identity behaves like delegated access, not simple automation

An AI agent is not just scripted automation with better language output. It is a software entity that receives context, requests permissions, and can act within that granted scope as if it were the user. That matters because the identity boundary moves from a fixed system account to a dynamic delegation model, where the agent may be able to read mail, move files, query calendars, and call downstream tools. The security problem is not only what the agent can do, but how quickly permissions become broad enough to support the task. Practical implication: model agents as delegated identities with explicit scope, not as generic workflow tooling.

Practical implication: model agents as delegated identities with explicit scope, not as generic workflow tooling.

MCP, APIs, and why tool access changes the trust model

Model Context Protocol, or MCP, gives an agent a structured way to talk to tools and services, often wrapping APIs in a more opaque experience for the user. That increases convenience, but it also widens the blast radius if the agent is over-permissioned or if the connected toolchain is poorly governed. In practice, the risk is less about the protocol itself and more about the access patterns it normalises: broad read permissions, persistent tokens, and cross-service movement that users do not always understand at grant time. Practical implication: review every agent-tool connection as an identity trust decision, not just an integration choice.

Practical implication: review every agent-tool connection as an identity trust decision, not just an integration choice.

Long-lived OAuth tokens create persistence that human review never sees

When an agent authenticates through OAuth, Login with Google, Login with Microsoft, or similar federated paths, the resulting token can outlive the immediate task and remain valid until explicitly revoked or expired. That turns a one-time approval into standing access unless lifecycle controls are enforced tightly. The hard part is that the token is often granted in a user interface that encourages broad acceptance, while the review process happens later, if it happens at all. Practical implication: treat token lifetime, grant scope, and revocation path as first-class governance controls for agent access.

Practical implication: treat token lifetime, grant scope, and revocation path as first-class governance controls for agent access.

Threat narrative

Attacker objective: The objective is to convert delegated agent access into durable, cross-service reach that can be used for data theft or operational misuse.

1. Entry begins when an attacker gains control of a still-valid delegated token or abuses an overbroad agent grant that was approved for productivity use. Escalation occurs when the token or agent context allows access to mail, files, calendars, or chat data beyond the original business need. Impact follows when the actor uses that standing access to enumerate, copy, or exfiltrate information across connected services before revocation catches up.

Breaches seen in the wild

• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.
• Replit AI Tool Database Deletion — Replit vibe coding AI assistant deletes live production database and creates 4,000 fake user records.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Agent identity exposes a delegation gap that classic IAM reviews were never designed to close. Human access review processes assume a person can be certified, challenged, or removed through a normal governance cadence. That assumption weakens when a software agent can acquire broad permissions, act immediately, and keep using them without a durable human workflow in the middle. The implication is that agent governance cannot inherit human review mechanics unchanged.

Ephemeral task context does not eliminate standing privilege debt. The article shows that agents are often approved through broad consent screens and then left connected to multiple services. That creates a form of privilege persistence even when the user thinks the task is temporary. For practitioners, the problem is not just token age but the mismatch between temporary intent and durable access.

Identity blast radius is now determined by the breadth of the tool graph, not the number of users. A single agent can touch desktop files, SaaS applications, and downstream APIs in one execution path. That means access concentration can occur without classic account sprawl, which is why NHI governance, SaaS entitlement control, and lifecycle offboarding must be analysed together. Teams should measure the tool graph, not just the account count.

The ‘mushy middle’ is where control assumptions fail fastest. Endpoint agents have device-level ambiguity, first-party agents have platform controls, but third-party productivity agents often sit between both models. This is the named concept that matters here: the runtime governance gap between user consent and controllable execution. Practitioners should treat that middle layer as an identity boundary that needs explicit ownership.

Access review cadence becomes a weak control when execution is faster than certification. The article’s central lesson is that agent behaviour can outpace the normal cadence of IAM operations. When permissions are granted, used, and forgotten inside a short operational window, review artefacts arrive too late to matter. The implication is that governance has to move closer to runtime, because retrospective certification alone no longer contains the risk.

From our research:

• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities, according to The State of Non-Human Identity Security.
• Another finding from our research shows that 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, which underscores how quickly delegated access becomes ungoverned at runtime.
• For a forward view on lifecycle control, see Top 10 NHI Issues for the governance gaps that most often turn delegated access into persistent risk.

What this signals

Runtime consent, not account count, is becoming the real identity governance variable. As agents spread across endpoints and SaaS tools, security teams need to measure how much access can be activated in one workflow, not how many identities exist on paper. That shifts the programme from inventory alone to permission shape, revocation speed, and tool-chain visibility.

The practical signal is that IAM, IGA, and NHI programmes are converging on the same control question: who can act, across which tools, for how long, and with what traceability. If that question cannot be answered in one control plane, the organisation is already relying on trust rather than governance. Teams should expect more demand for agent-specific policy, evidence, and lifecycle offboarding.

Security leaders should also expect the middle layer of third-party productivity tools to become the hardest part of the estate to govern. It is easy to see the endpoint agent and easier to govern the first-party platform, but the cross-service path is where oversight disappears. That is why the identity blast radius now needs to be part of standard access-risk reporting.

For practitioners

• Inventory every agent-touchpoint across identity, SaaS, and desktop layers Build a single register of where agents can authenticate, what data they can reach, and which human or service principal granted the access. Include OAuth grants, platform-native copilots, MCP-connected tools, and browser-driven workflows. Map each connection to an accountable owner and a revocation path.
• Constrain consent screens to the minimum task scope Require task-specific approval boundaries for agents that request mail, file, calendar, chat, or desktop permissions. If a request reads like full user replication, redesign it so the agent can only reach the exact resource set needed for the job. Avoid enterprise-wide blanket acceptance for convenience.
• Shorten token lifetime and force explicit re-authorization Set tighter expiry windows for delegated tokens used by agents and remove any assumption that a one-time approval is acceptable for ongoing use. Pair expiry with automated revocation checks when the user, device, or business task changes. This is especially important for tokens tied to deprovisioned accounts.
• Monitor agent activity as identity behaviour, not just endpoint behaviour Correlate access to files, messages, calendars, and downstream APIs so that unusual breadth or timing stands out. A device alert alone will miss many agent workflows because the risk is distributed across services. Build detection around tool sequences and permission use, not just signatures.

Key takeaways

• AI agents behave like delegated identities, which means their permissions must be governed as access grants rather than as simple automation settings.
• Persistent OAuth-style access, broad consent screens, and cross-service tool use create identity blast radius that human review cycles often miss.
• Security teams need runtime visibility, explicit scope, and rapid revocation if they want agent governance to keep pace with enterprise adoption.

Key terms

• Delegated Identity: Delegated identity is when one actor acts on behalf of another with explicit permission and bounded authority. In AI-assisted commerce, it requires clear consent, limited scope, and traceable records so the retailer can distinguish authorised delegation from unauthorised automation.
• Identity Blast Radius: Identity blast radius is the amount of data, systems, and actions reachable through a single set of credentials or grants. For AI agents and NHIs, it is determined by permission breadth, token lifetime, and the number of connected tools, not just by how many accounts exist.
• Agentic Runtime Governance Gap: The distance between approving an AI agent as a project artefact and controlling its actual production behaviour. This gap appears when static approvals, access reviews, or policy documents do not keep pace with the agent’s live tool use and changing operational context.
• Persistent Token Risk: Persistent token risk is the exposure created when a credential or grant remains valid long after the immediate task is complete. In practice, it turns a temporary approval into standing access unless the organisation actively monitors expiry, scope changes, and revocation events.

What's in the full article

Reveal Security's full blog covers the operational detail this post intentionally leaves for the source:

• The article’s step-by-step examples of how endpoint agents, SaaS agents, and productivity-tool agents differ in risk shape.
• The permission-screen behaviour described in the article, including how broad access requests are approved in practice.
• The article’s concrete walkthrough of local desktop agent behaviour and cross-service data movement.
• The author’s explanation of why human-in-the-loop controls are often too late when agents execute quickly.

👉 Reveal Security's full blog covers the agent permission model, tool-chain behaviour, and the control gaps leaders need to see.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.