Every MCP server that sells into an enterprise eventually meets the same request: "Send us your security documentation." What arrives is usually a link to the product docs and an offer to get on a call. That answer costs weeks, because the reviewer cannot approve a call; they can only approve a record.
The record is the evidence pack. It is a small, versioned set of documents that answers the questions a vendor security review will ask about an MCP server before the reviewer has to ask them. This is what belongs in it.
What the pack is and is not
The pack is not a certification, and it does not claim to be one. It is not a penetration test report, though it can cite one. It is not marketing. It is the same material an engineer would want if they had to take over the server on Monday: what it is, how identity flows through it, what could go wrong, what stops each thing, and how that was checked.
Write it for one reader: a security analyst with forty minutes, a questionnaire to fill in, and no context on your product. If a section cannot be read cold, it is not finished.
1. Architecture and data-flow diagram
One page. Show the agent host, the MCP client, your MCP server, the authorization server, your product API, and every downstream system a tool can reach. On each arrow, name the credential that authorizes it and the data that crosses it.
This single diagram removes most follow-up questions, because almost every questionnaire item is a question about one arrow: where does customer data go, who holds tokens, which components are in which cloud account, what leaves your boundary.
State the deployment topology plainly: which cloud, which regions, whether the server is multi-tenant or single-tenant, and what is stored versus passed through. If the server stores nothing but logs, say so; that is a strong answer and it is often true.
2. The authorization design note
Two to three pages describing how a call is authorized, written against the specification rather than in general terms. A reviewer who knows OAuth will scan it for named mechanisms:
- The server is an OAuth 2.1 protected resource, and it publishes protected resource metadata (RFC 9728) pointing at its authorization servers.
- Clients run authorization code flow with PKCE (RFC 7636) and request the server as the audience using resource indicators (RFC 8707).
- The server validates every access token: signature, issuer, expiry, and audience. Tokens not issued for this server are rejected with a
401and aWWW-Authenticatechallenge. - Tokens are not passed through to downstream systems. Where a downstream call must carry the user, the server performs token exchange (RFC 8693) or uses a service credential with the user identity carried explicitly.
- Scopes are enumerated, one line each, with the tools each scope permits.
Name the MCP specification revision you implement, and date it. "We follow the MCP spec" ages badly; "we implement the 2025-06-18 authorization specification, with the changes in the following revision tracked in our backlog" tells the reviewer you know the surface is moving.
3. The threat model
Half of a threat model is a list of things you decided not to defend against, and reviewers respect that more than a clean sheet. Cover, at minimum, the threats specific to this class of server:
- Confused deputy. The model is asked to act on another tenant's data. Control: identity is bound from the token in the handler; no tool accepts a user or tenant argument.
- Token misuse. A token issued for another resource is presented to this server, or a token for this server is replayed elsewhere. Control: audience validation, short lifetimes, refresh rotation.
- Prompt injection through tool output. Third-party content returned by a read tool contains instructions. Control: structured outputs, bounded size, read and write tools separated, destructive tools gated behind a confirmation the model cannot set.
- Over-broad tools. A tool can do more than the human it acts for. Control: tools derived from product permissions, enforced at the data layer.
- Runaway loops. Per-user and per-tool rate limits, with the limit values stated.
For each, write the threat, the control, and the residual risk you are accepting. Residual risk with a named owner reads as maturity. An empty residual-risk column reads as an incomplete analysis.
4. The control matrix
The matrix is the piece that saves the reviewer the most time: a table mapping each control to where it is implemented and how it is evidenced. Three columns are enough - control, implementation, evidence - plus a fourth for the questionnaire section it answers if you know which questionnaire you are facing.
Most enterprise questionnaires are variations of the same instrument (CAIQ and SIG are the common ones), and their sections repeat: identity and access management, logging and monitoring, encryption, data location, change management, incident response, subprocessors. Build the matrix once against those headings and the fourth column fills itself in for the next customer.
Two rules keep the matrix honest. Every row's evidence must be a thing that exists - a file, a dashboard, a test output, a configuration - not a sentence. And no row may claim a certification, an audit, or a partnership you do not hold. A single unsupportable row makes a reviewer re-check every other one.
5. Audit sample and retention
Include three or four real audit events, redacted, from a running environment: a successful tool call, a scope denial, a cross-tenant rejection, and an error. Include the field list, the retention period, and how the customer can receive the stream in their own SIEM.
Reviewers ask for this because it is the difference between a server that logs and a server that can support an incident investigation. The schema itself is worth designing before the first tool; we have written separately about what those events should contain.
6. The test record
Claims in the first five sections are assertions until something checks them. The test record is a short document listing the adversarial checks run before release, the date, the build tested, and the result of each: cross-tenant attempts through every tool, tokens with a wrong audience, expired and replayed tokens, injected instructions in every output field, oversized inputs, call floods.
A reviewer does not need your test harness. They need to see that the list exists, that it covers their concerns, and that it was run against the version they are being asked to approve.
7. Operational facts
Finish with the short answers that otherwise generate a week of email: security contact address, vulnerability disclosure route, incident notification commitment, subprocessor list, data residency, backup and deletion behavior, and how customers are told about breaking changes to tools or scopes.
Keeping the pack true
Version the pack and date every page. Re-issue it when the MCP specification revision you implement changes, when you add a tool that writes, when a scope changes meaning, or when the deployment topology moves. A pack that describes last quarter's server is worse than no pack, because the reviewer will find the discrepancy and then verify everything by interview.
The work is a few days if the server was designed with identity flowing from the token to the data layer to the audit log. It is considerably longer if the pack has to document a server that cannot answer those questions yet - which is the point. Writing the pack tells you what to fix, and it is cheaper to learn that from your own document than from a customer's reviewer.
We produce an evidence pack as a standard deliverable on every MCP server build, and assembling one against an existing server is most of what an MCP security audit does.