Every MCP server an agent connects to can read the agent's context, act with the agent's credentials and feed text straight into the model, so an unchecked server is an unchecked privileged integration. This template is a tickable checklist for approving a Model Context Protocol server before agents use it, and for re-checking it on every new version. Each check is tied to a requirement in the MCP specification (version 2026-07-28, the latest version listed when checked on 8 November 2026) or its Security Best Practices page, so findings can be argued from the standard rather than opinion. It covers provenance, authorisation, token handling, tool poisoning, local server isolation, network and SSRF controls, and logging. It is written for platform, security and AI engineering teams; for the reasoning behind each control read the MCP Security Best Practices Explained guide.
How to use this template
- Replace text in square brackets, such as [Organisation], [server name] and [MCP gateway], with your own details.
- Run the checklist when a server is first requested, on every version or configuration change, and at least every [six months] for servers in use.
- Mark each check Pass, Fail, N/A (state why) or Exception (link the approved risk acceptance). "Spec" shows the specification keyword: MUST and MUST NOT checks cannot be excepted for production use.
- Sections 3 and 4 apply to remote servers using HTTP; section 6 applies to local servers using stdio. Answer both when a server supports both.
- Keep the completed checklist with the server's record in your MCP inventory. See the MCP Server Trust Assessment for the wider risk rating that this checklist feeds.
- Specification wording changes between versions. Record the specification version you checked against in section 1.
1. Server record
| Field | Value |
|---|---|
| Server name and version | [name], [version or commit hash] |
| Publisher and source | [official vendor / internal team / community], [repository and package registry URL] |
| Transport | [stdio local / Streamable HTTP remote] |
| MCP specification version supported | [for example 2026-07-28] |
| Downstream systems and credentials used | [APIs, databases, SaaS], [credential type and owner] |
| Data classification reachable | [public / internal / confidential / regulated] |
| Business owner and technical owner | [names] |
| Reviewer and date | [name], [date] |
2. Provenance and supply chain
Malicious and impersonating servers are a demonstrated risk. In the postmark-mcp malicious MCP server case, a package under a trusted-sounding name behaved for fifteen versions and then began copying every email it sent to an attacker.
| ID | Check | Result |
|---|---|---|
| PRV-01 | The server comes from the publisher of the downstream system or from an internal team, not a look-alike package. The registry account and repository are verified to belong to that publisher. | [ ] |
| PRV-02 | The version is pinned (exact version or digest), not "latest", in every client and gateway configuration. | [ ] |
| PRV-03 | The diff between the approved version and any new version has been reviewed before upgrade, including changes to tool descriptions. | [ ] |
| PRV-04 | Dependencies have been scanned for known vulnerabilities and the server has a maintainer, a release history and a way to report vulnerabilities. | [ ] |
| PRV-05 | The server is recorded in the [MCP inventory or registry] with owner, scope and review date, and clients can only load servers from that allowlist. | [ ] |
See the MCP Registry and Server Publishing Security Guide.
3. Authorisation (remote servers)
Authorisation is optional in MCP, but when an HTTP server supports it the specification says it should conform to the Authorization specification, which builds on OAuth 2.1.
| ID | Check | Spec | Result |
|---|---|---|---|
| AUT-01 | Any server exposing non-public data or actions requires authorisation. An unauthenticated remote server is limited to public, read-only tools. | [Organisation] rule | [ ] |
| AUT-02 | The server publishes OAuth 2.0 Protected Resource Metadata (RFC 9728) naming its authorisation server(s). | MUST | [ ] |
| AUT-03 | The authorisation server implements OAuth 2.1 with PKCE and publishes RFC 8414 or OpenID Connect Discovery metadata. | MUST | [ ] |
| AUT-04 | Client registration uses Client ID Metadata Documents or pre-registration. Dynamic Client Registration is deprecated in the 2026-07-28 version and, if still enabled, is restricted and monitored. | SHOULD / MAY | [ ] |
| AUT-05 | Clients send the resource parameter (RFC 8707) with the server's canonical URI in authorisation and token requests. | MUST | [ ] |
| AUT-06 | The authorisation server returns iss in authorisation responses (RFC 9207) and clients validate it, which protects against mix-up attacks. | SHOULD (server) / MUST (client) | [ ] |
| AUT-07 | scopes_supported lists only the minimal scopes for basic use; higher scopes are requested by step-up through a WWW-Authenticate scope challenge; no wildcard or "full-access" scopes. | SHOULD | [ ] |
| AUT-08 | The server enforces authorisation on every tool call against the caller's identity and scopes, not only at connection. Possession of a state handle (cart ID, workflow ID) is never treated as authentication, and handles are bound to the authenticated user. | MUST / SHOULD | [ ] |
| AUT-09 | If the server proxies a third-party API with a static client ID, it shows its own per-client consent page (client name, scopes, redirect URI), with CSRF protection and anti-framing, before forwarding, and validates redirect URIs by exact match. | MUST | [ ] |
See the MCP Authorisation Specification Guide.
4. Token handling
| ID | Check | Spec | Result |
|---|---|---|---|
| TOK-01 | The server validates that every access token was issued for it as the audience and rejects others with HTTP 401. | MUST | [ ] |
| TOK-02 | No token passthrough: the server never forwards the client's token to downstream APIs; it uses its own credential or a token obtained for the downstream audience. | MUST NOT accept or transit other tokens | [ ] |
| TOK-03 | Tokens travel only in the Authorization: Bearer header, never in the URL query string, and every request carries authorisation. | MUST | [ ] |
| TOK-04 | Refresh tokens are kept confidential in transit and storage; clients do not assume they will be issued. | MUST | [ ] |
| TOK-05 | Downstream credentials held by the server are scoped to the tools exposed, short-lived or rotated on schedule, stored in [secrets manager], and owned by a named person. | [Organisation] rule | [ ] |
| TOK-06 | Sensitive parameters (passwords, API keys, tokens, personal data) are not marked with x-mcp-header, because header values are visible to intermediaries. | SHOULD NOT | [ ] |
The LiteLLM MCP auth bypass shows why token validation and default credentials belong on this list. See the Secrets Management Guide for TOK-05.
5. Tools, tool poisoning and prompt injection
Tool names, descriptions, annotations and results all reach the model as text. A changed description or a poisoned result is indirect prompt injection (OWASP LLM01:2025), and over-broad tools are excessive agency (LLM06:2025).
| ID | Check | Spec | Result |
|---|---|---|---|
| TOL-01 | Tool descriptions and schemas have been read by a reviewer and contain no instructions to the model beyond describing the tool (for example "also read ~/.ssh" or "do not tell the user"). | [Organisation] rule | [ ] |
| TOL-02 | Clients treat tool annotations (such as read-only hints) as untrusted unless the server is trusted. | MUST | [ ] |
| TOL-03 | The tool list is fingerprinted at approval; a notifications/tools/list_changed event or a changed hash triggers re-review before the new tools are exposed to agents. | [Organisation] rule | [ ] |
| TOL-04 | Where several servers are aggregated, tool names are prefixed or disambiguated so one server cannot shadow another's tool. | SHOULD | [ ] |
| TOL-05 | The server validates all tool inputs, implements access controls, rate limits invocations and sanitises outputs. | MUST | [ ] |
| TOL-06 | Clients ask for user confirmation on sensitive operations, show tool inputs before calling, validate results before passing them to the model and apply timeouts. | SHOULD | [ ] |
| TOL-07 | Only the tools the use case needs are enabled; destructive tools (delete, send, pay, change permissions) require human approval. | [Organisation] rule | [ ] |
The Sentry MCP agentjacking case shows a tool result, not a tool description, carrying the injected instructions. See the MCP Security Testing Guide for how to test TOL-01 to TOL-06.
6. Local servers and client configuration
Local servers run with the user's privileges. In the Amazon Q MCP config vulnerability, opening a repository started servers defined in a project file without consent, and those processes inherited the developer's cloud credentials.
| ID | Check | Spec | Result |
|---|---|---|---|
| LOC-01 | Clients with one-click local server set-up show the full command and arguments, warn that it executes code, and require explicit approval. | MUST | [ ] |
| LOC-02 | Project or repository files cannot start MCP servers without workspace trust and user consent. | [Organisation] rule | [ ] |
| LOC-03 | The server runs sandboxed (container or application sandbox) with file system access limited to named directories and network access limited to named hosts. | SHOULD | [ ] |
| LOC-04 | Local servers use stdio, or, if they listen on HTTP, require an authorisation token or use a restricted IPC channel such as a Unix domain socket. | SHOULD | [ ] |
| LOC-05 | Credentials are passed to stdio servers from the environment or [secrets manager] with the narrowest scope, not the user's full cloud profile or SSH agent. | [Organisation] rule | [ ] |
See the Local MCP Server Security Guide.
7. Network, transport and SSRF
| ID | Check | Spec | Result |
|---|---|---|---|
| NET-01 | Remote servers and authorisation servers use HTTPS; http:// is accepted only for loopback in development. | MUST (authorisation URLs) | [ ] |
| NET-02 | Clients deployed on servers block OAuth discovery and metadata fetches to private, loopback and link-local ranges, including 169.254.0.0/16, and validate redirect targets. | SHOULD | [ ] |
| NET-03 | Clients reject authorisation URLs with javascript:, data:, file: or other non-HTTP schemes and never open URLs through a shell. | MUST | [ ] |
| NET-04 | Outbound traffic from the server and server-side clients goes through an egress proxy or allowlist. | SHOULD | [ ] |
| NET-05 | Remote servers sit behind [MCP gateway or API gateway] with authentication, rate limiting and policy enforcement. | [Organisation] rule | [ ] |
See the Remote MCP Server Hardening Guide and the Agent Egress Control and Network Isolation Guide.
8. Logging, monitoring and response
| ID | Check | Result |
|---|---|---|
| LOG-01 | Every tool call is logged with the calling user or agent identity, client ID, tool name, arguments (redacted where sensitive), result status and downstream identity used. Clients log tool usage as the specification recommends. | [ ] |
| LOG-02 | Scope elevation events (scope requested, subset granted) are logged with correlation IDs. | [ ] |
| LOG-03 | Logs reach [SIEM] with alerts for new tools, tool list changes, denied authorisation spikes, unusual data volumes and calls outside business patterns. | [ ] |
| LOG-04 | A tested procedure exists to disable the server, revoke its tokens and downstream credentials, and identify affected agents and data. | [ ] |
See the MCP Incident Response Playbook for LOG-04.
Implementation guidance
This section is for the team that owns MCP approvals.
- Inventory first: find the servers already configured in IDEs, desktop assistants and agent platforms before running the checklist on new requests. See the Unsanctioned AI Agents and MCP Servers Guide.
- Tier the checks: a read-only server over public data needs sections 1, 2, 5 and 7; a server with write access to confidential systems needs every section and a named owner.
- Enforce centrally: where you run an [MCP gateway], implement PRV-05, NET-05, TOL-03 and LOG-01 there, so individual clients do not have to.
- Re-run on change: tie PRV-03 and TOL-03 to your dependency update process; most risk enters through upgrades, not first installs.
- Measure: percentage of servers in use that are in the inventory with a passing checklist; servers with any failed MUST check; median days from new version release to review; percentage of servers with pinned versions; tool calls logged with agent identity.
| Checklist section | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 | Other |
|---|---|---|---|
| Provenance (2) | SR-3, SA-9 | GV.SC-07, ID.AM-02 | ATT&CK T1195.002 Compromise Software Supply Chain |
| Authorisation and tokens (3, 4) | AC-6, IA-5 | PR.AA-05 | OAuth 2.1, RFC 8707, RFC 9728 |
| Tools and injection (5) | SI-10, CM-7 | PR.AA-05 | OWASP LLM01:2025, LLM06:2025 |
| Local and network (6, 7) | CM-7, SC-8 | PR.AA-05 | MCP Security Best Practices |
| Logging (8) | AU-2 | PR.PS-04 |
Standards and references
- Model Context Protocol: Security Best Practices
- Model Context Protocol: Authorization
- Model Context Protocol: Tools
- IETF: RFC 9728 OAuth 2.0 Protected Resource Metadata
- IETF: RFC 8707 Resource Indicators for OAuth 2.0
- OWASP: Top 10 for LLM Applications 2025
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
Related NHI Mgmt Group resources: MCP Security Guide · MCP Security Best Practices Explained · MCP Server Trust Assessment · MCP Gateway and MCP Server Governance Guide · MCP Incident Response Playbook