Agent Sprawl is the new Shadow IT. Here’s how to tackle it proactively.

Enterprise AI has evolved over the last year. . Boards have gone from cautiously wanting to see a demo to asking how AI will run at scale, in production—governance, security, trust built in.

And running real AI, accurately, reliably, and safely, is the real challenge. While people try to figure that out, the agents are getting added anyway.

Here’s what Shadow IT means in 2026. 

Ten years ago, shadow IT meant an unapproved SaaS tool expensed on a corporate card. It was a real problem, and the industry solved it with discovery tools, access brokers, and policy.

It is happening again now, with one major difference. This time the software can act..

Your HR platform now ships AI agents. So do your ITSM tool, your CRM, and your productivity suite. Employees are adding browser agents and personal copilots on top. The agent sprawl is getting a name amongst security researchers: shadow AI.The term for people and vendors adopting AI without IT visibility or governance.

Shadow IT was mostly a visibility problem. A team signs up for a file-sharing tool or a project tracker on a corporate card, and IT does not know it is in use. The data sitting inside it is a real risk, but the tool itself only stores and displays. Find the app, and you have most of the problem.

But Shadow AI is visibility, data, access, and action, all in one. You do not know the agent exists. You do not know what it reads. You do not know whose credentials it is holding. And while you are still working out question one, it has the power to approve a request, update a record, send an email, or move money.

The Census Problem

Here is a simple test. Ask your organization one question: what is AI doing across our systems right now?

Most enterprises cannot answer it. Agents are arriving through five different doors:

• Native agents inside your systems of record—HR, ITSM, CRM, finance
• Copilots inside your productivity and communication tools
• Browser agents and personal AI assistants adopted by individual employees
• Agents built by internal teams on open-source frameworks
• Agents operated by your outsourcing and service partners

Each arrived with its own permission model, its own logs, its own approval conventions, and its own dashboard. None of them knows the others exist. Five vendors means five answers to "who approved this action?" -- and zero unified answers when a regulator, an auditor, or an attacker forces the question.

Governance teams are being asked to govern what they cannot even see. That is the census problem, and it gets worse every quarter, because every software vendor on earth is currently adding AI agents to their product. The problems of SaaS are entering the era of agentic AI—unless you proactively act against it.

SaaS tools are still the major entry point for AI agents, so they arrive as a feature flag on software that has already cleared procurement and security reviews. The approval gate never fires a second time. This is an implementation problem, andit is fixable with discovery and policy.

But say the right policies and implementations were in place, and we had a perfect inventory tomorrow with every agent known, approved, and owned—there would still be issues. The confused deputy and transitive trust failures do not sit inside any one agent. They sit in the handoffs between them, so there is no one vendor who can patch them, because no vendor owns the seam between their product and four others.

Over the past year, Anthropic, Google, and OpenAI—the companies behind Claude, Gemini, and ChatGPT, which we will call the foundational model makers—published their security doctrine for AI agents. Their catalogue of attacks reads like a description of what happens when AI agents multiply without a common control layer.

In plain English:

• The confused deputy. An attacker tricks a low-privilege agent into asking a high-privilege agent to do something it should never do. The powerful agent sees a legitimate-looking request from a colleague and executes. The more agents you run from more vendors, the more deputies there are to confuse.
• Transitive trust. Agent A trusts agent B simply because agent B asked. In multi-agent systems, trust is implicit and inherited by default -- and the model makers are unanimous that it must not be. Authorization has to be re-checked at every handoff, not passed along like a hall pass.
• Privilege inheritance. A manager agent delegates work to helper agents without narrowing their permissions. The helpers inherit the manager's full reach. One over-privileged agent quietly becomes ten.
• Tool poisoning and the rug pull. Agents discover tools by reading their descriptions. Corrupt the description, and the agent misuses a legitimate tool. Worse: a tool an agent already trusts can be silently swapped for a malicious version. This is not theoretical. In September 2025, security researchers found a widely used open-source connector impersonating a well-known email service. It behaved correctly for fifteen releases. The sixteenth added one line of code that blind-copied every email it sent to an attacker-controlled address. Around 1,500 downloads a week, roughly 300 organizations, and nothing in the agent's behaviour looked wrong. The author pulled the package once contacted, but every copy already installed kept running.
• Indirect prompt injection. Malicious instructions hidden inside content an agent reads -- an email, a resume, an invoice. The model makers agree it is the number one agentic threat, and agree it cannot be fully filtered away. (Part 3 of this series covers why, and what to do instead.)

Notice what these attacks have in common: none of them breaks a model. They exploit the gaps between agents—the handoffs, the trust assumptions, the tools. Sprawl does not just multiply agents. It multiplies gaps.

There is a second blind spot in most sprawl conversations: an enterprise does not have one kind of agent activity, it has two.

• Agents acting on behalf of a person. An employee asks a question in chat; the agent acts in that person's context, with that person's permissions, in real time.
• Agents acting autonomously. An invoice processor or a ticket triager running in the background under its own identity, typically on schedules or triggers.

Both modes are legitimate. Both need governing. But they need different guardrails: the first must be strictly bounded by what the human is allowed to do; the second needs its own managed identity, scoped narrowly to its task, with human checkpoints on consequential actions. Vendor-by-vendor governance rarely distinguishes the two -- which means autonomous agents often run with permissions designed for humans, and nobody notices until an audit does.

Take the most ordinary process in the enterprise: a new hire starts Monday.

Onboarding touches the HR system (create the employee record), the ITSM tool (provision the laptop and accounts), the identity platform (assign roles and access), and payroll (set up compensation). Four systems. In the sprawl world, that is four different vendor agents, each doing its fragment.

Now walk the seams. Who verifies that the ITSM agent acting "because HR asked" is responding to a real HR event, and not a spoofed one -- the confused deputy, live in production? What happens when the identity agent inherits a request originated by the HR agent -- does anyone re-check permissions at that hop, or is trust transitive? If the new hire's start date changes and three of four systems update, which agent owns the outcome? And when an auditor asks, nine months later, why this person ended up with finance-system access, the answer is scattered across four logs in four formats.

The same story plays out in finance (month-end close crosses the ERP, banking platforms, and procurement) and IT (an access request starts in chat, gets approved against an HR role, and lands in the identity platform). Real work refuses to stay inside one system -- which means siloed, per-vendor governance fails on exactly the work that matters most.

You cannot fix this by scheduling the vendors into a room. Vendors optimize for their own surface. Nobody is incentivised to govern the seams between their product and four others.

What is striking is how much agreement there already is on the alternative. The model makers came at this from three different directions -- one from zero-trust networking, one from adversarial testing of its own agents, one from a published security framework -- and landed on the same four things. In plain English:

• Identity. Every agent is a named principal, not an anonymous process running on somebody's API key. You can say which agent did a thing, who it was acting for, and what it was allowed to be.
• Scoped authority. An agent gets the narrowest set of powers that lets it finish its job, and nothing more. Not "access to the CRM." Access to these records, for these operations, within these limits.
• Observability. Every action an agent takes is recorded in a form a human can review afterwards. If you cannot reconstruct what happened, you are not governing, you are hoping.
• Human oversight. A person approves the consequential actions, and the definition of consequential is set deliberately rather than left to the agent.

Say those four out loud and they sound like security basics, because they are. That is the point. The agentic era did not invent new controls; it removed the assumption that a human was sitting behind every action. What is new is where the controls have to live. You cannot implement identity, scoped authority, observability, and human oversight separately inside each of five vendor products and call the estate governed. Four principles applied five different ways is not governance. It is five governance projects. (Part 3 works through where these four come from and what each one actually demands.)

So it has to be a layer -- a control plane that sits above every agent in the estate, whoever built it. Concretely, that layer must do five things:

• One identity model. Every agent -- native, third-party, or homegrown -- operates under an identity your existing identity provider governs. An agent can never do what its identity could not do directly in the underlying system. No parallel permission universe.

• Re-authorization at every hop. When one agent triggers another, the request authorization is checked again, from scratch, every time. Nothing is waved through because a trusted agent asked for it. This is the structural fix for the confused deputy.

• Least agency, not just least privilege. Least privilege limits which systems an agent can touch. Least agency limits what it can do there -- which actions, how often, toward which destinations. A payments agent that can read only its own payment queue, and approve nothing above a set threshold, is least agency at work.

• One audit trail. Every action, every handoff, every approval, from every agent, in one immutable record. "Why did this happen?" becomes a query, not a forensic project across five log formats. The trail itself needs governing too. Who can read it, who can export it, and a guarantee that nobody, including an administrator, can quietly edit or delete a line of it. An audit trail anyone can rewrite is not evidence.

• A kill switch. When something goes wrong -- and assume-breach thinking says something eventually will -- you cut it off in seconds. One tool, one integration, one agent, or every agent at once. The business systems underneath stay up. The agents acting on them stop.

One more property matters, and it is the one most often missed: the control plane must be agent-agnostic. It has to govern the agents you build and the agents your vendors ship -- triggering them, being triggered by them, and holding them all to the same permission model, the same human-in-the-loop policy, and the same audit trail. A control plane that only governs the agents it created is not a control plane. It is another silo.

This is the problem we built Ema to solve. Ema operates as a universal agentic control plane, and permissions inside it are set at four nested levels:

• the organization,
• the team,
• the individual AI Employee,
• and the specific action that the AI Employee is allowed to take.

Each level constrains the one below it, so what is denied at the organization level cannot be granted to a team, and what is denied to a team cannot be granted to one of its agents. The most granular level is the one that matters most in practice: an AI Employee is not given a system, it is given a list of permitted actions in that system.

On top of that sit the other three. Human-context and autonomous agents are handled as separate identity types, so an agent running on a schedule never quietly borrows a human's permissions. Human-in-the-loop checkpoints are sized to risk rather than applied uniformly. And an immutable audit trail records every action, every handoff, and every approval, including when approvals are switched off. Because the layer is agent-agnostic, it also triggers and governs third-party agents in the systems you already run -- one permission model, one approval policy, one audit trail, instead of five vendor dashboards.

It runs at scale: one global IT services firm operates this model across 250,000 employees; a Fortune Global 500 manufacturer went from concept to governed production across more than 20 systems of record in four weeks.

Agent sprawl is coming to every enterprise -- in most, it has already arrived. The choice is not whether you will run many agents. You already do. The choice is whether anything governs them as one.

Next in this series: the playbook -- what to demand from any agent platform before you buy.