The Model Context Protocol (MCP) is now the standard connecting AI agents like Claude, Cursor, and GitHub Copilot to external tools and data. With over 177,000 registered MCP tools as of 2026 (per the MCPShield formal security framework), the attack surface is enormous and mostly ungoverned. This checklist gives CISOs, security architects, and internal audit teams a practical starting point for auditing MCP server security.
Why this matters
Peer-reviewed research (arXiv 2603.22489) identifies 57 threat classes across the MCP ecosystem using STRIDE and DREAD frameworks. The most impactful is tool poisoning — malicious instructions embedded in a tool's description or inputSchema, read by the model as if authoritative. Analysis of seven major MCP clients revealed insufficient static validation and parameter visibility in most implementations.
Prompt injection now appears in over 73% of production AI deployments (Obsidian Security, 2026). If your organisation has consultants using Claude or Cursor with any MCP server, this checklist applies to you.
The 15-control checklist
Run each control as a yes/no question against every MCP server your organisation uses. A single "no" is a material finding.
Trust boundary and authentication
1. Are all MCP servers on an explicit allow-list? The host should refuse to load any server not on a maintained allow-list. Auto-discovery is a supply-chain risk.
2. Are tokens audience-bound per RFC 8707? The server MUST reject any token not explicitly issued for it. Token passthrough to downstream APIs is explicitly forbidden by the MCP specification (2025-06-18).
3. Are session IDs generated with CSPRNG? UUIDv4 or equivalent. Sequential, guessable, or reused IDs enable session hijacking.
4. Is redirect_uri validated by exact string match? No wildcards. State values must be cryptographically random, single-use, and short-lived.
Tool integrity
5. Are tool descriptions treated as untrusted content? Every string emitted by an MCP server — descriptions, output, annotations, resource contents — must be treated as untrusted. This is the trust boundary.
6. Are tool approvals hash-bound? When a tool is approved and added to the allow-list, its hash should be recorded. On subsequent invocations, mismatched hashes must reject. This prevents rug-pull attacks where a trusted server updates its tools with malicious behaviour post-approval.
7. Is metadata scanned for prompt injection markers before it reaches the model? The host — not the protocol — must screen for injection patterns in tool descriptions and outputs.
8. Are tool outputs labelled as data, not instructions? Sanitise and escape before returning to the model context. Attacker-controlled data returned in tool results is the second most prevalent MCP threat class.
Authorisation and consent
9. Is human-in-the-loop consent enforced for all side-effecting operations?
readOnlyHint MUST NOT be treated as a basis for auto-approval. Every write, delete, or external call requires explicit human confirmation.
10. Do MCP servers operate on least privilege? Read-write scope is granted only where read is insufficient. Read-only mode should be the default for sensitive environments.
11. Is per-client consent maintained on proxy servers? Proxy servers must maintain a registry of approved client_id values and check it before initiating third-party OAuth flows.
Observability and audit
12. Is every tool invocation logged against a verified identity? The log entry must include the authenticated user, the tool identifier and hash, the arguments, the timestamp, and the response. Anonymous or system-account logs fail this control.
13. Is the log tamper-evident? Append-only. Hash-linked. Cryptographically signed. If any log entry can be modified after the fact, the log cannot be relied on in an audit.
14. Can the log be verified offline? A regulator, auditor, or insurer should be able to verify log integrity without access to your production systems. KMS-signed with the public verification key published or escrowed is one pattern.
Supply chain
15. Is the exact server version and signature recorded on every invocation? Supply-chain provenance means knowing which version of which server was in play at the moment of the invocation. Attestation chains that record the server hash at invocation time provide this. Package-manager-level version numbers do not.
What to do with the results
Score honestly. If you fail more than five controls, the risk is material and should be escalated to your executive risk committee. If you fail one or two, it is a normal remediation programme.
If MCP servers are in your consulting toolchain — Claude, Cursor, or GitHub Copilot integrations — this list is the minimum starting point. CyberTeam runs an expanded version of this checklist on every AI security engagement, mapped to the full 57-threat MCP taxonomy.
References
- Model Context Protocol Specification, 2025-06-18 revision (Security Best Practices + Authorization sections)
- Model Context Protocol Threat Modeling and Analysis of Vulnerabilities to Prompt Injection with Tool Poisoning (arXiv 2603.22489)
- A Formal Security Framework for MCP-Based AI Agents (MCPShield, arXiv 2604.05969)
- MCP Security Best Practices (modelcontextprotocol.io)
Get the audit run for you
If you want CyberTeam to run this checklist against your production MCP servers, book a scoping call. We will scope the engagement, give you a fixed price, and deliver a report your internal audit team can defend.