Enterprises have been experimenting with agentic AI for years. What’s changed in the 18-24 months, however, is that rather than experimenting with the technology in individual pilots or one-off use-cases, it’s become embedded right across entire workflows. We’re now seeing agents pull data from internal systems, trigger actions across platforms, and stitch together workflows that used to rely on multiple people and tools. In a lot of ways, it feels natural. If something can be automated, teams will automate it. If something can be connected, it gets connected. The barrier to doing that has become incredibly low, which is why adoption is moving so quickly. But when everything starts connecting this easily, it also means that access is being granted easily, often without the same level of thought or structure that businesses would apply to human employees.
Every AI agent inside an enterprise ultimately shows up on the network as a non-human identity (NHI), whether that’s a service account, API key, token, or automation credential acting on its behalf. These identities aren’t new, but the speed and scale at which AI is creating them is.
According to recent data, the number of NHIs on the average enterprise network now commonly exceeds human identities by a factor of 100:1, and in some cases reaches highs of 500:1. What’s more, only 12% of organizations have automated lifecycle management for these machine identities, with the rest leaning on ad hoc of manual processes – if they’re managed at all. AI agents are the fastest-growing contributor to this sprawl. They are routinely making requests, moving data, and interacting across services, sometimes in ways that aren’t fully mapped out at the point of integration. They’re also designed to be flexible, so they tend to evolve as workflows evolve, and that’s where the cracks begin to show, particularly when identity isn’t treated as a central control point from the outset. When access is granted simply to enable functionality and “get things working”, rather than being defined around what should happen at a specific moment, access becomes a sprawling mess that’s difficult to clean up.
From SaaS sprawl to AI sprawl
A lot of this may feel like déjà vu. After all, it isn’t the first time enterprises have found themselves in this position. A decade or so ago, SaaS sprawl became one of the defining challenges of enterprise IT. Teams adopted tools quickly to solve immediate problems, often without a centralized view of how those tools fit together or how access should be managed across them. At its peak, organizations were running hundreds of applications in parallel, each with their own set of accounts, permissions, and policies. Even now, many enterprises are still working through that complexity, relying on single sign-on and centralized identity platforms to bring some level of order back into the system.
The pattern with AI is similar, but it’s moving faster and in a way that’s harder to see. Instead of dozens or hundreds of applications, we have agents, integrations, and automation layers being introduced into workflows, often incrementally and without much, if any, friction. Each one connects to data, interacts with systems, and requires some level of access to function properly. On the surface, it doesn’t look chaotic – in fact, it may look a lot like progress, as productivity ramps up and more processes become automated. But underneath, the familiar sprawl problem is brewing. Access is distributed, visibility becomes fragmented, and control starts to weaken. The difference is that this kind of access sprawl doesn’t sit neatly in an application inventory. It lives across interactions, APIs, and processes, which makes it far more difficult to track and manage once it starts to grow.
Leaving the doors open
A lot of the risk starts at the point of integration. Getting an AI agent up and running has become relatively straightforward, whether it’s through APIs, connectors, or custom middleware that links models into internal systems. The focus is usually on making sure the agent can do its job without friction, which often means giving it broad access to the data and services it might need. NHIs aren’t “onboarded” or “offboarded” in the same way humans are, and there is often no chain of custody – nobody “owns” an AI agent or assesses its permissions and whether they’re still needed, and even if there was an owner, there are often too many NHIs for manual governance to keep up. Even the person setting up the integration may not know which model will ultimately connect to that endpoint, how that model might change over time, or how many downstream systems it will interact with as workflows expand.
Rethinking access from permissions-based to request-based
What this really points to is a need to rethink how access is granted in the first place. In many environments, permissions are still assigned statically. An identity is created, access is defined upfront, and that access tends to persist until someone revisits it. That approach was already difficult to maintain at scale, especially during the early days of SaaS sprawl, but with AI agents it becomes even more fragile. These systems don’t operate in a fixed pattern. They handle different tasks, interact with different services, and change over time as workflows evolve. Giving them broad, long-lived access just to keep things running introduces more risk than it removes, because it’s no longer tied to what the system is actually doing at any given moment.
Instead, businesses should make access dynamic and tied to the request itself. Rather than assigning everything upfront, access is granted based on what that identity needs in that specific interaction. That might be a particular dataset, a single API call, or a defined action within a system, with permissions that expire once the task is complete. This is where ideas like just-in-time access and continuous validation start to make sense. It also aligns closely with how zero trust needs to evolve, because businesses aren’t just looking at where a request is coming from, but whether the identity behind that request should be allowed to perform that action in that specific moment. Simply put, the same level of rigor that applies to human identities needs to apply here as well, because every identity on a network – human or otherwise – needs to be managed, controlled and understood.
AI will only scale securely if identity becomes the control plane
AI sprawl rarely looks like a problem in its early stages. It masks itself as efficiency and productivity – things that businesses are constantly chasing. Workflows move faster, teams rely less on manual intervention, and there’s a sense that systems are finally starting to connect in a meaningful way. But without a clear identity framework underpinning that progress, the same patterns that defined SaaS sprawl begin to resurface. Access becomes fragmented, visibility starts to fade, and privileges accumulate in ways that are difficult to unwind once they’re in place. It doesn’t happen all at once, and that’s what makes it easy to miss.
If AI is going to operate inside core business processes, then identity has to sit at the center of how those systems are designed and governed. That means treating machine identities – including AI agents – with the same level of rigor as human ones, defining access around specific actions rather than broad roles, and ensuring those permissions are continuously validated as systems evolve. It also means making sure the underlying identity platform is reliable and scalable enough to support that model, because once identity becomes the control plane, everything depends on it. The organizations that get ahead of this won’t slow AI adoption down. They’ll enable it to scale in a way that remains controlled, visible, and aligned with how the business actually operates.
