AI agent identity risk is outpacing enterprise IAM controls

At a glance

What this is: This report argues that AI agents should be treated as a high-risk non-human identity class because many organisations lack policies and controls for their autonomous access.

Why it matters: IAM and NHI teams need governance models that can constrain agent behaviour, audit access, and align IT, compliance, and executive oversight before scope drift becomes a security incident.

By the numbers:

• 96% of technology professionals identify AI agents as a growing security threat, and 66% believe this risk is immediate.
• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.

👉 Read SailPoint's research on AI agent identity risk and governance gaps

Context

AI agent identity risk is emerging because autonomous software can act, decide, and access resources without fitting neatly into human-centric IAM controls. Once an agent can reach sensitive data or tools, it becomes a non-human identity with real blast radius, not just an application feature. For NHI governance, the key issue is whether the organisation can define scope, review access, and prove control over agent behaviour.

The report frames a familiar pattern in a new form: adoption is moving faster than policy. That is typical of early NHI sprawl, where access is granted for utility first and governed later. The practical consequence is that security, compliance, and operations teams can each see part of the problem, but no one can fully answer who approved the agent, what it can reach, or when it should lose access.

Key questions

Q: How should security teams govern AI agents as non-human identities?

A: Security teams should assign each AI agent a unique identity, bind it to a specific owner, and limit it to approved tools, data, and environments. Governance should include short-lived access, continuous logging, and a revocation path that can remove privileges as soon as the task or workflow changes.

Q: Why do AI agents create more IAM risk than traditional workloads?

A: AI agents create more IAM risk because they can choose actions, chain tool calls, and change behaviour based on context, which makes their access less predictable than a standard workload. That increases the chance of scope drift, unintended data access, and privilege accumulation unless controls are continuously enforced.

Q: What is the difference between governing an AI agent and governing a service account?

A: A service account usually follows a fixed, machine-driven pattern, while an AI agent can make decisions and invoke tools dynamically. That means AI agents need stricter runtime policy checks, tighter task scoping, and more frequent access review than many conventional service accounts.

Q: When does AI agent access become a privilege problem?

A: AI agent access becomes a privilege problem when the agent can reach systems, data, or credentials beyond the exact task it was meant to perform. At that point, the issue is not only authentication, but blast radius, because a single agent identity can cause broader harm than its original role suggests.

Technical breakdown

Why AI agents behave like non-human identities

AI agents are not just software objects that call APIs. When they can choose actions, invoke tools, and retain context across tasks, they operate as non-human identities with delegated authority. That creates three control problems at once: authentication of the agent, authorisation for each action, and ongoing verification that the behaviour still matches intent. Traditional IAM often assumes a stable subject and predictable request patterns. AI agents break both assumptions because their access path can shift with prompts, workflows, and external data. Practical implication: treat agent identity, not only model output, as the control point.

Practical implication: Map each agent to an explicit identity, scope its tools, and review its privileges as if it were a privileged workload.

Where governance breaks down for autonomous access

Governance fails when organisations cannot trace what data an agent can see, what systems it can touch, and which policy decided that access. The report’s findings point to a common gap between intent and enforcement: policies may exist in principle, but few organisations have operational controls that bind those policies to runtime behaviour. That gap matters because autonomous agents can move faster than manual review cycles, especially when they chain actions across systems. Practical implication: build policy enforcement into the access path, not into after-the-fact review.

Practical implication: Use policy-based controls, logging, and approval workflows that enforce limits before the agent acts.

Identity blast radius and scope drift in agentic systems

The most important technical risk is not only compromise, but scope drift. An agent that starts with limited purpose can accumulate access, reusable credentials, and trust relationships until it can reach far more than its original job requires. That is identity blast radius: the practical extent of harm available to a single compromised or over-permissioned NHI. In agentic environments, blast radius expands quickly because tools often inherit broad entitlements for convenience. Practical implication: minimise standing access and isolate agent privileges by task, environment, and data class.

Practical implication: Reduce standing privilege, segment tools by task, and reassess access whenever the agent’s role changes.

Threat narrative

Attacker objective: The attacker objective is to abuse an over-permissioned agent identity as a trusted path to data, credentials, and downstream systems.

1. Entry occurs when an AI agent is granted access to enterprise tools and data without tightly bounded scope or continuous policy enforcement.
2. Escalation follows when the agent inherits broader permissions, reusable credentials, or chained tool access that exceeds its intended purpose.
3. Impact occurs when the agent performs unintended actions, exposes sensitive data, or leaks credentials into systems it should not reach.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.

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

NHI Mgmt Group analysis

AI agents should be governed as privileged NHIs, not treated as a new class of application feature. The report confirms that organisations are already letting agents touch sensitive systems before governance catches up. That is the same pattern seen in other NHI sprawl problems: access arrives first, and accountability arrives later. Practitioners should place agents inside identity, privilege, and audit controls from day one.

Policy without runtime enforcement is not governance. A policy document that says agents must not exceed scope does not stop a tool call, a data lookup, or a credential use at runtime. The governance model has to bind identity, authorisation, and logging together so decisions are enforced where the agent operates. Practitioners should assume manual review will always lag autonomous execution.

Identity blast radius is the right concept for agentic security. The security question is not simply whether an agent is allowed to exist, but how far it can go before a mistake becomes an incident. That lens pushes teams toward task-scoped access, short-lived credentials, and explicit separation between agent roles. Practitioners should measure and reduce agent blast radius the same way they would for a privileged workload.

Agent governance will require joint ownership across IT, compliance, and executive leadership. The report shows that visibility is uneven across those groups, which means risk decisions can be made without common context. That is a structural weakness, not a communication issue. Practitioners should formalise ownership, reporting, and review cadence before agent deployment becomes normalised.

Scope drift is the hidden failure mode in AI agent programmes. An agent may begin with a narrow task and gradually accumulate permissions, credentials, and trust relationships through automation. Once that happens, the control problem shifts from provisioning to containment. Practitioners should build controls that continuously verify intended scope rather than assuming the original approval still applies.

From our research:

• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so, according to AI Agents: The New Attack Surface report.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• The governance gap is widening as AI agent deployment accelerates, which is why practitioners should pair policy with continuous access controls and auditability.

What this signals

Identity blast radius will become the defining planning metric for agentic AI programmes. Organisations that cannot measure how far an agent can move, what it can read, and which tools it can invoke will struggle to explain risk in operational terms. With 80% of organisations already reporting agent behaviour beyond intended scope, the problem is no longer hypothetical. Teams should expect tighter scrutiny of delegated access, especially where OWASP Agentic AI Top 10 risks intersect with existing IAM controls.

The next phase of maturity will come from binding identity controls to runtime enforcement rather than relying on inventory alone. That aligns with the NIST AI Risk Management Framework, which pushes governance toward accountability and ongoing measurement instead of one-time approval. Practitioners should prepare for agent review processes that look more like privileged access operations than classic application onboarding.

As agent deployments expand, governance teams will need a way to distinguish intentional autonomy from uncontrolled privilege growth. The signal from this research is that many organisations are already behind: only 44% have formal policies, yet 98% plan to deploy more agents within 12 months. Practitioners should prioritise policy enforcement, audit coverage, and owner assignment before the agent population multiplies further.

For practitioners

• Define explicit agent identities Assign every AI agent a unique identity, owner, and business purpose so access can be traced back to a responsible team. Tie that identity to approved tools, datasets, and environments rather than to a generic service account.
• Enforce task-scoped privileges Limit each agent to the minimum permissions needed for a specific workflow, then remove access when the task ends. Use short-lived credentials and separate privileges by environment, data class, and tool chain.
• Instrument runtime policy checks Add approval, logging, and policy evaluation at the point where the agent requests data or invokes tools. This creates evidence for audit and reduces the chance that an agent can act outside intended scope unnoticed.
• Align governance ownership Create a formal review path that includes security, IT, compliance, and business owners before agents are expanded into new workflows. Use the review to confirm who approves access, who monitors drift, and who can revoke privileges.

Key takeaways

• AI agents are now an NHI governance problem because they can act, not just process, and that changes the risk model.
• The clearest evidence of maturity lag is the gap between 92% who see governance as critical and 44% who have policies in place.
• Practitioners should reduce agent blast radius with task-scoped privilege, runtime policy checks, and explicit ownership before deployment expands further.

Key terms

• AI Agent: An AI agent is autonomous software that can decide, act, and use tools with delegated authority. In security terms, it behaves like a non-human identity because it can access systems, move data, and trigger outcomes without direct human input for every step.
• Identity Blast Radius: Identity blast radius is the total amount of damage a single identity can cause if it is misused, compromised, or over-permissioned. For AI agents and other NHIs, it is shaped by tool access, data reach, credential scope, and how quickly privileges can be revoked.
• Scope Drift: Scope drift is the gradual expansion of an identity’s effective permissions beyond its original purpose. In NHI environments, it often happens when automation adds tools, credentials, or trust relationships faster than governance can review and remove them.
• Non-Human Identity: A non-human identity is any machine, workload, token, certificate, bot, or AI agent that authenticates to systems and is granted access. These identities need governance because they can hold privilege, touch sensitive data, and create security exposure without being tied to a person.

What's in the full report

SailPoint's full report covers the operational detail this post intentionally leaves for the source:

• Benchmark data on AI agent governance maturity across peer organisations for board and risk reporting
• Expert analysis of the identity risks posed by autonomous agents in enterprise environments
• Guidance on aligning executive awareness with IT and compliance expectations
• Framework references for mitigating AI agent threats through identity-centric controls

👉 SailPoint's full report includes the benchmark data, framework guidance, and expert analysis behind these findings.

Deepen your knowledge

AI agent identity governance is a core topic in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for autonomous workloads and delegated access, it is worth exploring.