MCP Security Audits
Know what a reviewer will find before they find it
Most MCP servers are written in a week by a product engineer, work well in a demo, and then stall for months in a customer's vendor review. An audit tells you exactly why yours will stall, and what to change, before that happens.
What we do
We assess an MCP server, existing or planned, against the questions an enterprise security reviewer will ask before they let their staff connect an agent to your product:
- Authorization. Whether the server implements the MCP authorization specification as written: OAuth 2.1 with PKCE, protected resource metadata discovery, authorization server metadata, and resource indicators so tokens are bound to your server and cannot be replayed elsewhere. Whether tokens issued for another audience are accepted (they must not be).
- Token handling. Where tokens live, how long they live, whether the server ever forwards a client's token to a downstream API (the token passthrough anti-pattern), and how refresh works across long agent sessions.
- Scoping. Whether every tool call resolves to a specific human and tenant, and whether that identity is enforced by the server against your data layer rather than trusted from the agent.
- Tool design. Tool names and descriptions as an attack surface (prompt injection through descriptions, over-broad tools, destructive actions without confirmation), input validation, output size and content controls.
- Audit and observability. Whether a customer's security team could reconstruct what an agent did on behalf of which user, and export that to their SIEM.
- Transport and deployment. Streamable HTTP configuration, origin validation, session handling, secrets management, rate limiting, network exposure.
- Directory readiness. The concrete requirements of the connector directories you intend to list in, and where you fall short.
You receive a findings report ranked into three bands (blocks a security review, raises a question you will need to answer, good practice), a remediation plan with effort estimates your own engineers can execute, a one-page summary in the language your customer's security questionnaire uses, and a walkthrough with your engineering and security leads.
Who this is for
- B2B SaaS teams who have a working MCP server and their first enterprise customer asking questions
- Teams about to build one who want the security design settled before the code exists
- Platform or security leads who inherited an internal MCP server and need an independent read
How we work with you
The audit is billed hourly, time and materials, and a typical one runs about two weeks: kickoff and access on day one, review and testing through the first week and a half, draft findings shared for factual corrections, then the final report and a working session with your engineers and your security lead. Scope is agreed in an initial conversation, and if your server is small the audit is short.
What it is not
It is not a penetration test of your whole product, and it is not a compliance certification; we do not issue attestations. It is also not a build: code changes are their own engagement, and many clients have us carry the fixes through with the same engineer who found them.
Next step
Send us a note about your server and the review it is facing, and we will tell you what an audit would cover. Contact us.