How is this checklist different from MCP best practices?

Format and use. The best-practices article argues the controls and explains the reasoning, which is what you read to understand why each control exists. This checklist is an audit instrument: each item has a pass criterion you verify against a running deployment, so it is what you run to find out where you stand. Use the best-practices piece to learn the controls and this list to grade a specific deployment against them. A failing item here maps directly to a section there.

Which items can a gateway verify, and which cannot?

A network control on the streamable HTTP transport can verify and enforce transport exposure, authentication and audience validation, per-call authorization, egress allowlisting, and independent audit, because all of that traffic passes through it. It cannot verify items about stdio servers, since that traffic never crosses a network, or items about installed-package provenance, which are supply-chain review rather than runtime enforcement. The checklist groups items so the split is visible: enforce the HTTP items at a control point and cover the stdio and supply-chain items with host hardening and provenance checks.

Why is per-server audience validation called out specifically?

Because it is the control that prevents a confused-deputy attack and the one deployments most often miss. If a server accepts any validly signed token regardless of whom it was minted for, a token issued for a low-sensitivity server can be replayed against a high-sensitivity one, and the second server acts on the first server's authority. Validating that the token's audience matches the specific server being called closes that path. It is a one-line check that is genuinely load-bearing, which is why it gets its own item rather than folding into general token validation.

What does independent audit commit mean in practice?

It means the record of a decision is written by something other than the process that executed the tool, and it commits before or independently of the tool's own success. An application that runs a tool and also writes its own audit log can lose that log on a crash after the action, or suppress it, or log selectively. A decision recorded at a separate enforcement point survives a crash of the tool-running process and cannot be edited by it. That independence is what makes the record usable as evidence in an investigation rather than a convenience log the same system controls.

MCP Security Checklist: A Deployment Audit Instrument With Pass Criteria

A checklist earns its place by being gradable. Each item has a pass criterion you can verify against a running deployment, so an auditor and a builder reach the same verdict. This is an audit instrument for a Model Context Protocol deployment, grouped into six sections, with an explicit pass criterion for each item. It complements the prose in MCP security best practices, which argues the controls, and the ranked failure modes in MCP security risks, which explains why they matter. Run this against your deployment and count the items that fail their criterion; that count is your work queue.

Section 1: transport and exposure

The transport decides what a network control can even see, so it comes first.

Transport is declared per server. Pass: every MCP server is recorded as stdio or streamable HTTP, and the record is current. A server whose transport nobody can state fails.
HTTP servers are not bound to public interfaces without authentication. Pass: no streamable HTTP MCP server is reachable from an untrusted network without an authentication check in front of it. The NSA and CISA MCP guidance from June 2026 is explicit that unauthenticated exposed servers are the first failure to close.
stdio servers are treated as a local trust domain. Pass: stdio servers are covered by host controls, and no control document claims a network gateway governs them. Marking a stdio server as network-protected is a fail, because the traffic never crosses a network.

Section 2: authentication

The server validates access tokens as an OAuth 2.1 resource server. Pass: every HTTP request is rejected without a valid token whose signature, issuer, and expiry check out.
Token audience is validated per server. Pass: a token minted for one MCP server is rejected by another. This is the control that stops a confused-deputy path, and it is the item most deployments miss.
No shared static credential fronts multiple callers. Pass: each caller presents its own identity, and the server never accepts one shared key standing in for many agents.

Section 3: authorization

Each tools/call is authorized, not just the session. Pass: connecting authenticates identity, and every individual tool invocation is checked against the caller's role before it runs.
Authorization includes argument-level constraints. Pass: a caller permitted to run a tool is still constrained on the arguments, so read_record on an allowed table does not imply every table.
Default is deny. Pass: a tool or argument not explicitly permitted is refused. An allow-by-default policy fails this item regardless of how many rules it lists.

Section 4: egress

Each server has a destination allowlist. Pass: an MCP server can reach only the APIs and data stores its tools declare, and an attempt to reach elsewhere is blocked.
Egress is enforced, not just documented. Pass: the allowlist is applied at a control point on the path, and pointing a tool at a non-listed host actually fails rather than merely violating a written policy.

Section 5: audit

Every authorization decision is logged. Pass: pass and block decisions both produce a record with caller identity, tool, arguments, and outcome.
The audit record commits independently of the server that ran the tool. Pass: the log survives a crash of the tool-running process, because a record the same process can lose or overwrite is self-attestation rather than evidence.
Records name the actor, not the proxy. Pass: identity is propagated so a downstream log shows the human or agent that made the request rather than a shared service account.

Section 6: supply chain

Installed servers come from verified sources. Pass: the provenance of every MCP server binary or package is known and checked, addressed in MCP server supply chain security.
Tool descriptions are treated as untrusted. Pass: the deployment accounts for tool-description injection, where a malicious server's tool metadata carries instructions, covered in MCP tool poisoning prevention.

Reading the results

Items 1 through 3, 4 through 11, and 12 through 14 on the HTTP transport are verifiable at a network control point, which is why an MCP gateway is the practical place to enforce and evidence them across many servers at once. Items covering stdio servers and installed-package provenance sit in host hardening and supply-chain review, outside what a network control can see. The timing on the enforceable items is not negotiable: Google Mandiant's M-Trends 2026 report put median attacker handoff at 22 seconds, so an authorization decision that is logged after the tool ran is a record and not a control.

DeepInspect

Most items in sections 2 through 5 above describe one enforcement and logging point in front of your HTTP MCP servers. That is what DeepInspect is.

DeepInspect is a stateless proxy on the AI request path between agents and the MCP servers and models they call. It validates the caller identity your application supplies, authorizes each tools/call against role and arguments with a default-deny posture, holds no shared downstream credential, constrains egress per server, and commits a per-decision audit record that survives a crash of the process that ran the tool, inline and fail-closed. It covers the HTTP transport items on this list at one point across every server behind it. The stdio and supply-chain items stay in host and package controls by design, and this checklist is honest about that split. Book a demo today.