AI agent sprawl exposes governance gaps in enterprise access

At a glance

What this is: This is an analysis of how AI agents become risky when inherited permissions, sharing, and ownership drift are not continuously governed.

Why it matters: It matters because IAM, IGA, and PAM teams now have to govern agent behaviour after deployment, not just approve access at creation time.

By the numbers:

• Most organizations have 800+ risky agents operating without security oversight.
• agents granted an average of 43 permissions but actively using 4.

👉 Read Obsidian Security's analysis of risky AI agents and governance gaps

Context

AI agents introduce a governance problem that looks familiar at first but behaves differently in practice. They inherit permissions from the user who created them, then keep operating as access is shared, ownership changes, or the agent is published beyond the original control boundary.

For IAM and NHI programmes, the issue is not simply that agents have access. It is that their access can outlive the person who configured it, and their effective privilege can diverge from the original approval state. That makes static review models incomplete for agent identity governance.

The article argues that teams need continuous discovery, end-to-end governance, and runtime enforcement because agent inventories and risk states change after deployment. That starting point is typical for organisations that have expanded AI usage faster than their control plane has matured.

Key questions

Q: How should security teams govern AI tools that inherit user permissions on endpoints?

A: Treat each OAuth-connected assistant, plug-in, or local model as a non-human identity with delegated authority. Map what it can read, change, or trigger, then bind it to ownership, review, and revocation controls. If the tool can act on behalf of a user, it belongs in the same governance cycle as other privileged access, not in an informal exception path.

Q: Why do AI agents create a larger security risk than ordinary web applications?

A: AI agents can act with delegated authority, chain tool calls, and reach internal APIs without human pacing. That means a compromise can move from data exposure to active execution much faster than in a traditional web app. The risk is not just stolen data, but uncontrolled use of the identity and permissions attached to the agent.

Q: What breaks when AI risk reviews are done only at deployment time?

A: You miss the behaviour that appears after launch. Models change, prompts are edited, connectors are added, and a previously acceptable workflow can become risky without any formal re-review. Static assessment creates stale assurance, which is especially dangerous when the system can act faster than a human can intervene.

Q: Who should be accountable when an AI agent retains access after a project ends?

A: The accountable party should be the current human sponsor who can explain why the agent still exists and approve its continued access. Creator history is useful, but it is not sufficient once teams change, projects end, or identities are reused. Accountability has to follow operational ownership, not historical creation metadata.

Technical breakdown

Inherited permissions and privilege drift in AI agents

AI agents typically begin with the permissions of the human user who creates or connects them to tools. The risk appears when the agent is then shared more widely, published through a public URL, or left running after the original owner is no longer present. At that point, effective access no longer matches the original access decision. The core failure is privilege drift across the agent’s operational life, not simply excessive permissions at provisioning time. In identity terms, the agent behaves like an NHI whose entitlement state changes without a corresponding governance event.

Practical implication: treat agent ownership and effective access as mutable identity data, not a one-time approval record.

Continuous discovery versus deployment-time review

Traditional deployment review assumes a bounded system: inspect the code, validate the configuration, approve the integration, and then trust the result until the next change. AI agents break that model because they evolve after deployment as integrations are added, permissions expand, and sharing patterns change. A quarterly audit cannot capture a living agent inventory with enough fidelity. Continuous discovery is therefore a control-plane requirement, not a reporting enhancement. It provides the current inventory, ownership, scope, and integration context needed to decide whether an agent is still operating within policy.

Practical implication: maintain a live inventory of agents with ownership, scope, and connected systems instead of relying on periodic reviews.

Runtime enforcement for agent access

Runtime enforcement becomes necessary because static policy checks cannot see how an agent behaves once it starts operating. The article recommends observation mode first, which is a sensible way to learn normal traffic patterns before blocking access. This is especially important where agents are high privilege but low-use, because apparent entitlement size often overstates legitimate need. Runtime controls let teams detect unauthorized access to sensitive systems and constrain behaviour once the actual access pattern is understood. That is a different control problem from provisioning or recertification.

Practical implication: begin with observed behaviour baselines and narrow runtime policies before moving to blocking enforcement.

Threat narrative

Attacker objective: The attacker or risk condition seeks sustained access through an agent identity whose privileges outlive ownership and oversight.

1. entry: A user creates an AI agent and connects it to tools, giving it inherited access through the creator's permissions.
2. escalation: The agent is shared with lower-privilege teammates or published publicly, causing its effective reach to expand beyond the original approval state.
3. impact: The agent continues running after the owner leaves, leaving a high-privilege, unmonitored identity that can reach sensitive systems and data.

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 access becomes an NHI governance problem the moment it outlives the creator. The article shows that AI agents inherit a human's permissions, then continue operating after those permissions should have been reconsidered. That places them inside the NHI governance model, not outside it, because the control question becomes who owns the access state once the human actor is no longer in the loop. Practitioners should treat the agent as a governed identity with a lifecycle, not as a feature attached to an application.

Continuous discovery is the missing control plane for AI agent sprawl. Quarterly review models assume a stable population of identities and a stable set of entitlements. Agents change after deployment as they are shared, republished, or left behind, so the inventory must move at the same pace as the runtime. That makes live ownership, scope, and integration context the minimum viable governance signal for agent security.

Standing privilege is not the same thing as visible usage. The article's 43 permissions versus 4 active permissions figure is a reminder that entitlement volume can hide an enormous amount of dormant risk. A low-use agent can still carry high-impact access if it retains the right tool connections or data paths. The implication is that access review has to examine potential blast radius, not just recent activity.

Runtime enforcement is where AI agent governance stops being theoretical. Security teams cannot prove control over agent behaviour if they only inspect configuration at deployment time. Observation mode first, then narrowly scoped enforcement, reflects the reality that agent traffic needs to be understood before it is constrained. Practitioners should assume the control gap is behavioural, not just administrative.

Identity blast radius is the right concept for agent risk. The article shows that the decisive issue is not how many agents exist, but how far one agent can reach once its permissions, sharing state, and ownership drift are combined. That is a governance pattern spanning IAM, IGA, and PAM. Teams need to measure blast radius explicitly, because entitlement counts alone understate the operational risk.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
• 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.
• Use OWASP NHI Top 10 to map agentic identity risk to a broader control model before agent sprawl outpaces governance.

What this signals

Identity blast radius is becoming the practical unit of measure for AI agents. If an agent can inherit permissions, be shared, and keep running after its owner leaves, the question is no longer whether it exists, but how far it can reach before anyone notices. Teams should expect agent inventories to grow faster than manual governance can keep up, which makes continuous discovery and access scope mapping essential.

With 80% of organisations already seeing agents act beyond intended scope, the control gap is not hypothetical. The next step for mature programmes is to connect agent ownership, entitlements, and runtime behaviour in one workflow, using governance tooling that can survive account turnover and tool sprawl.

A useful benchmark is whether your programme can answer, in near real time, which agents can touch sensitive systems and who can revoke them. If that answer depends on a quarterly review, the control model is already lagging the operational risk.

For practitioners

• Implement live agent inventory controls Track every agent at the moment it appears, with owner, access scope, connected tools, and publishing state. Use that inventory as the source of truth for review and response.
• Reconcile effective access against intended access Compare each agent's granted permissions with what it actually uses, especially where the article's pattern shows 43 permissions but only 4 are actively used. Focus review effort on agents with broad entitlement and low visibility.
• Tie agent ownership to lifecycle events Remove or revalidate agent access when the human owner changes role, leaves the organisation, or loses the account used to create the agent. Treat account disablement as a governance trigger for dependent agents.
• Deploy observation-mode runtime policies Start with monitored policy enforcement for agent access to sensitive systems, then expand to targeted blocking rules once normal behaviour is established. This reduces false positives while giving teams actionable telemetry.
• Prioritise high-blast-radius agents first Rank agents by data reach, system reach, and integration depth, then remediate the ones that can touch sensitive environments even if they appear low risk by usage volume.

Key takeaways

• AI agents are becoming governed identities in their own right, because their privileges can outlive the human who created them.
• The strongest evidence of risk is not just how many agents exist, but how often they act beyond intended scope and how little of their access is actually reviewed.
• IAM, IGA, and PAM teams need continuous discovery and runtime enforcement if they want to control agent blast radius after deployment.

Key terms

• AI Agent Identity: The digital identity used by an autonomous AI agent to authenticate to external systems, APIs, and services. Managing AI agent identities is an emerging and rapidly evolving area of NHI security.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
• Runtime Enforcement: Runtime enforcement is the practice of blocking malicious behaviour while software is running, rather than only detecting it after the fact. It monitors process activity, network actions, and privilege changes so a live attack can be interrupted at the point of execution.
• Continuous discovery: Continuous discovery is the ongoing process of detecting identities as they appear, change, or disappear across environments. For AI agents and other NHIs, it prevents inventory drift and keeps ownership, privilege, and lifecycle controls aligned with the live environment.

What's in the full article

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

• The full agent inventory and risk scoring approach behind the 800+ risky agents finding.
• Operational examples of continuous discovery fields such as ownership, scope, and integration context.
• Runtime enforcement guidance for moving from observation mode to targeted blocking.
• The article's breach context and the Salesforce exposure discussion referenced in the post.

👉 The full Obsidian Security post covers the agent inventory model, runtime enforcement approach, and breach context in more detail.

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 identity security programme, it is worth exploring.