MCP Security Review Checklist
Model Context Protocol deployments need controls across transport, tool surface, descriptor trust, scoped authorisation, and audit — not just “the server is up”. This checklist covers all six control areas with lifecycle gates and evidence requirements. 28 rows, ready to paste into your AI Committee review.
Get the spreadsheet
Enter your email to download
Excel format (.xlsx). Opens in Excel, Google Sheets, or any spreadsheet tool. Includes a how-to guide tab and working columns for status, owner, gap tracking. You'll also receive new blog posts when they publish.
Who it's for
AI platform engineers, AppSec leads, and AI governance teams reviewing an MCP server deployment before pilot or production.
Use it per MCP deployment — one copy per server under review. It is especially useful before pilot, when transport security, tool surface scope, and descriptor trust need to be locked in.
How to use it
- 1Identify the MCP deployment: server, clients, host environment, tools exposed.
- 2Filter by Lifecycle Gate — Before pilot controls must be in place before any client connects.
- 3For each tool, complete the Tool Surface rows — add rows as needed.
- 4Treat any descriptor whose source is undocumented as a control gap.
- 5Mark each row: Covered / Partial / Missing / Not applicable / Unknown.
- 6Treat Missing rows at the relevant gate as review blockers.
What's in the file
Five fixed columns plus eight working columns (status, owner, evidence link, gap, priority, target date, notes). Each row is a specific control — not a category.
| Column | Contents |
|---|---|
| Control area | Transport / Tool surface / Descriptor / Authorisation / Audit / Lifecycle |
| Required control | Specific, actionable — not a category |
| Lifecycle gate | Before pilot / Before production / Ongoing |
| Evidence required | What you show an auditor or AI Committee to prove the control is working |
| Framework tags | OWASP Agentic, NIST AI RMF, ISO 42001 clause, EU AI Act article |
Sample row — Descriptor trust
| Area | Control | Gate | Evidence | Frameworks |
|---|---|---|---|---|
| Descriptor | Descriptor content reviewed as instruction content (not just as documentation) | Before pilot | Descriptor review record showing each description vetted for embedded instructions | OWASP Agentic, OWASP LLM |
From checklist to review pack
Spreadsheets are the starting point
This checklist helps identify which MCP security controls are in place and which are missing. Drel turns that gap analysis into a guided AI security review — mapping controls to findings, generating a risk disposition, and producing a review-ready dossier your AI Committee can actually approve or reject.
Frequently asked questions
- What is MCP and why does it need a dedicated checklist?
- Model Context Protocol is an open standard for connecting AI models to external tools and data. MCP standardises the surface where LLM instructions meet the world — which makes some risks (descriptor poisoning, scoped delegation, audit trail completeness) protocol-specific and not fully addressed by traditional AppSec checklists.
- What is descriptor poisoning?
- An MCP tool descriptor includes a name and description that the LLM reads as part of deciding when and how to call the tool. If the description contains content that the LLM treats as instructions, the agent's behaviour can be manipulated by whoever supplied the descriptor. The checklist requires that every descriptor's source is documented and the content reviewed as instruction.
- How does this complement the OWASP Agentic Top 10 control map?
- The OWASP Agentic Top 10 covers all agentic systems. This checklist drills into MCP-specific implementations of the same risk categories — particularly A02 (Prompt Injection via tool output), A03 (Tool Misuse), A06 (Tool Injection via malicious descriptors), and A09 (Identity).
- Does this assume a specific MCP server implementation?
- No. The checklist is implementation-agnostic. Where a specific MCP server doesn't support a control (e.g., no scoping mechanism), record the gap and note the compensating control from a different layer (network segmentation, separate servers per scope).
- What lifecycle gate applies to authorisation controls?
- Per-client authentication and scoped tokens must be in place before pilot. Revocation mechanisms and scope-change logging are required before production. Quarterly review of the authorisation model is an ongoing control.
- Can I use this for both MCP servers I run and MCP servers I consume?
- Yes. Most rows apply equally to server-side and client-side review. For MCP servers you consume from a third party, treat the descriptor sourcing and the contractual security commitments as your evidence — and add a re-assessment trigger when the upstream server changes.