THE VERDICT: Most MCP security reviews fail in one of two directions: they audit the code and miss the registry, or they audit the registry once and never again. A defensible audit is a fixed 27-point instrument covering five domains — Registry & Provenance (5), Schema Integrity (5), Grants & Trust Tiers (5), Runtime Output Handling (6), Change & Operations (6) — run as a repeatable sweep, not a one-time ceremony. On our reference estate (10 servers, 140 tools) the sweep takes three auditor-days, and 22 of the 27 checks are mechanically verifiable from the registry alone. Audit the static estate first; sample the runtime; re-run on every registry change.
- The 27-point checklist makes MCP audits repeatable: same instrument, same evidence format, same scoring, every time — so a registry that passes twice in a row is actually improving, not just re-audited.
- Five domains in enforcement order: Registry & Provenance, Schema Integrity, Grants & Trust Tiers, Runtime Output Handling, Change & Operations. 22 of 27 checks are mechanically verifiable from registry artifacts; 5 require runtime sampling.
- Reference sweep: 10 servers / 140 tools = 3 auditor-days at our checklist pace of roughly 2 minutes per mechanical check and 30 minutes per runtime sample.
- The checklist pairs with the five-layer prevention architecture (which prevents poisoning) and the runtime defense gateway (which blocks it at inference). The audit verifies all three are actually configured as claimed — configuration drift is the finding we hit most.
- Audit scoring is binary per check: pass, fail, or not-applicable-with-justification. "Partially compliant" is a fail with a remediation deadline, because partial controls are how drift hides.
"An audit that cannot be re-run by a different auditor and reach the same findings is not an audit. It is an opinion with a spreadsheet."
Why a Fixed Instrument Beats a Smart Reviewer
The failure pattern we kept seeing — in our own first pass and in every post-incident review we've studied — is auditor-driven variance. A sharp reviewer finds sophisticated poisoning patterns in server A and misses that server B's schema hash was never pinned at all. The sophisticated finding feels like value; the missing baseline is what actually causes incidents. A fixed instrument inverts the emphasis: the 22 mechanical checks guarantee the baseline is never skipped, and the auditor's judgment is reserved for the 5 runtime samples where it changes the outcome.
The second reason is drift. MCP estates change weekly — new servers, schema updates, tier changes. A point-in-time review decays the day it's delivered. A 27-point instrument with a 3-day sweep cost can be re-run monthly or on-demand after any registry change, which converts the audit from an event into a control. That distinction is the difference between compliance theater and the change-management domain (checks 23–27) that closes this checklist.
The 27-Point Checklist
Scoring: each check is PASS, FAIL, or N/A (with written justification). Any FAIL in Domains 1–3 is release-blocking; Domain 4–5 fails require a remediation deadline inside 30 days.
Domain 1 — Registry & Provenance (checks 1–5)
| # | Check | Evidence artifact | |---|---|---| | 1 | Every MCP server in every client config resolves to the managed registry — zero local-only server definitions | Diff of client configs vs registry export | | 2 | Every server has a named owner and provenance class (first-party / vetted-third-party) | Registry entries | | 3 | Server binaries/images are pinned by digest, not tag | Registry + artifact store digest match | | 4 | No server is registered with default or vendor-default credentials | Credential scan of server configs | | 5 | Deprecated-transport servers (HTTP+SSE) are flagged with a migration owner | Registry transport field |Domain 2 — Schema Integrity (checks 6–10)
| # | Check | Evidence artifact | |---|---|---| | 6 | Every tool's schema hash pinned at registration (name + description + inputSchema) | Hash ledger | | 7 | Client verifies pins at session init and refuses drift | Client config + one live drift test | | 8 | Tool descriptions pass instruction-phrase lint (no "include the…", "ignore previous…") | Lint report at last registry change | | 9 | No tool name collisions across servers sharing a grant surface | Collision report | | 10 | inputSchema is valid JSON Schema (types, required fields, no permissive `*`) | Schema validator run |Domain 3 — Grants & Trust Tiers (checks 11–15)
| # | Check | Evidence artifact | |---|---|---| | 11 | Every agent declares an explicit tool-grant list; zero agents bind "all tools from server" | Grant manifests | | 12 | No untrusted-tier tool binds to any agent holding credentials above the defined sensitivity class | Tier×grant matrix | | 13 | Grant lists are reviewed artifacts (approver recorded, date within policy window) | Review log | | 14 | Write-capable tools are grant-separated from read-only triage agents | Grant manifests | | 15 | Tier assignments match documented provenance — no inflation (everything isn't "vetted") | Tier distribution vs review depth |Domain 4 — Runtime Output Handling (checks 16–21, sampled)
| # | Check | Evidence artifact | |---|---|---| | 16 | Untrusted-tier tool output is wrapped/marked as data before context injection | Runtime sample: 5 calls per tier | | 17 | Tool output containing instruction-like phrases is flagged, not silently executed | Canary: poisoned-output test vector | | 18 | Error responses from tools do not leak credentials or filesystem paths into context | Sampled error-call review | | 19 | Sandboxed execution caps (timeout, memory, egress) enforced where the defense gateway is deployed | Sandbox config + one violation test | | 20 | Multi-hop chains: output of one tool is not auto-executed as instruction by the next agent | Sampled 2-hop trace | | 21 | Session logs retain enough context to reconstruct any given tool call's provenance | Log completeness sample |Domain 5 — Change & Operations (checks 22–27)
| # | Check | Evidence artifact | |---|---|---| | 22 | All registry mutations go through the review gate — zero direct production edits in the audit window | Gate audit trail vs registry history | | 23 | Schema updates triggered re-approval (pin re-hash + human sign-off), zero silent drift | Re-approval log | | 24 | Registry state is version-controlled; rollback procedure tested | Repo history + one rollback drill | | 25 | Alerts fire on: unregistered server load attempt, schema drift, tier-inflated grant request | Alert system test records | | 26 | Audit itself is re-run on schedule and after every high-risk registry change | Audit calendar + last two reports | | 27 | Findings from the previous audit are closed or carry a live deadline — no silent refails | Findings tracker |Audit Coverage Estimator
Price the sweep before you promise it. Mechanical checks run at roughly 2 minutes per tool; runtime samples cost about 30 minutes per sampled server (5 calls per tier plus one canary). The estimator covers the reference sweep and your steady-state re-run cadence:
Worked Example: The Reference Estate Sweep
Run the defaults as a concrete plan: 10 servers × 14 tools = 140 tools. Mechanical checks: Domain 1–3 and Domain 5 artifacts resolve at the registry level, so 2 minutes per tool covers hash verification, lint status, grant membership, and collision checks batched across the estate — 4.7 hours. Runtime sampling: 3 of 10 servers (highest tier-mix, one first-party, one vetted-third-party) × 30 minutes = 1.5 hours including the poisoned-output canary. Total: 6.2 hours for a re-run sweep — cheap enough to run monthly without a budget fight.
The first full sweep took us 3 auditor-days, and the delta is the honest part most checklist vendors omit: first-time audits include evidence pipeline construction (extracting client configs, building the hash ledger, writing the drift test). Budget 3× for the first run, then amortize. The third anchor, as always, is a confession: our first sweep scored the estate 24/27, and we almost reported 26 — two of the passing checks were marked PASS on the strength of "the config says so" without running the live drift test. Config-claimed controls are claims, not evidence. Both got re-tested, one failed, and the instrument gained its most important rule: every check's evidence must be an artifact, never a statement. That rule is now baked into the evidence column above.
What the Audit Is Not
Three boundaries keep the instrument honest. First, it is not a prevention architecture — a perfect 27/27 estate can still be poisoned by a first-party tool whose description was malicious before your first review; that residual is what the runtime defense gateway exists for. Second, it is not a substitute for the prevention layers; checks 6–15 verify the five layers are configured as claimed, and configuration drift between "documented security" and "running security" was our most frequent finding class. Third, it is not a compliance framework mapping — the 27 checks map cleanly onto SOC 2 access-control and change-management evidence requests, but the instrument optimizes for finding real MCP risk, not for filling templates. Teams that need the mapping can derive it in an afternoon; teams that design the audit for the template will audit the template.
The Decision Matrix
| Your situation | Audit posture | Rationale |
|---|---|---|
| Production agents with credential access | Full 27-point, monthly re-run + on-change | Credential estates are the exfiltration target; drift cost is highest |
| Production agents, no sensitive credentials | Full 27-point, quarterly re-run | Baseline still mandatory; drift cadence can relax |
| Pre-production / evaluation estate | Domains 1–3 only (15 checks) | Schema and registry integrity are cheap and catch the worst pre-launch mistakes |
| After any poisoning incident (yours or public) | Immediate re-run + canary intensification (check 17 on every server) | Incidents change the threat surface; the instrument is your inventory |
| Multi-team shared platform | Full 27-point + Domain 5 evidence per team | Ownership boundaries are where silent refails hide |
Zero-Glue: The Checklist as a Boundary Contract
A checklist is the Zero-Glue Theorem applied to governance: eliminating unstable middleware — in this case, auditor memory and reviewer goodwill — by enforcing a native, machine-checkable boundary between claimed and actual security posture. Each of the 27 checks replaces a conversation ("I'm pretty sure we pinned those") with an artifact (a hash ledger entry). When the artifact and the claim diverge, the finding writes itself, no interpretation required. Governance that depends on someone's diligence is glue; governance that depends on artifacts is a boundary.
Uncompromising Summary
MCP security audits drift toward failure in two ways: the smart-reviewer model that skips baselines to chase sophisticated findings, and the point-in-time report that decays before it's filed. The 27-point instrument fixes both by being fixed: 22 mechanical registry checks that never get skipped, 5 runtime samples that use judgment where judgment pays, binary scoring that treats "partial" as fail, and a sweep cost — roughly one auditor-day on a 140-tool estate at steady state — cheap enough to re-run on every meaningful registry change. Run it with the prevention architecture beneath it and the runtime gateway behind it, and the three together form a loop: prevention configures, the audit verifies, the gateway catches. Start with the evidence rule — artifacts, never statements — because that single discipline is what turned our own 26/27 fantasy into an honest 24 and then into a real 27.
Enterprise Architectural FAQ
Audit the data layer, not just the schema
Most findings in a 27-point MCP audit land on unverified inputs rather than the protocol itself. Our Clay playbook covers verifying and enriching the records and entities your agents read before they act.
Get the Clay Agent-Data Playbook →Download this guide’s assets
Get the 27-point audit CSV + tracker from this guide. Instant download — no email required.
Download the bundle →Prefer it by email? Subscribe for the full library →
How is a 27-point audit different from running the prevention architecture's own checks?
The prevention architecture enforces controls at runtime (allowlists, pin verification, grant enforcement); the audit verifies the controls exist, are configured as documented, and haven't drifted — including on paths the runtime never exercises, like rollback procedure (check 24) and alert firing (check 25). They answer different questions: "is it blocking?" versus "would it still block if we hadn't looked for a month?" The drift between those two answers is where incidents incubate.
Why are only 5 of 27 checks runtime-sampled instead of full-coverage?
Runtime sampling is the expensive edge: each sampled server costs ~30 minutes of deliberate canary and trace work, and full runtime coverage of a 140-tool estate would price the sweep out of monthly feasibility — which historically kills re-auditing entirely. The sample targets the highest-mix servers (both tiers, one first-party) because tier interactions are where output-handling failures concentrate. If a sampled server fails a Domain 4 check, protocol is to widen sampling to its whole tier before re-scoring.
What infrastructure handles evidence collection for the mechanical checks?
Four artifacts, all generated from the registry: a client-config diff (catches unregistered servers), the hash ledger (pin verification), the grant×tier matrix (checks 11–15), and the gate audit trail (checks 22–23). Teams that already run the prevention architecture generate three of the four as a byproduct — which is exactly why the audit is priced at 2 minutes per tool. The only purpose-built tooling is the drift canary for check 7, a scripted session-init against a deliberately mutated schema.
How do you keep the audit itself from decaying into checkbox theater?
Three mechanisms are built into the instrument: binary scoring with N/A-requires-justification (no partial credit to hide behind), the findings-tracker check (27) that audits the audit's own history, and the evidence-artifact rule from our confession anchor — every PASS must cite a machine-generated artifact, and a second auditor must be able to reproduce it. If your estate ever scores 27/27 twice using only config-file evidence, treat the second 27 as a finding.
Related Cluster Intelligence
- Voiceflow vs Bland.ai: Voice Agent Comparison →
- ElevenLabs Pricing 2026: Plans, Credits, Alternatives →
- The 10-Year Paradigm Shift: Embracing Model Context Protocol (MCP) →
- Clay Data Credit Optimization Tactics →
- Smartlead vs Instantly: Cold Email Cost Per Reply →
- Smartlead Deliverability Repair Protocol →
/links/[tool]). If you deploy through them, we may earn an affiliate commission at $0 added cost to you. All performance figures in this article come from internal testing under the configurations documented here; results vary by workload, scale, and environment. We disclose limitations and failure modes wherever they exist. Authored by Alex, Principal AI Infrastructure Architect at Wenboom. See our Terms of Service for the full disclaimer.