COMMENTARY: Multiple customer environments, enpoints, customer environments, tools, integrations, and now AI agents getting layered on top. This is a real picture of what security teams have to deal with now. And for MSSPs, the problem is even harder. They are not managing agent sprawl inside one environment. They are often trying to secure dozens or hundreds of customer environments, each with its own tools, identities, cloud accounts, SaaS apps, and AI experiments. If agents are deployed without shared context or governance, MSSPs inherit the complexity and the risk.
The average enterprise runs
83 different security tools, and AI promised to change that. By replacing fragmented tools with agents and internal builds, AI was supposed to allow organizations to reduce their stack to something manageable, with fewer tools, fewer integrations, less data fragmentation, and fewer alert queues.
Instead, AI is adding another layer, but building on architecture that was never designed to support sprawling agent ecosystems and interconnected workflows. AI became good at executing tasks, but the infrastructure hasn’t kept up.
Agents don't get tired of switching between tools or stitching together data, but speed and access were never the only real issues. The problem is that fragmented systems produce incomplete context, andֹֹֹֹ agents that reason confidently on incomplete context don't fail loudly, they fail silently. A human analyst who can't correlate an alert across three disconnected systems will flag it. An agent may simply close it.
Every wave creates a new sprawl
Security has always evolved in familiar waves of point solutions. A new risk class would appear, a specialized product would focus on it, and then teams would adopt it. EDR, SIEM, CSPM, IAM, DSPM, and CNAPP each aimed to solve a pressing problem. But adoption also increased the stack surface that security professionals had to manage.
AI is following the same trajectory, with reports showing that enterprises are already struggling with AI agent sprawl. Some companies are
actively trying to limit the number of agents they create because of cybersecurity, management, and cost concerns, and market research estimates suggest Fortune 500 enterprises may soon run well over
150,000 agents each.
At that scale, agents that operate in silos may deliver tactical wins, but the long-term effect is more fragmentation, more surface area, and a foundation that is harder to manage than before. The common response is to give agents better access to tools, MCP connections, API integrations, and cross-system queries.
But faster access to disconnected systems doesn’t produce a coherent picture of risk. For example, an over-permissioned IAM role might be surfaced by an agent, but if your IAM, cloud, and SaaS systems have never been normalized into a shared context layer, the agent can't tell you who owns that identity, what systems it can reach, whether it's part of an active attack path, or how that access interacts with other workflows. It won't flag that this picture is missing. It will just work with what it has.
A lack of context
Fragmented AI deployment creates a connective tissue problem as organizations build capable agents but skip the layer that ties them together. When every agent sees only part of the picture, the burden of correlating risks and alerts falls back onto security teams. The result is AI that can act quickly, but often without the complete context needed to make reliable security decisions.
The problem doesn’t stop there, and it's made worse by a visibility gap at the organizational level. A
recent survey found that more than half of organizations run agents without security oversight or logging, and only a small number have full visibility into which agents communicate with each other. Security teams end up managing the gap between what agents can see and what needs to be understood.
The risk of a governance gap
As agents proliferate, so do credentials, integration points, and trust relationships. That creates a governance problem before it becomes a model problem.
One 2026 study found that 88% of organizations report confirmed or suspected AI agent security or privacy incidents within the last year. Another survey found that
83% of organizations lack basic governance over their AI tools, and only 9% have working governance systems. Most deployments still rely on employee training, warning emails, or informal controls rather than enforceable policy.
The result is a security posture that is easy to start and hard to control. Agents are often granted broad access during pilots, only to be kept in production long after the assumptions have changed. They inherit shared API keys, over-scoped service accounts, and unchecked access to data and workflows. In that model, the agent becomes a new class of identity with very little supervision attached.
Incidents show the blast radius
External exposure compounds the problem. Agent ecosystems become especially dangerous if a compromised agent has access to multiple systems because its blast radius is no longer confined to one tool. A prompt injection, over-broad token, or misconfigured integration can become a multi-system takedown event. AI agent security incidents keep pointing to the same root causes, either authorization, identity, or runtime policy, and not just general model behavior.
A recent hack of a chat agent integration quickly spiraled out of control and ended up affecting more than
700 organizations through integrations spanning Salesforce, Google Workspace, Slack, S3, and Azure.
The same logic applies to internal adoption, where every department spins up agents with its own access model and no central oversight. Without realizing the dangers, organizations can quickly end up with dozens or hundreds of unsupervised attack surfaces.
MCP standardizes access, not context
Protocols like MCP are useful because they standardize how agents connect to tools, but standardizing connections is not the same as unifying context. Just because it is easier for agents to call systems doesn't make it easier to understand what those systems mean together. Security teams need a single correlated view that preserves relationships across identities, permissions, workloads, and data.
Without unified context, the analyst is still the integration layer. The only difference is that instead of stitching together outputs from dozens of tools, they are now stitching together outputs from dozens of tools
plus a growing fleet of agents. The abstraction is cleaner, but the fragmentation remains.
The shift security teams need
Before adding another agent, two questions are worth asking: Does this expand visibility, or carve out another silo? And does this produce governance clarity, or create another set of permissions, logs, and schemas to reconcile later?
Without architectural change, industry risks repeating the same pattern it has already lived through multiple times, with new tools, new sprawl, and a new level of stress for security teams. Organizations that want AI to reduce fragmentation need systems that unify context across the security stack. A unified intelligence layer where agents share context across cloud, identity, and SaaS moves teams from reaction and reconciliation toward active decision-making on top of correlated data. That means normalizing identity, cloud, and SaaS data into a shared context layer before deploying agents on top of it, not after the sprawl has already set in.
MSSP Alert Perspectives columns are written by trusted members of the managed security services, value-added reseller and solution provider channels or MSSP Alert's staff. Do you have a unique perspective you want to share? Check out our guidelines here and send a pitch to [email protected].
