AI agent sprawl exposes governance gaps traditional IAM cannot contain

At a glance

What this is: This article argues that enterprise AI agent sprawl is creating a governance problem that traditional cybersecurity and IAM controls were not designed to contain.

Why it matters: It matters because IAM, PAM, and governance teams now have to account for non-human actors that can act across systems, data, and business processes with a wider blast radius than conventional accounts.

By the numbers:

• The AI agents market is projected to grow from USD 7.84 billion in 2025 to USD 52.62 billion by 2030, registering a CAGR of 46.3%.
• 75% of organizations experienced a SaaS security incident in the past 12 months, a 33% spike from 2024.
• 88% of organizations reported confirmed or suspected AI agent security incidents in the last year, and the healthcare sector reached 92.7%.
• 97% of AI-related security breaches involved AI systems lacking proper access controls.

👉 Read ZioSec's analysis of the SaaSpocalypse and AI agent risk

Context

Enterprise AI agents are no longer just chat interfaces. They are non-human identities that can execute tasks, call tools, and move across data and applications, which means the security problem is now about governance of action, not just protection of models or prompts.

The article frames this as a SaaSpocalypse because the underlying control model assumes software will stay inside bounded workflows. Once agents can act across business units and external systems, IAM, PAM, and access review processes have to cope with behaviour that is dynamic, cross-domain, and difficult to certify after the fact.

That makes this an NHI governance issue first and an AI issue second. The central question for practitioners is how to govern agent privileges, tool access, auditability, and accountability before sprawl turns into an operational and compliance problem.

Key questions

Q: How should security teams govern AI agents that can act across multiple business systems?

A: Treat each AI agent as a non-human identity with an owner, a purpose, and a narrow capability set. Approve tool access explicitly, log every action, and recertify privileges whenever the workflow, data source, or destination changes. Governance fails when agents are managed like temporary scripts instead of identity-bearing actors.

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

A: Traditional automation follows predetermined rules, while AI agents can select actions and interact with systems in ways that are harder to predict and certify. That makes the security problem one of governing authorised capability and accountability, not just stopping malicious code. The risk increases whenever agents can cross tool and data boundaries.

Q: What breaks when AI agent access is not tightly scoped?

A: The main failure is blast-radius expansion. If an agent can reach too many systems, one bad instruction, compromised prompt, or unsafe tool call can cascade across applications, data stores, and workflows. Tight scoping limits the number of identities, systems, and records exposed when the agent misbehaves.

Q: How can organisations tell whether AI agent governance is working?

A: Look for evidence that every agent has a named owner, a recorded business purpose, a restricted capability set, and audit logs that can be reviewed in incident response. If teams cannot explain what an agent may do, who approved it, and when its scope last changed, governance is not working.

Technical breakdown

Why agentic AI expands the enterprise attack surface

Agentic AI changes the security model because the system is no longer only producing content. It is selecting actions, invoking tools, and interacting with external systems on behalf of a business process. That creates a larger attack surface than chatbots because the agent can cross identity, data, and application boundaries in one execution path. The risk is not just prompt injection or bad output, but misuse of authorised capability. In identity terms, the question becomes which permissions an agent can exercise, how those permissions are constrained, and whether the environment can detect out-of-scope behaviour before impact.

Practical implication: Map every agent to the systems it can touch, then constrain tool access to the smallest usable set of capabilities.

OpenClaw-style capability control and agent privilege boundaries

The article treats OpenClaw as a capability-management layer that curates which tools and APIs an agent may use. Mechanically, that is different from model filtering or content moderation. It is closer to policy enforcement for action execution, where the allowed verbs are defined and monitored separately from the model's reasoning output. This matters because an agent with broad but poorly governed permissions can still cause harm even if the model itself appears safe. The security control point is the action boundary, not only the prompt boundary.

Practical implication: Separate model safety controls from action controls, and review whether each agent has an explicit allowlist for tools, data, and destinations.

AI TRiSM, IAM, and the governance layer above agent execution

The article correctly places technical controls inside a broader governance model, because agent security fails when ownership is unclear. AI TRiSM, IAM, DLP, SIEM, and review processes each cover part of the problem, but none is sufficient alone. Governance has to define who approves agent purpose, who owns the risk, how changes are reviewed, and what evidence proves the agent stayed inside its mandate. Without that layer, even granular capability controls become isolated point solutions with no programme-wide accountability.

Practical implication: Assign named owners for each agent, tie approval to business purpose, and require logging that supports later audit and recertification.

Threat narrative

Attacker objective: The objective is to turn legitimate AI agent access into cross-system misuse that exposes data, corrupts workflows, or widens operational blast radius.

1. Entry occurs when an enterprise deploys an AI agent with access to SaaS applications, data stores, and external tools as part of normal business operations.
2. Escalation happens when the agent is permitted to chain actions across systems, which lets one compromised instruction or malformed input expand into broader misuse of authorised capability.
3. Impact follows when the agent accesses sensitive data, performs unintended actions, or triggers operational disruption across connected workflows.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

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 agent sprawl is now an NHI governance problem, not a model-safety problem. The article describes agents that can act across business units, tools, and data sources, which means the security boundary is no longer the chatbot interface. Once an agent can initiate actions in production systems, the relevant governance question becomes how non-human identities are assigned, constrained, and audited. Practitioners should treat agent lifecycle and access as first-class identity controls.

Standing trust assumptions are breaking under agentic behaviour. Access review cadences, human approval checkpoints, and conventional least-privilege design all assume that the actor's intent is stable and reviewable over time. That assumption weakens when an AI agent can chain actions dynamically across tools and data sources inside a single execution path. The implication is not just more control, but a rethink of what can realistically be certified after the fact.

Capability-level governance is the right named concept for this category. The article points toward a model where the unit of control is not the model itself, but the specific actions, tools, and destinations an agent may use. That is the most useful way to separate safe language generation from unsafe execution. For practitioners, the lesson is that identity governance must move from broad role assignment to explicit capability containment.

AI TRiSM only works when it is anchored in identity ownership. Governance language without accountable owners does not stop agent sprawl. The article's business-unit framing shows how quickly AI adoption outpaces central oversight unless ownership, logging, and approval paths are defined up front. Practitioners should expect AI governance to fail when nobody can answer who owns the agent's access.

Agent security is becoming a shared discipline across IAM, PAM, and data controls. The threat described here crosses classical product boundaries because agents can read, decide, and act in one flow. That means isolated controls will miss the compound risk created by cross-system execution. Practitioners need a governance model that can connect identity, privilege, and data access into one reviewable chain.

From our research:

• 88% of organizations reported confirmed or suspected AI agent security incidents in the last year, and the healthcare sector reached 92.7%, according to AI Agents: The New Attack Surface.
• Only 44% of organizations have implemented any policies to govern AI agents, even though 92% agree that governance is critical, according to the same report.
• For a deeper control perspective, see OWASP Agentic AI Top 10 for the agentic risk categories practitioners should map to policy and access controls.

What this signals

Capability-level control will become the practical dividing line between AI adoption and AI sprawl. As agents move from experiments into operational workflows, teams will need to prove not only that the model is safe, but that the action surface is bounded. That is where identity, privilege, and audit evidence start to matter more than the choice of model or interface.

The article's logic also points to a governance shift: AI programme owners will need lifecycle processes that look much closer to NHI governance than to classic application rollout. Agent ownership, approval, recertification, and decommissioning will need to be visible in identity records, not scattered across business-unit notebooks or workflow tools.

Capability drift will become the new shadow AI signal. When an agent's tool access, data reach, or destinations expand without a corresponding review, the programme has moved beyond controlled adoption. Practitioners should expect identity teams to ask for evidence of scope changes, not just inventory counts, and to anchor that evidence in the 52 NHI Breaches Analysis and the Top 10 NHI Issues where control failures recur across non-human identities.

For practitioners

• Inventory every AI agent as a non-human identity Record each agent's owner, business purpose, tool set, data sources, and downstream systems. Treat these records as lifecycle objects that must be recertified, not as informal automation notes.
• Constrain agent capability with explicit allowlists Limit every agent to approved tools and destinations only, and review those permissions whenever the workflow changes. Use the allowlist as the enforcement point rather than relying on model behaviour.
• Tie agent approval to business-unit accountability Require named approval for each agent's scope, then make the owner accountable for reviews, logging, and exception handling. This prevents shadow AI from expanding unchecked across departments.
• Integrate agent logs into IAM and SIEM review Send action logs, access events, and tool invocations into your existing monitoring stack so agent behaviour can be correlated with identity records and reviewed during incidents.
• Re-run recertification on agent privilege changes Revalidate agent access whenever prompts, workflows, tools, or data destinations change. A static approval loses value once the agent's effective authority changes in production.

Key takeaways

• AI agents are widening the identity perimeter because they can exercise authorised capability across systems, data, and workflows.
• The scale of the problem is already visible in the data, with high incident rates and weak policy adoption across current deployments.
• Practitioners should govern agents as non-human identities, with explicit ownership, capability boundaries, and recertification when scope changes.

Key terms

• Agentic AI: AI systems that can choose actions, call tools, and carry out tasks with some degree of independence. In identity terms, the key issue is not just what the model says, but what authority it can exercise, what systems it can reach, and how its actions are constrained and reviewed.
• Capability-level governance: A control approach that limits what an AI agent can do by defining approved tools, destinations, and actions. It shifts the security focus from prompt safety alone to the specific execution paths an agent may use, which is where most operational damage occurs.
• Shadow AI: AI agents or AI-enabled workflows that operate outside formal governance, ownership, or inventory. The problem is not simply unknown technology, but unknown authority, because unmanaged agents can accumulate access, move data, and trigger business actions without review.
• Non-human identity: A digital identity used by software, workloads, services, or AI agents rather than a person. These identities still need ownership, lifecycle control, and access governance, because they can authenticate, access data, and interact with systems at machine speed.

Deepen your knowledge

AI agent governance and capability control are covered in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are defining ownership, scope, and lifecycle rules for agents, it is worth exploring.

This post draws on content published by ZioSec: The SaaSpocalypse: Navigating Enterprise AI Agent Risks with OpenClaw and Beyond. Read the original.