The tools that caught shadow IT can't see MCP sprawl
In AI agent governance, most MCP servers run as local processes that never cross the network boundary older shadow-IT tools were built to watch. The risk changed too: from data leaving through an unsanctioned app to actions taken through one.
Gravitee's 2026 State of AI Agent Security report counted more than three million AI agents now running inside corporations, a larger workforce than Walmart employs globally, and found the number had roughly doubled in four months. In that same window, the share of those agents under active monitoring barely moved. Mean monitoring coverage sits at 52 percent. Only 14.4 percent of organizations report that every agent they run went live with full security review. Eighty-eight percent report experiencing or suspecting an agent-related security or privacy incident in the past year.
Everyone's already calling this the new shadow IT
That framing is everywhere right now, and it's not wrong. Employees and developers connect Model Context Protocol servers to give agents access to files, databases, and internal tools, often without telling anyone, the same way an earlier generation spun up SaaS accounts on a personal card. But calling it shadow IT and moving on undersells the actual problem, because it implies the fix is the one that already worked once: better discovery, a scanner, a quarterly audit. That fix was built for a threat that looked different from this one, and it's worth being specific about how.
Why the old watchtower doesn't see this
Cloud access security brokers and SaaS-discovery tools earned their keep by watching a network boundary. An employee's browser talked to Dropbox or a shadow SaaS tenant, that traffic crossed a wire the security stack could see, and the tooling flagged it. The whole model depends on the unsanctioned thing being visible at the perimeter you're already watching.
A large share of MCP servers don't cross that perimeter at all. They run as local subprocesses over stdio, inside a developer's IDE, terminal, or desktop app, talking to the agent through a pipe on the same machine rather than a request that traverses your network. Security researchers disclosed in May 2026 what they called a systemic flaw across Anthropic's official MCP SDKs, a vulnerability touching an ecosystem with more than 150 million downloads and an estimated 200,000 exposed instances. The specific mechanism was how the SDKs handle that local stdio transport, and Anthropic confirmed the behavior was by design, declining to change the protocol and framing input sanitization as a developer responsibility. That's not a bug waiting on a patch. It's how a meaningful share of MCP traffic is built to work, which means it was never going to show up in a tool built to watch network egress.

The risk didn't just get bigger, it changed shape
There's a sharper way to put what's actually different here, and a security researcher at Akto framed it well earlier this year: "the earlier risk was that shadow AI exposed your data. The risk now is that it operates on it. The controls built for the first problem were not designed to see, let alone govern, the second."
That distinction is easy to state and easy to underestimate. A data-loss-prevention rule can scan an outbound message for a credit card number or a customer list. It has nothing to say about a tool call that deletes a record, moves money, or writes to a system nobody reviewed, because that action doesn't look like exposure at all. It looks like the agent doing its job. The same CSA writeup found that 79 percent of organizations still lack visibility into the AI agents and MCP-connected systems already running in their environment, and that 47 percent of enterprise AI use happens through personal accounts sitting entirely outside single sign-on and identity governance. An agent connected through one of those accounts doesn't need to reach anything exotic. Whatever the employee already has access to is fair game, and there's no audit log watching it happen.

What discovery has to look like when the wire doesn't help
If the network boundary was never the right vantage point for this, the fix isn't a better version of the same watchtower. It's moving the vantage point to where the action actually happens: the point where an agent calls a tool, not the point where a packet crosses a switch. That means an inventory of MCP servers and the tools they expose that gets built by asking the agents and gateways directly, not by sniffing traffic. It means every tool call attributable to a specific agent identity and logged with its arguments and outcome, the same discipline a policy decision point applies to any other authorization question. And it means treating that inventory as something that changes daily, not a spreadsheet refreshed once a quarter, because the Gravitee number that should worry you most isn't the size of the fleet, it's that the fleet doubled in four months while the fraction anyone was watching stayed flat.
None of this is exotic engineering. It's the same discipline that eventually caught up with SaaS sprawl, applied at the layer where this particular sprawl actually happens, which is not the layer the last generation of tools was built to watch.
Sources
- State of AI Agent Security 2026 Report: When Adoption Outpaces Control, Gravitee
- Shadow AI Agents: The Insider Threat You're Not Monitoring Yet, Krishanu Borah (Akto), via Cloud Security Alliance
- MCP Tool Poisoning: Enterprise AI Agent Security in 2026, ITECS, citing OX Security's MCP supply-chain disclosure
- MCP Servers: The New Shadow IT for AI in 2026, Qualys