Skip to content

Agent sprawl vs SaaS sprawl: What’s the same, what’s different

BetterCloud

July 31, 2026

8 minute read

Several identical humanoid robots are seated in rows at desks, each using a computer against a blue background, visually representing automation and artificial intelligence in an office environment while illustrating the contrast between agent sprawl and SaaS sprawl in modern digital workplaces.

If you led IT through the last decade, you know this story already. A new category of technology shows up promising efficiency and control. Teams adopt it fast, often faster than IT can track. A few years in, someone finally asks “wait, how many of these do we actually have running?” and the answer is uncomfortably large.

We told that story in detail in BetterCloud’s 2026 State of SaaS report. We surveyed 525 IT and security professionals against a backdrop of buzz outside the industry that SaaS itself was dead, that AI was replacing it, that the sprawling app stacks of the early 2020s were already yesterday’s problem.

That is not what the data said. The plot twist was that sprawl is growing again, not shrinking, and it’s growing for reasons that have little to do with IT losing discipline and everything to do with how modern organizations actually adopt technology.

Now we’re watching the same plot twist start to play out with AI agents, except faster and with higher stakes. If you’re an IT director or IT manager trying to figure out whether “agent sprawl” is a real problem or just a buzzword vendors are using to sell you something new, this is worth ten minutes of your time.

What we mean by “the plot twist”

Quick recap for anyone who didn’t read the full report. The buzz outside IT circles going into 2026 was that SaaS as a category was dying, being swallowed up by AI, and that the sprawling app stacks of the early 2020s were fading into history. IT teams were expected to report smaller, tighter, more governed stacks than they had in 2023 or 2024.

Instead, our survey respondents told us the opposite. App counts crept back up. Shadow IT remains as departments keep signing up for tools outside of procurement, often because a single point solution solved an immediate problem faster than waiting on an IT-approved alternative. Consolidation efforts worked in pockets but didn’t hold at the organizational level, because the underlying incentive that drives sprawl (individual teams optimizing for their own speed) never went away.

That’s the pattern worth remembering as we talk about agents. Sprawl isn’t a technology problem. It’s a behavior problem that shows up wherever a new technology makes it easy for a non-IT employee to solve their own problem without asking permission first.

Why agent sprawl is SaaS sprawl’s faster, weirder cousin

Here’s where things get more interesting than a simple “history repeats itself” comparison. Agent sprawl shares SaaS sprawl‘s root cause, but it diverges from it in a few important ways that IT leaders need to plan for differently.

What’s the same

The adoption curve starts the same way. A marketing manager creates an AI agent that drafts campaign briefs. A sales rep sets up an agent to auto-qualify leads. A finance analyst wires an agent into a spreadsheet workflow. None of this goes through IT. None of it shows up on an asset inventory. It’s the exact same shadow IT pattern that built SaaS sprawl in the first place: individual employees solving individual problems with individual tools, at a pace that outruns governance.

The incentive structure is identical. Employees don’t adopt shadow tools because they don’t care about security or IT policy. They adopt them because the sanctioned path is slower than the unsanctioned one. That was true when the unsanctioned path was a free-tier project management app. It’s still true now that the unsanctioned path is a browser extension that automates a workflow using an LLM.

Visibility is still the first casualty. In the State of SaaS report, one of the most consistent findings was that IT teams routinely underestimate their real app count, sometimes by a significant margin, because discovery tools only catch what’s been explicitly connected or expensed. Agents introduce the same blind spot, except agents are harder to fingerprint than a SaaS login. An agent might not even be a distinct “application” in the traditional sense. It might be a workflow built inside a tool you already sanctioned, using a permission set nobody reviewed for that use case.

What’s different

Agents act, apps don’t. This is the difference that should keep IT Directors up at night more than SaaS sprawl ever did. An unsanctioned SaaS app is a data exposure risk. It sits there holding information it shouldn’t have. An unsanctioned agent is an actor that can read data, make decisions, send emails, update records, and trigger downstream actions, all without a human clicking “confirm” at each step. Sprawl used to mean “too many places your data lives.” Now it can mean “too many things with standing permission to do something with your data.”

Agents inherit and combine permissions. A single SaaS app usually operates inside its own walled garden. An agent frequently spans several. It might read from your CRM, write to your support ticketing system, and post to a shared Slack channel, all in one workflow. That means an ungoverned agent doesn’t just carry the access risk of one app, it carries the combined access risk of every system it touches, and those permissions often get granted through the identity of whichever employee set the agent up in the first place.

The pace is faster. SaaS sprawl built up over years, driven by procurement cycles and IT budget planning, however imperfect. Agent adoption is happening in weeks, because the barrier to spinning one up is closer to “type a prompt” than “fill out a purchase order.” IT teams that are still catching up on SaaS visibility are now being asked to build agent visibility on an even more compressed timeline.

The vendors are less mature. The SaaS ecosystem, for all its sprawl, is at least a known quantity. There are established categories, known security postures, and a couple decades of enterprise procurement muscle memory to draw on. The agent ecosystem is still being built in real time. Governance frameworks, audit standards, and even shared vocabulary for what an “agent” is versus a “workflow” versus a “bot” are still forming. That immaturity means IT can’t just port over its SaaS governance playbook and expect it to fully cover agent risk.

So is this actually a crisis, or just the next hype cycle?

Fair question, and it’s worth answering honestly rather than reflexively. Not every organization is dealing with runaway agent sprawl today. Plenty of IT teams are still in the early stages, running pilots, testing a handful of agents in controlled environments, and haven’t yet seen the department-level free-for-all that defined SaaS adoption in its wild years.

But the latest State of SaaS data gives us a useful early warning signal here. The same survey that revealed sprawl was creeping back up also showed that IT teams consistently underestimate how fast unmanaged adoption compounds. What starts as “a few teams experimenting” tends to become “an unmanaged sprawl problem” faster than most IT leaders expect, because the barrier to entry keeps dropping and the perceived upside keeps rising. Agents lower that barrier even further than SaaS did. If SaaS sprawl crept up despite years of consolidation pressure and better discovery tooling, there’s no strong reason to expect agent adoption to behave more cautiously, especially when the tools themselves are being marketed directly to individual employees and embedded into products your teams already use every day.

The honest answer is that agent sprawl isn’t a hypothetical future problem. It’s SaaS sprawl’s pattern, replaying with a technology that has more autonomy and less oversight built in by default.

What IT directors and managers should actually do about it

None of this is an argument for locking down agent adoption entirely. IT teams that tried to ban shadow SaaS outright mostly learned that prohibition doesn’t work, it just pushes adoption further out of view. The goal isn’t to stop agent adoption. It’s to get ahead of it before visibility becomes the problem it became with SaaS.

Start with discovery, not policy. You can’t govern what you can’t see. Before writing an agent usage policy, invest in understanding what’s already running. That means looking beyond a simple app inventory and asking which existing SaaS platforms have agent or automation features already turned on, and by whom.

Map permissions, not just tools. The right question isn’t “how many agents do we have.” It’s “what can each of these agents actually do, and on whose authority.” An inventory that lists agent names without mapping their access and action scope isn’t giving you the risk picture you need.

Bring business teams into the conversation early. The teams building agents right now, marketing, sales, support, are the same teams that historically drove shadow SaaS adoption. They’re not doing it to cause problems, they’re doing it because it works for them. IT teams that treat this as a partnership conversation rather than an enforcement action tend to get better visibility and better long-term compliance than teams that lead with restriction.

Extend your SaaS governance muscle, don’t rebuild from scratch. If your organization already has a working SaaS management and discovery practice, you have a real head start. The skills involved in finding shadow SaaS, understanding who owns what, and building lightweight approval paths that don’t slow teams down too much all transfer directly to agent governance. The tooling needs to extend to cover agent-specific risks like action permissions and cross-system access, but the operating model doesn’t need to be reinvented.

Treat this as an ongoing practice, not a one-time audit. The mistake plenty of organizations made with SaaS sprawl was treating consolidation as a project with an end date. It never really ends because adoption never stops. Agent governance needs to be built the same way: a continuous practice, not a checkbox exercise you complete once and move on from.

The throughline

The connective tissue between these two campaigns isn’t a coincidence. SaaS sprawl and agent sprawl are two chapters in the same story about how modern organizations adopt technology: fast, decentralized, and usually well ahead of whatever governance structure IT has in place. The plot twist in our SaaS data wasn’t that sprawl exists, everyone already knew that. It was that sprawl kept growing even after years of active effort to shrink it, because the forces driving it were structural, not accidental.

Agents are the next test of that same structural pattern, running at a faster pace with higher stakes attached to every unmanaged instance. IT directors and managers who internalize that connection now, rather than treating agent governance as a brand new problem with no precedent, will be in a far better position to get ahead of it than the ones who wait for their own plot twist moment to show up in next year’s data.

If SaaS sprawl taught IT teams anything, it’s that visibility has to come before control, and control has to come before it’s too late to matter. The organizations that build that muscle now, while agent adoption is still in its early innings, are the ones that won’t be surprised by what they find when someone finally asks “wait, how many of these do we actually have running?”

Frequently asked questions

What is agent sprawl?

Agent sprawl is the uncontrolled proliferation of AI agents across an organization, often set up by individual employees or teams outside of IT’s knowledge or approval. It follows the same pattern as SaaS sprawl, where a technology that’s easy to adopt without going through procurement ends up scattered across departments with little central visibility or governance.

Is agent sprawl the same thing as SaaS sprawl?

Not exactly. Agent sprawl and SaaS sprawl share the same root cause: employees solving problems faster with unsanctioned tools than they could through IT-approved channels. But agents introduce risks that SaaS apps generally don’t, because agents can take autonomous action across multiple systems using inherited permissions, rather than simply storing or displaying data within their own environment.

Why is agent sprawl considered higher risk than SaaS sprawl?

Because agents act rather than just store. A SaaS app that’s adopted without IT’s knowledge is a data exposure risk. An agent adopted without IT’s knowledge can read, write, and trigger actions across every system it’s connected to, often using the permissions of whoever set it up. That combination of autonomy and inherited access is what separates agent risk from traditional shadow IT risk.

How can IT teams get visibility into agent usage?

Start by looking at agent and automation features already built into SaaS platforms your organization has sanctioned, since a lot of early agent adoption happens inside tools IT already approved for a different purpose. From there, build a discovery process that maps not just which agents exist, but what systems and data each one can access and what actions it’s authorized to take.

Did BetterCloud’s State of SaaS report find that SaaS sprawl is getting worse?

Yes. Our 2026 State of SaaS report surveyed 525 IT and security professionals and found that SaaS sprawl is increasing again after a period where many expected consolidation efforts to have brought it under control. The report’s core finding is that sprawl is driven by structural incentives, not a lack of IT discipline, which is the same dynamic now playing out with agent adoption.

Should IT block agent adoption until governance catches up?

Most IT leaders who tried an outright ban on shadow SaaS found it pushed adoption further out of sight rather than stopping it. The more effective approach is building lightweight visibility and approval processes that don’t slow teams down significantly, paired with ongoing partnership with the business teams driving agent adoption in the first place.

Categories