Agentic AI Security
What Is Shadow MCP?
- Unapproved servers
- Local tools
- Hidden access
Short answer
Shadow MCP is the use of Model Context Protocol servers that your organization hasn't reviewed, approved or registered. A developer adds a server to an agent's configuration, and from then on the agent can call its tools and feed its results to an AI model. Nobody in security knows the server exists, what it can reach or what it returns.
Maskflare Engineering Updated
How does shadow MCP happen?
It happens because adding a server takes one line of configuration. An engineer wants the agent to query a database, read tickets or browse a wiki. She finds an open-source server, copies a snippet into the agent's settings file, pastes in a personal access token and is done in five minutes. Nothing was bought, nothing went through procurement and nothing shows in a network inventory.
Typical examples:
- A local server started as a child process of the IDE, reading the project folder.
- A hosted server from an unfamiliar publisher, connected with a company account.
- A server a colleague shared in a team chat, with a token that has far more rights than the task needs.
- A server that was approved once and later updated, so what it does today is not what was reviewed.
It is closely related to shadow AI, but the unit of exposure is different. Shadow AI is usually a person pasting text into a tool. Shadow MCP is an agent being given standing access to systems.
Why is it risky?
| Risk | What it looks like |
|---|---|
| Unvetted code | The server runs with the user's rights. If it is malicious or compromised, it can read what the user can read |
| Over-broad credentials | A personal token with write access sits in a plain-text config file |
| Data in results | Whole records return to the model and then to the AI provider |
| Poisoned descriptions | A server describes its tools in ways meant to steer the model. See tool poisoning |
| Silent change | The server's tools or behaviour change after anyone looked |
| No record | No log says which tool ran, so incidents can't be scoped |
The MCP specification puts much of the responsibility on clients: it says there should be a human in the loop who can deny tool invocations, and that clients should show tool inputs before calling the server and log usage for audit. Shadow MCP is the case where none of those controls was set up by anyone responsible for them.
Why doesn't a ban work?
For the same reasons it fails with chat apps. The tools are useful, the config is a text file, and a developer who is blocked on one machine will use another. A flat ban also removes your chance to see what people actually need. A better approach is to make the approved path easier than the unapproved one.
How do you bring it under control?
- Ask first. Run a short survey or review agent settings files in a pilot group. You will usually find more than you expect.
- Publish an allowlist of approved servers and a one-paragraph process to request a new one, with an answer in days, not months.
- Route approved servers through one point. An MCP gateway gives you masking, tool-level access rules and logs for every call.
- Scope credentials. Give each server its own narrow token, with read and write kept separate.
- Review tool descriptions when a server is added and when it changes.
- Revisit every quarter. New servers appear weekly.
What can Maskflare do about it?
Maskflare controls the paths that go through it. In the console you register an MCP server by name, and agents reach it at /v1/mcp/{server}. A call to a name that isn't registered is refused as unknown. For hosts that can't change their server URL, the forward proxy can inspect the MCP hosts you list. Registered servers get tool access per group, with destructive tools denied by default, masking of personal data and secrets in both directions, and injection screening of results and tool listings. See agent and MCP security.
For developers on Claude Code, OpenAI Codex, Cursor, GitHub Copilot CLI and VS Code agent mode, the coding-agent hooks cover another path. In Claude Code the hook masks the input and output of MCP tools on the machine where it is installed, and blocks prompts that contain secrets. The desktop agent installs and keeps those hooks in place.
What should the policy say?
One page is enough. Name the approved servers. Say which data must never reach any server, with examples from your own work such as customer IBANs or patient names. Say that tokens must be personal to the task and rotated. Explain how to request a new server, and promise a fast answer. Finally, say what happens after a mistake: if reporting an unapproved server gets someone punished, you will never hear about the next one.
Frequently asked questions
Is shadow MCP the same as shadow AI?
They overlap. Shadow AI covers any unapproved AI tool or account. Shadow MCP is the narrower case of unapproved tool servers connected to agents, where the exposure is standing access to systems rather than a pasted prompt.
Can Maskflare find MCP servers on our laptops?
No. Maskflare controls MCP servers that are registered with its gateway or inspected in proxy mode. It does not scan devices for server configurations, so discovery needs your own process.
Do local stdio servers pass through the gateway?
No. A server started as a local process and used directly does not go through the gateway route. For Claude Code, the Maskflare hook can still mask the input and output of its MCP tools on that machine.
What is the first step if we suspect shadow MCP?
Look at the agent configuration files of a pilot group and list every server and token. Then decide which to approve, which to replace and which to remove.
Should we block all MCP servers until reviewed?
A short freeze can make sense for sensitive teams. As a long-term policy it tends to push use out of sight. A fast approval process with a gateway usually reduces more risk.