In this article
August 10, 2026
August 10, 2026

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.

Explore with AI
Open in ChatGPT
Open in Claude
Open in Perplexity

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.

Diagram contrasting two paths: an employee browser talking to a SaaS app across a network boundary a CASB watches, versus a developer's IDE talking to an MCP server as a local subprocess over stdio and on to local files, databases, and APIs, all on one machine, crossing no network boundary and marked as not watched.

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.

Diagram comparing two scanning outcomes: a DLP scanner catching a customer list being exposed through an unsanctioned app and flagging it, next to the same DLP scanner facing an MCP tool call that deletes a record, finding nothing to flag because it was never built to read a tool call, and the action executing anyway.

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