AI agent sprawl is exposing toxic access combinations in apps

At a glance

What this is: AI agent use is expanding rapidly, and the key finding is that risk comes from toxic combinations of overprivilege, hidden ownership, and chained workflows rather than from any single agent alone.

Why it matters: IAM, IGA, and security teams need to govern agents as first-class non-human identities because human-centric visibility, review, and audit models miss how agent permissions accumulate and spread.

By the numbers:

• AI agent activity grew 300x in 2025 as employees started building and connecting personal agents to enterprise applications.
• Nearly 40% of agents carry medium-to-critical risk factors in the average environment.
• Over 800 risky agents exist in the average environment.
• Agents move 16x more data than human users on average.

👉 Read Obsidian Security's analysis of AI agent sprawl and hidden access drift

Context

AI agent identity security is becoming a governance problem, not just a tooling problem. The article shows that employees are connecting agents to calendars, cloud drives, CRM systems, and code pipelines faster than security teams can review the resulting access model, which means the effective identity perimeter is now expanding inside business applications.

The central failure is familiar to identity teams: access is granted for speed, then left to drift. In this case, the drift is amplified by machine-speed execution, hidden delegation chains, and the fact that an agent can become the common access layer for many users, creating exposure that traditional IAM and SIEM workflows do not see in time.

That makes AI agents structurally different from ordinary SaaS integrations. They combine application access, broad data visibility, and delegated execution in ways that look legitimate individually but become toxic when composed across workflows, owners, and connected systems.

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 more identity risk than ordinary SaaS integrations?

A: AI agents can operate continuously, chain multiple tools, and act on delegated permissions with little human oversight. That makes their effective privilege broader than the original approval suggests. The risk is not only access, but the speed and persistence with which the agent can turn access into credential exposure or lateral movement.

Q: What breaks when AI agents are given broad inherited permissions?

A: Broad inherited permissions break the assumption that access is tied to a narrow business need. The result is larger blast radius, weaker accountability, and faster propagation of mistakes or abuse across connected systems. A single compromised or misconfigured agent can then touch far more data and workflows than the original task required.

Q: Who is accountable when an AI agent accesses sensitive data it was not meant to use?

A: Accountability sits with the team that approved the agent, its connectors, and its policy boundaries, not with the runtime behaviour alone. Organisations need ownership for intent, permissions, monitoring, and validation so they can prove whether the agent stayed inside its approved purpose. Without that, audit and regulatory response become retrospective guesswork.

Technical breakdown

Why AI agent permissions become toxic in enterprise apps

AI agents usually inherit the permissions of the user or service token used to create them, but the practical access shape often expands after deployment. The article's examples show broad read access, shared visibility, and reused credentials being combined with business convenience, then forgotten. That creates an identity object whose real privileges are broader than the original intent. In IAM terms, the problem is not just overprovisioning. It is the combination of entitlement scope, data reach, and downstream reuse that turns a normal integration into a high-blast-radius identity.

Practical implication: map each agent to its actual entitlement set, not its intended use case, before allowing it to persist.

How chained workflows turn separate approvals into one attack path

The article's planning-to-coding-to-deployment example shows a delegated workflow in which each step trusts the previous output. That pattern matters because compromise does not need to happen at the final tool. A malicious instruction injected into an upstream input can propagate through a sequence of agents and trigger downstream actions that are individually valid but collectively harmful. This is a classic trust propagation problem, where local correctness does not guarantee global safety. The control challenge is therefore about inter-step verification and provenance, not just endpoint hardening.

Practical implication: require explicit trust boundaries and validation checkpoints between agents in any multi-step workflow.

Why auditability fails when agents operate faster than human review

Auditability depends on being able to reconstruct who initiated an action, what data was touched, and which identity held the authority at the time. The article shows that this breaks down when agent activity is high-volume, ownerless, or tied to stale credentials. Once the agent is out of lifecycle alignment, logging alone is not enough if the organisation cannot connect action to owner and entitlement state. For regulated environments, that means the audit gap is not a missing report; it is a missing governance model for non-human execution.

Practical implication: tie every agent action to ownership, entitlement, and lifecycle state so audit evidence remains usable.

NHI Mgmt Group analysis

AI agent governance is becoming an NHI problem before it becomes an AI problem. The article shows that the real failure mode is not model output, but delegated access that outgrows human review cycles. Once agents are connected to business systems, they behave like non-human identities with operational reach, entitlement drift, and lifecycle risk. That means IAM, IGA, and PAM teams must treat agent access as part of the same governance fabric as service accounts and tokens.

Identity blast radius is the right concept for agent risk. The article's scenarios show that no single permission may look dangerous on its own, but the combination of broad access, shared visibility, and chained execution creates a much larger effective exposure. This is a better organising concept than generic shadow AI language because it ties the risk to the identity perimeter, not the model itself. Practitioners should measure how far one compromised or overprivileged agent can reach across apps and data.

Access review processes are being asked to govern identities that change faster than the review cycle. Those processes were designed for identities whose privilege state persists long enough to be observed, certified, and remediated. That assumption weakens when agents are created ad hoc, reused widely, and allowed to keep operating after ownership changes. The implication is that classic recertification alone cannot be the control boundary for agent governance.

Control effectiveness now depends on correlating identity, entitlement, and behaviour in one view. The article is right to reject siloed signals from SIEM, CASB, and endpoint tools as sufficient for this problem. Agent security requires context on who owns the agent, what applications it can touch, and what data it actually moves. Without that correlation, security teams only see symptoms after the toxic combination is already active.

From our research:

• 70% of organisations already grant AI systems more access than human employees according to Ultimate Guide to NHIs , 2025 Outlook and Predictions.
• 82% of organisations say machine identities are now one of their fastest-growing governance gaps, according to the same resource.
• For a deeper control lens, see OWASP NHI Top 10 for the agentic application risk patterns that make toxic combinations easier to miss.

What this signals

Identity blast radius is the metric teams should watch next. With agent activity expanding faster than review cycles can absorb, governance needs to shift from counting agents to measuring how far one agent can reach across applications, data sets, and delegated workflows. The relevant question is no longer whether an agent exists, but whether its access can be contained before a shared workflow turns it into a broad data path.

The programme implication is straightforward: agent governance cannot live only in security tooling. It has to sit inside IAM, IGA, and application ownership processes so that access, ownership, and data movement are correlated before the agent becomes operational risk. For practitioners, that means tightening lifecycle controls and aligning them to NIST AI Risk Management Framework concepts where AI-driven access decisions affect production systems.

For practitioners

• Inventory every AI agent as a governed identity Create a live register that links each agent to its owner, connected applications, credentials, and data scope. If you cannot answer those four questions for an agent, it should be treated as an unmanaged identity rather than a sanctioned workflow.
• Right-size agent access before broad sharing begins Review whether the agent needs read/write access, org-wide visibility, or only task-scoped permissions. Remove blanket access paths first, then revalidate against the actual actions the agent performs in production.
• Break chained workflows at trust boundaries Require validation between planning, coding, and deployment steps so one agent's output cannot automatically become another agent's authority. This is especially important where agents can modify code, publish changes, or move regulated data.
• Tie every agent to lifecycle ownership Make agent offboarding part of user offboarding, token revocation, and application review. If an employee leaves, their agent tokens and delegated permissions must be reviewed as part of the same control path, not as a separate clean-up task.
• Use application-layer telemetry to spot toxic combinations Monitor whether newly added permissions, unusual data movement, and shared visibility appear together. That combination is a stronger signal than any one event alone and is the kind of pattern existing human-centric controls often miss.

Key takeaways

• AI agents are becoming non-human identities with real data reach, and the risk comes from accumulated permissions rather than any single action.
• The scale is already material: Obsidian Security reports 300x growth in agent activity, nearly 40% medium-to-critical risk, and 16x more data movement than human users.
• Teams need ownership, entitlement review, and workflow trust boundaries in place before agent sprawl turns into invisible blast radius.

Key terms

• Toxic Access Combination: A toxic access combination is a set of permissions that becomes dangerous when granted together, even if each entitlement looks acceptable on its own. In identity governance, these combinations matter because they can enable misuse, separation-of-duties failures, or broader compromise.
• 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.
• Agent Lifecycle Drift: Agent lifecycle drift is the gap between an agent's original approved state and its later production behaviour. It happens when models, prompts, tools, or upstream services change after launch, making the agent materially different from the version that was initially reviewed.

What's in the full article

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

• Step-by-step examples of how agent permissions accumulate across CRM, drive, and code workflows.
• Product-specific guidance on surfacing ownership, application connections, and data touchpoints in a live environment.
• Real-time detection logic for toxic combinations such as shared visibility plus sensitive data movement.
• Audit and compliance implementation detail for regulated environments that need immutable agent activity logs.

👉 The full Obsidian Security post covers the five risk scenarios, detection approach, and governance detail in context.

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.