MCP Security Checklist (Copy and Use)

An MCP security checklist is a short list of controls you confirm before and after connecting AI apps to MCP servers. The one below has 40 numbered items in eight groups. Copy it into a doc or ticket, assign an owner to each group, and mark each item yes, no or not applicable.

Every item traces back to a primary source. Most come from the official MCP Security Best Practices for the 2026-07-28 spec, the tools specification, or the OWASP MCP Top 10. OWASP lists that project as "Beta Release and Pilot Testing" as of October 2026, so expect its wording to change.

The checklist suits IT leads, small business owners and developers. Items marked "(builders)" are for teams that run or write their own servers.

How to use this checklist

Work top to bottom. Groups 1 and 2 matter most for everyone. Groups 3 to 5 depend on whether you use local servers, remote servers or both.

Write the date and the reviewer's name at the top. Keep the completed copy with your security records. A "no" is not a failure; it is a task with an owner and a due date.

The checklist

1. Inventory and approval

1. We keep a written list of every MCP server in use, with publisher, version, hosting (local or remote) and business owner.
2. We know which AI apps (clients) connect to each server.
3. No new server touches company data without approval from a named person.
4. We have checked for "shadow" servers. OWASP's entry on shadow MCP servers describes these as "unapproved or unsupervised deployments" and suggests regular discovery scans.
5. Unused servers are removed, not just ignored.

2. Identity, tokens and scopes

1. Remote servers use OAuth sign-in rather than shared, long-lived API keys, where the vendor offers both.
2. Each server requests only the scopes it needs. The best practices list wildcard scopes such as *, all or full-access as a common mistake.
3. Write access is granted only to workflows that need it. Everything else starts read-only.
4. (builders) The server validates that tokens were issued for it. The best practices state that servers "MUST NOT accept any tokens that were not explicitly issued for the MCP server."
5. (builders) The server never forwards a client's token to a downstream API (no "token passthrough").
6. (builders) Proxy servers that use one static client ID show their own consent screen for each client, as the confused deputy section requires.
7. Tokens are revoked when a person leaves or a server is retired.

3. Local servers

1. Every local server comes from a publisher we can identify, such as a verified namespace in the official MCP Registry.
2. Someone read the full install command before approving it. The spec says clients offering one-click setup must show "the exact command that will be executed, without truncation."
3. Local servers use the stdio transport where possible. The best practices recommend stdio "to limit access to just the MCP client."
4. Any local server using HTTP requires a token and listens only on 127.0.0.1, not all network interfaces.
5. Local servers run in a sandbox or container with limited file and network access. See sandboxing local MCP servers.

4. Remote servers (builders)

1. The server validates the Origin header on every connection. The Streamable HTTP spec makes this a MUST, to block DNS rebinding.
2. Every connection is authenticated. Several 2026 CVEs involved HTTP modes with no authentication at all.
3. State handles (cart IDs, workflow IDs) are random, bound to the signed-in user, and never treated as proof of identity.
4. The client blocks OAuth discovery URLs that point at private IP ranges or cloud metadata addresses (SSRF protection).
5. Authorization URLs are checked so only https:// (or loopback http:// in development) can open.

5. Tool use and approvals

1. A person can see which tools are exposed and can deny any call. The tools spec says there "SHOULD always be a human in the loop."
2. Payments, deletions and outbound messages need explicit confirmation.
3. The client shows tool inputs before sending them, as the tools spec recommends, to catch accidental data leaks.
4. Tool annotations (hints like "read-only") are not trusted unless the server is trusted. The spec makes this a MUST for clients.
5. No single agent combines private data, untrusted content and a way to send data out, unless approvals sit in between.
6. Tool descriptions are reviewed after updates, to catch a server that changed after approval.

6. Logging and monitoring

1. Every tool call is logged with user, client, server, tool, inputs, result status and time.
2. Scope changes are logged. The best practices suggest logging "elevation events (scope requested, granted subset) with correlation IDs."
3. Secrets and tokens are masked in logs, including tokens inside URLs.
4. Logs are stored where the people they record cannot delete them.
5. Someone reviews alerts or a log sample on a set schedule.

7. Supply chain and updates

1. Server versions are pinned. OWASP MCP04 says to pin exact versions and "avoid 'latest'."
2. We watch security advisories for each server, SDK and client we use.
3. MCP SDKs and clients are kept current. The incident tracker lists SDK and client CVEs fixed only by upgrading.
4. Archived or unmaintained servers are replaced. Archived projects may not get security fixes.

8. Review and response

1. This checklist is re-run at least quarterly and whenever a server is added.
2. We have a written plan for a compromised server. See MCP incident response.
3. Staff know how to report a suspicious AI action, and know they will not be blamed for reporting.

How the checklist maps to OWASP

Use this table when someone asks which risks the checklist covers.

For a plain-English walk through each entry, see the OWASP MCP Top 10, explained.

What to fix first

If you score many "no" answers, do not try to fix everything at once. Fix in this order:

1. Items 1, 3 and 5: know what is connected and remove what you do not need.
2. Items 7, 8 and 24: cut access and add approvals for risky actions.
3. Items 14 and 16: close the local-server gaps that allow code to run on your machines.
4. Items 29 and 31: turn on logging, with secrets masked.

The rest can follow over the next quarter. The MCP security best practices from the spec explain the reasoning behind the builder items.

Next step

If you would like a second pair of eyes, our MCP readiness audit works through this checklist with your team and ranks the gaps by risk. Building your own server? Our MCP development team builds the builder items in from the start.

Frequently asked questions