MCP security audit that checks your server’s OAuth, tokens and tools in ten days

What the MCP security audit checks

Authorization and tokens

• Protected resource metadata, and every token checked for your server’s audience, so a token issued for another API gets a 401.
• No token passthrough, meaning the server never forwards a token it received from the client to another API.
• PKCE with S256 (proof that the app finishing a sign-in is the one that started it), exact redirect URI matching, an iss value naming the authorization server in every response, and a consent screen that names the client.
• Client registration through Client ID Metadata Documents, with Dynamic Client Registration only where a client still needs it.

Scopes, tools and confused deputies

The scopes each tool needs against the scopes the server holds, step-up challenges for tools that need more, and every path where the server acts with its own authority on a request it shouldn’t trust.

State handles, request state and retries

Handles that are random, short-lived and bound to the user ID in the verified token, so a guessed or stolen handle gets nothing. The security best practices say a handle must never be treated as authentication. requestState protected against tampering and replay, write tools that run once when a client retries after a dropped stream, and per-user results marked "private" so a shared cache can’t serve them to someone else.

Prompt injection through tools

Tool descriptions, and tool results that carry text your customers or their customers wrote. We plant instructions in those fields and record which ones reach an action that changes data or money.

Inputs and SSRF

Validation of tool arguments against what your API enforces, and every fetch your server or authorization server makes to a URL someone else chose, such as a Client ID Metadata Document. SSRF (server-side request forgery) is a request like that aimed at your internal network.

Logging, limits and dependencies

An audit record for every tool call (user, client, scopes), rate limits per user and per tool, how secrets are stored, and known vulnerabilities in your dependencies.

Tool-use evals

A suite that sends your real tasks and current tool definitions to the OpenAI and Anthropic models behind ChatGPT and Claude, and checks which tool each picks and with which arguments. It runs in your CI. ChatGPT and Claude add their own prompts and confirmations, so the verdict lists what an API test can’t see.

Each check maps to a section of the specification in our MCP server security guide.