Answer box
Most enterprises now run Model Context Protocol (MCP) servers they never inventoried. The servers bind to localhost or random ports, ship inside developer IDEs and AI assistants, and dynamically expose tools to any agent that asks. Traditional asset management never sees them. This playbook is the 10-step process — discovery, classification, ownership, risk scoring, and runtime governance — for getting MCP under control in 30 days, before the first incident lands on your desk.
Why MCP is the new shadow IT
Model Context Protocol shipped less than two years ago and is already the connective tissue between LLMs and enterprise systems. Every major coding agent, every enterprise AI assistant, every "let the model use a tool" workflow now passes through MCP servers.
The problem: MCP wasn't designed for enterprise governance. Servers run as local processes, often launched by npx, uvx, or vendor-bundled binaries. They register tool descriptions dynamically. They authenticate to backend systems with credentials the agent's user holds. Your CASB never sees the traffic because it never leaves the host. Your DLP never inspects it because it isn't HTTPS to a known SaaS. Your CMDB never lists it because it isn't a process anyone declared.
Qualys recently called MCP "the new shadow IT" (source). CISA's GitHub leak gave us the first major incident-of-record under this category. Cloud Security Alliance's May 2026 report found 79% of organizations have no visibility into agent or MCP traffic (source).
The way through is the way you handled shadow IT in 2017: inventory first, classify, own, then govern. Here is the playbook.
Step 1 — Define what counts as an MCP server in your environment
Before discovery, decide what you are counting. The OWASP Agentic Top 10 (ASI04) treats every "dynamically trusted external resource" as in-scope. For an inventory, narrow that to:
- Local MCP servers — processes launched on a developer or analyst workstation that expose tools via stdio or local sockets.
- Hosted MCP servers — long-running services in your VPC, in SaaS, or in a partner's environment that agents connect to over the network.
- Bundled MCP servers — MCP capabilities embedded inside a vendor product (Claude Code, Cursor, Cline, Codex CLI, internal agents).
If a tool descriptor reaches an LLM and the model can call a function in response, it is in scope. Write this definition down. It will be quoted in audit findings.
Step 2 — Discover MCP traffic from the network
Run a one-week passive scan from your network egress and from each workstation you can instrument:
- Egress: log every connection to known MCP server hosts and to ports
3000-3999,5173,8765, and the OpenAI/Anthropic/Mistral developer ports your IDEs connect to. - Workstation: enumerate child processes of every IDE binary (
code,cursor,claude,codex, JetBrains) and capture their command lines. MCP server invocations almost always includemcpor a server name in the argv.
This passes give you the "first cut" inventory — typically 8-40 distinct MCP servers per developer workstation, far more than the team thinks they run.
Step 3 — Discover MCP servers from configuration files
MCP server lists live in well-known config files. Scan repos and home directories for:
| File | Where to find it |
|---|---|
claude_desktop_config.json |
~/Library/Application Support/Claude/ (macOS), %APPDATA%\Claude\ (Windows) |
claude_code_config.json / .claude/settings.json |
~/.claude/, project root |
mcp.json / mcp.config.json |
project root, often shared in source control |
cursor/mcp.json, cline_mcp_settings.json |
per-editor config dirs |
.vscode/mcp.json |
VS Code MCP extension |
mcp-config.yaml / mcp_servers.toml |
self-rolled internal config |
Cross-reference everything you find against the network discovery. Anything in config but not in network logs is latent — it will run the moment a user invokes the tool. Treat it as active.
Step 4 — Classify every server you found
For each MCP server, capture:
- Name + canonical version — pin to a specific commit or package version. "latest" is not an answer.
- Source — first-party (you wrote it), open-source community, vendor-bundled, partner-hosted.
- Tools exposed — the list of
tools/listentries. This is your function-level inventory. Critical for ASI02 (Tool Misuse) review. - Backend systems touched — every database, SaaS API, internal service, or filesystem path the server can reach.
- Auth model — does it use the user's credentials, a workload identity, an API key, or unauthenticated localhost trust?
- Egress profile — what external hosts the server can reach (npm registry, public APIs, vendor cloud).
- Data sensitivity — does it read source code, customer data, financial systems, PII, PHI, secrets?
A spreadsheet is fine for week one. By week three, this lives in your CMDB or the AccuroAI catalog.
Step 5 — Assign ownership
Every MCP server gets an owner. Not a team — a named individual. This is the single highest-leverage control in the entire playbook.
Two rules:
- No orphans. If you cannot find an owner in 24 hours, the server is decommissioned. Reinstate it through change management if anyone protests.
- The owner is accountable, not the engineer who launched it. Owners are usually a director or above who can authorize a decommission and absorb the productivity hit.
The orphan-decom cycle is uncomfortable, but in our deployments it removes 20-40% of the inventory in week one without any user complaints. Most of the orphans were experiments people forgot they ran.
Step 6 — Risk-score each server
Five dimensions, 0-3 each. Total: 0-15.
| Dimension | 0 | 1 | 2 | 3 |
|---|---|---|---|---|
| Data sensitivity | Public docs only | Internal non-sensitive | PII / source code / financials | PHI, secrets, customer data |
| Backend reach | Read-only local | Read-only network | Write to a system of record | Write to multiple systems of record |
| Auth model | Workload identity, scoped | User token, scoped | User token, broad scope | Long-lived API key or unauthenticated |
| Supply chain | First-party, signed | First-party, unsigned | OSS, pinned + reviewed | OSS, unpinned or unmaintained |
| Egress | None | Allowlisted hosts only | Outbound to npm/PyPI only | Arbitrary internet egress |
Anything 10+ moves to immediate review. Anything 13+ is paused pending mitigation. Document the score; it becomes part of the audit evidence under ISO 42001 A.8.24 and NIST AI RMF MANAGE-2.
Step 7 — Apply the seven baseline controls
For every MCP server that stays in production:
- Pin the version. No auto-upgrade. Subscribe to the upstream release feed. Plan upgrades like dependency upgrades — pinned, reviewed, rolled out staged.
- Allowlist tool descriptors. The runtime knows which tools each server is allowed to expose. New tools require approval before the agent can call them. This is the single most effective control against tool poisoning.
- Inspect tool responses. Run inline inspection on what the server returns to the agent, not just on user input. Indirect prompt injection lives in tool responses. AccuroAI's Protect layer does this in <38ms.
- Scope credentials per call. The agent receives a short-lived, capability-scoped token per task, never a long-lived API key.
- Log every tool call with full provenance: user, agent identity, MCP server name+version, tool name, arguments, response hash, latency. This is your audit trail.
- Network-isolate local MCP servers from production data stores. If the server doesn't need to reach prod, deny it at the host firewall.
- Decommission tracking — every server in the inventory has an expected end-of-life date. Servers without one default to 90 days, then re-review.
These map to OWASP ASI02, ASI03, ASI04, and ASI07 directly.
Step 8 — Build the agent-to-server graph
You cannot govern what you cannot draw. For each agent in production, map which MCP servers it calls. For each MCP server, map which agents call it.
Look for three patterns:
- One-to-many — one agent calling many servers. Usually fine. Review the tool-graph for unsafe compositions (read-internal + write-external in the same chain).
- Many-to-one — many agents calling one server. This is your highest-blast-radius asset. A compromise here cascades. Apply the strictest controls here first.
- Untracked servers — servers that appear in agent logs but not in your inventory. These are the gaps your discovery missed. Run Step 2-3 again.
Render this as a graph. Show it at the next AI risk committee. It will be the most-discussed slide in the deck.
Step 9 — Stand up MCP-specific incident response
When an MCP server is compromised, the first 60 minutes matter. Pre-stage:
- Kill switches — per-server and per-tool. Disabling a tool descriptor should take seconds, not change windows.
- Detection signals — anomalous tool-call rates, new tool descriptors appearing, response patterns containing injection signatures, egress to new hosts.
- Forensic snapshot — when a server is killed, capture process state, network logs, and the last N tool calls automatically.
- Communication tree — who gets paged when which class of MCP incident fires.
Run a tabletop drill in week four. Most enterprises discover their kill switch needs a config-file edit + redeploy + IDE restart. That is not a kill switch.
Step 10 — Make the inventory live, not a quarterly snapshot
The single failure mode of this playbook is treating the inventory as a one-time exercise. MCP servers turn over weekly. New ones ship inside every IDE update. Make the inventory continuous:
- Re-run discovery (Steps 2-3) weekly, automated.
- Diff against last week. Any new server enters a 24-hour review window before it can call sensitive tools.
- Any change to an existing server's tool list re-triggers classification (Step 4) and re-scoring (Step 6).
- Decommission tracking from Step 7 fires alerts as servers approach end-of-life.
This is exactly the workflow AccuroAI runs as a managed service — continuous discovery, classification, scoring, and inline tool-response inspection in one control plane. If you would rather not stand it up internally, book a 30-minute demo and we will run the first inventory against your environment as part of the pilot.
What you should have in 30 days
| Week | Output |
|---|---|
| 1 | First-pass inventory from network + config-file discovery. Definition document. |
| 2 | Classified inventory with ownership assigned. Orphan decommissions complete. |
| 3 | Risk scores applied. Top-10 servers fully under the seven baseline controls. |
| 4 | Agent-to-server graph drawn. Incident response runbook + tabletop. Continuous-inventory pipeline live. |
A defensible MCP governance program inside one month. Past this, the work is operational — keeping the inventory current and tightening controls as the OWASP framework evolves.
FAQ
What is MCP? Model Context Protocol — an open specification for how LLMs discover and call external tools. Servers expose tool descriptions; agents call them. Originally published by Anthropic, now adopted across the industry.
Why is MCP an enterprise security risk? MCP servers run as local processes, expose tools dynamically, and inherit user credentials. They are invisible to CASBs, DLPs, and SIEMs. They are the primary attack surface for ASI04 (Agentic Supply Chain Compromise) and a major surface for ASI02 (Tool Misuse).
How do I find MCP servers I don't know about? Combine network egress logs with workstation-level child-process enumeration and a scan of well-known config file paths. See Step 2 and Step 3.
Is there a Gartner / OWASP framework for MCP specifically? Not yet a standalone one. OWASP's Top 10 for Agentic Applications 2026 covers MCP risks under ASI04 and ASI07. Gartner's expected H2 2026 AI-SPM Market Guide will likely include MCP under tool/agent posture.
Who should own MCP governance internally? Joint ownership: AI security or security architecture owns policy; platform engineering owns the runtime; GRC owns audit evidence. The single most common failure mode is leaving it to "the AI team" without security in the loop.
Sources: Qualys — MCP Servers as Shadow IT · Cloud Security Alliance — Shadow AI Agents · OWASP Top 10 for Agentic Applications 2026.
Related: The OWASP Top 10 for Agentic Applications 2026, Annotated for Enterprises · Agentic AI Governance: Enterprise Risk and Control Frameworks.