Why AI Agents and MCP Servers Are the New Shadow IT

Shadow IT used to mean a SaaS app someone expensed without telling IT. The new version is quieter and far more capable: AI agents, MCP servers, and the artifacts loaded into them, installed on developer and employee laptops, each carrying its own permission model and none of them reporting to security. They read files, run shell commands, reach the network, and hold credentials, and they were adopted from the bottom up, one developer at a time. This post makes the case for the category we work in: the local AI layer is shadow IT, traditional controls do not see it, and visibility has to come before governance.

How AI agents became shadow IT overnight

Every wave of shadow IT follows the same shape. A capability that used to require a procurement cycle becomes a one-click install, individuals adopt it because it makes them faster, and by the time security notices, it is already load-bearing. AI agents fit the pattern exactly, only the adoption curve is steeper. A developer installs Cursor, adds an MCP server they found in a public registry, grants it filesystem and shell access to get past a prompt, and moves on. None of that touched a ticket. Multiply it across an engineering org and you have a fleet of autonomous tools running on managed endpoints that no one signed off on.

What makes this wave different from the SaaS era is that the artifacts are not a single app you can put on an allowlist. A modern agent is an assembly: the agent runtime itself (Claude, ChatGPT, Cursor, Copilot, Gemini, Cline, Windsurf, and their peers), the MCP servers it connects to, the extensions in the IDE, plus skills, plugins, hooks, secrets, and CLIs layered underneath. Eight distinct artifact types, each installed independently, each with its own way of being configured, and each capable of taking real action on the machine.

Every artifact carries its own permission model

Classic shadow IT had a coarse blast radius: a SaaS tool got whatever data you fed it. The AI layer is finer-grained and, for that reason, harder to reason about. Permissions are granted locally, per artifact, often inside a config file the user edits to silence a prompt. There is no central place where those grants are visible, and no review step between 'I want this to work' and 'this can now run arbitrary commands.'

The patterns we see repeatedly are not exotic. They are the path of least resistance:

• Blanket permission grants like Bash(*) or Write(*) that hand an agent unrestricted shell or filesystem access because scoping them was more friction than the developer wanted.
• An unvetted MCP server pulled from a public registry, with filesystem, shell, and network capabilities, that no one ever reviewed before it started running.
• A plaintext secret — an API key, a database URL, a JWT, or a private key — sitting in a config file like ~/.claude/settings.json because that was the fastest way to make a connection work.
• An IDE or agent extension that is not on any allowlist, doing whatever the publisher decided it should do.

Each of these is a small, locally rational decision. In aggregate they are an ungoverned permission surface that grows every time someone installs something new.

Why traditional controls miss them

The reasonable objection is that you already have a security stack: a network gateway and firewall, EDR or XDR on the endpoint, DLP, and a GRC process. Why doesn't that cover this? Because every one of those tools was built to watch a different layer, and the local AI layer falls between them.

• Network and gateway controls see traffic, not configuration. An agent talking to an approved API over HTTPS looks identical whether its MCP server was reviewed or pulled from a registry an hour ago.
• EDR and XDR watch processes and behavior. They are not built to read an agent's permission grants, enumerate its MCP servers, or tell you that Bash(*) was just added to a config file.
• DLP inspects data in motion against patterns. It does not know a private key is sitting in plaintext in a settings file on the endpoint, at rest, where it never crosses the wire.
• GRC and manual audit operate on a cadence and on attestations. The AI layer changes daily and is never the thing being attested to.

None of these tools is failing at its job. They simply were not designed to inventory MCP configs, agent permission grants, plugins, extensions, skills, hooks, and plaintext secrets on the local machine. That is a new layer, and it needs its own lens. We see Anomity as complementing this stack, not replacing any of it.

Visibility has to come first

The instinct when a new risk surface appears is to reach straight for enforcement: block the registries, ban the extensions, lock down the configs. But you cannot write a meaningful policy against something you cannot enumerate. Before 'only approved MCP servers' means anything, you have to be able to answer how many MCP servers are running across the fleet, which are official, which are community, and which are simply unknown. Before 'no blanket permissions' is enforceable, you need to see where Bash(*) and Write(*) have already been granted.

You can't govern what you can't see.The Anomity principle

That is why we treat discovery as the foundation. A lightweight, unprivileged daemon on each managed endpoint inventories the eight artifact types, classifies MCP servers by trust signals, infers what capabilities each one actually holds, and flags the dangerous combinations — an unknown server with shell access and a plaintext credential nearby. Metadata only: not your source code, not your prompts, with secrets redacted on the device before anything leaves it. Once that picture exists, governance becomes something you can act on: define the rules, evaluate them continuously, and route violations to your SIEM, Slack, email, or Jira.

The shift in posture

Shadow IT was never solved by pretending adoption would stop. It was solved by making the invisible visible and then governing it without getting in the way of the people doing the work. The AI agent layer is at exactly that moment now. Developers and employees will keep adopting agents, MCP servers, and the artifacts around them, because they make work faster, and that is a good thing. The job in front of security teams is not to slow that down. It is to see it clearly, so that when the question comes — 'what changed last Thursday?' — the answer is a single query rather than a forensics engagement. Visibility first. Governance follows.