1. Start with the actual attack surface
The official Model Context Protocol documentation describes MCP as an open standard that lets AI applications connect to external systems such as files, databases, tools and workflows. In security terms, that means an MCP connection can bridge a model-driven application to systems that hold data or perform actions.
The first control question is therefore not “which servers are on our approved list?” It is “which MCP servers and configurations are actually present?” An approved catalog is useful, but it cannot govern connections nobody has discovered.
Inventory comes before policy. Discovery is not a security verdict; it is the evidence base required for review, approval and monitoring.
Where is MCP configured?
Identify supported client and project configuration surfaces without executing server code.
Where did it come from?
Keep provenance: client, project, configuration source and safe structural identity.
What can it reach?
Review transport, command identity, requested scope, credentials and exposed tool behavior.
What changed?
Baseline the approved structure and surface meaningful drift for human review.
3. Treat tool definitions and outputs as untrusted input
OWASP's MCP Security Cheat Sheet highlights tool poisoning, tool shadowing, cross-server escalation and prompt injection through tool return values. The important operational lesson is simple: tool metadata participates in model behavior.
A review should consider tool names, descriptions, parameter schemas and return behavior — not only package reputation. If a tool definition changes after approval, the security decision may need to be revisited even when the package name is unchanged.
Static inspection can reveal structure and suspicious signals, but it cannot prove a server is safe. Runtime behavior, authorization, deployment context and future changes still matter.
4. Review the supply chain before execution
MCP servers are software dependencies. OWASP recommends verifying source and publisher identity, reviewing source and tool definitions, checking dependency risk and monitoring for post-installation changes. For public repositories, useful pre-execution evidence can include ownership, project age, recent maintenance, release activity, license information, install scripts and dependency manifests.
That evidence is valuable precisely because it can be collected before running untrusted repository code. It should support a human decision, not replace one.
Open the public repo evidence scanner ↗5. Minimize blast radius
Least privilege is a recurring control across MCP and OWASP guidance. The practical goal is to limit what a compromised or manipulated server can do: narrow filesystem access, narrow network access, narrow OAuth scopes, isolate sensitive servers, and require explicit human confirmation for destructive or high-impact actions.
Teams should evaluate both capability and context. A filesystem tool restricted to a project directory is a different risk from the same tool running with broad home-directory access. A read-only integration is different from one that can modify or delete production data.
6. Approval is a lifecycle, not a checkbox
OWASP explicitly warns that an MCP tool approved yesterday may not be the same tool today. That makes structural baselines and drift review valuable controls. An approval record should identify the reviewed structure, while later changes should create a review event rather than silently inheriting trust.
A practical model is:
- discover the current MCP inventory;
- review structural evidence and ownership;
- approve the known structure;
- compare later states against that baseline;
- require human review when a current server is new or materially changed;
- use CI or policy gates where the workflow needs a machine-readable stop signal.
Approval should mean “matches the reviewed structural baseline,” not “safe forever.”
7. Practical MCP security review checklist
- Inventory: Do we know every MCP configuration currently present in the supported environment?
- Provenance: Can we identify the source, publisher and configuration location?
- Execution: For local servers, what executable or package will run and with which host privileges?
- Transport: Is the server local or remote, and is the remote connection authenticated and protected?
- Permissions: Are filesystem, network, API and OAuth scopes minimal?
- Tool integrity: Have tool descriptions, schemas and outputs been treated as possible injection surfaces?
- Supply chain: Have repository/package provenance, dependencies and install behavior been reviewed before execution?
- Secrets: Are credentials stored and transmitted appropriately rather than exposed in configs or logs?
- Human control: Do destructive or sensitive actions require meaningful confirmation?
- Drift: Will a changed server definition, configuration or permission set trigger re-review?
- Audit: Is there enough privacy-safe evidence to explain why the connection was approved?
Sources and further reading
This page is an independent ShadowMCP synthesis. Protocol and security claims are grounded in the sources below; ShadowMCP's evidence-first framing is our own operational model.