AI Agent Sprawl: The New Shadow IT Problem CISOs Can’t Ignore

Remember shadow IT? That familiar headache where employees signed up for cloud apps without telling anyone, and IT departments spent years playing catch-up trying to figure out what was actually running in their environments? Well, it’s back—except this time, the unsanctioned software doesn’t just store data or send emails. It takes actions on its own.

AI agents—autonomous or semi-autonomous software that can reason, plan, and execute tasks across systems—are showing up everywhere in enterprise environments. A developer spins one up to triage tickets. A finance analyst builds one to reconcile invoices. A marketing team connects one to their CRM to draft outreach. Each of these agents holds credentials, touches sensitive data, and often has the ability to do things—not just read them. And most of the time, nobody in security knows they exist.

This is AI agent sprawl, and it’s rapidly becoming one of the more uncomfortable governance problems facing CISOs today.

Why This Isn’t Just Shadow IT 2.0

It’s tempting to treat AI agents as the latest flavor of the shadow IT problem we’ve been managing for a decade. But that framing undersells the risk. The old shadow IT problem was fundamentally about visibility—unknown apps holding data in unknown places. Agent sprawl adds a dimension that changes the math entirely: agency.

• Agents act, they don’t just store. A rogue SaaS subscription might leak data. A rogue AI agent might move money, delete records, provision infrastructure, or send communications on behalf of your company—autonomously, at machine speed, and often without a human in the loop reviewing each step.
• Agents accumulate credentials and permissions. To be useful, an agent needs access. In practice, that access is frequently over-provisioned—broad API keys, service accounts with standing privileges, and OAuth tokens that never expire. Each agent becomes a small, persistent bundle of entitlements that nobody is actively governing.
• Agents chain together and call other agents. The genuinely new wrinkle is that agents increasingly invoke other agents and tools. One agent’s output becomes another’s input. This creates action chains that are extraordinarily hard to audit after the fact, because no single log tells the whole story.

The scale of this shift is already visible in adoption data. Gartner has predicted that by 2028, 33% of enterprise software applications will include agentic AI,  up from less than 1% in 2024—and that these agents will autonomously make at least 15% of day-to-day work decisions. When a third of your software portfolio can take independent action, the governance question stops being theoretical.

The Ways Agents Slip Through the Cracks

Agent sprawl doesn’t happen because people are careless. It happens because building an agent has become almost trivially easy, while the guardrails around them haven’t kept pace. A few common patterns:

• Low-code and no-code agent builders. Platforms now let non-developers assemble functional agents in an afternoon. That’s great for productivity and terrible for control, because these agents rarely go through any security review or asset registration process.
• Embedded agents inside sanctioned tools. Many products your organization already pays for now ship agentic features that are switched on by default. You didn’t procure an AI agent—you procured a productivity suite—but suddenly one is running inside it, with access to everything the suite can see.
• Developer experimentation that goes to production. An engineer prototypes an agent to solve a real problem, it works, and it quietly becomes load-bearing infrastructure. There was never a moment where someone decided to deploy it formally, so it never entered any inventory.
• Personal accounts and API keys. When employees connect agents using their own credentials or personal LLM API keys, the activity is completely invisible to enterprise monitoring. The organization is exposed to actions it can neither see nor attribute.

The through-line here is that agents get created at the edges, by the people closest to the work, and by the time security hears about them—if it ever does—they’re already embedded.

What Actually Goes Wrong

The failure modes aren’t hypothetical. Consider a few realistic scenarios that enterprises of all kinds should be thinking hard about:

• Data exfiltration through legitimate channels. An agent with read access to a customer database and write access to an external system can move sensitive data out of the organization while every individual action looks perfectly authorized. There’s no malware, no obvious breach—just an agent doing exactly what it was permitted to do, in a way nobody anticipated.
• Prompt injection turning helpful agents hostile. Agents that process external content—emails, documents, web pages—can be manipulated by instructions hidden in that content. A carefully crafted input can hijack the agent into taking actions its owner never intended. This is a genuinely new attack surface, and it’s one that traditional endpoint and network controls simply don’t see.
• Cascading errors at machine speed. When agents call other agents, a single bad decision can propagate through a chain of automated actions faster than any human can intervene. By the time someone notices, the damage may already be done and distributed across multiple systems.
• Orphaned agents with standing access. The employee who built the agent leaves. The agent keeps running, keeps holding its credentials, and keeps acting—now with no owner, no oversight, and no clear path to decommissioning.

Getting Ahead of the Sprawl

The good news is that this is a solvable problem, and the disciplines that solve it are ones security teams already understand—applied to a new class of asset. The key is to start now, while the number of agents in your environment is still countable.

• Inventory before anything else. You can’t govern what you can’t see. Build a living inventory of every agent in your environment, including embedded features in sanctioned tools and anything running on personal credentials. Network monitoring and API traffic analysis will surface agents that nobody bothered to register.
• Treat agents as identities. Every agent should have a distinct, non-human identity with scoped, least-privilege access and credentials that expire. Standing broad permissions and shared service accounts are exactly what you want to eliminate. This is identity and access management applied to software actors instead of people.
• Put humans in the loop for consequential actions. Not every action needs approval, but actions that move money, touch regulated data, or change infrastructure should require explicit human authorization. Deciding where those lines sit is a governance exercise, not a technical one.
• Test agents like adversaries would. Prompt injection and agent-chain manipulation are real attack vectors, and they don’t show up in a conventional penetration test. Agents that process untrusted input need to be probed specifically for these weaknesses before they’re trusted with anything sensitive.
• Establish an ownership and decommissioning process. Every agent needs a named owner and a defined lifecycle. When the owner leaves or the agent’s purpose ends, there should be a clear, enforced path to shutting it down and revoking its access.

None of this requires reinventing your security program. It requires extending the governance, identity, and testing disciplines you already have to a category of asset that most organizations aren’t yet tracking at all.

That last point is where a lot of enterprises get stuck—they recognize the risk but lack the in-house depth to assess AI-specific attack surfaces like prompt injection, or to fold autonomous agents into their identity and access modernization efforts. This is precisely the kind of problem Plurilock’s AI security testing and IAM modernization work is built to solve, and getting expert eyes on an emerging risk early tends to pay off enormously.

The organizations that will weather this well aren’t the ones hoping agents stay manageable on their own. They’re the ones that started counting, scoping, and testing before the sprawl got ahead of them—while it was still a governance project rather than an incident response. ■