How to Audit an MCP Server: A Step-by-Step Security Review

The Model Context Protocol (MCP) is the standard way to connect AI assistants and agents to tools and data. Its specification, version 2026-07-28, includes an authorization chapter and a list of security best practices with concrete attacks and mitigations. OWASP adds a separate MCP Top 10, still a beta in November 2026. Together they give you something to audit against. What follows is the order we recommend, and the evidence worth keeping at each step.

Scope first: servers you use and servers you build

Most companies are on both sides. Developers install MCP servers into their coding assistants and desktop clients; product teams may publish a server so customers' assistants can use the product. The questions overlap, but the evidence differs:

	Servers you use	Servers you build or publish
Main risk	A malicious or over-privileged server reaches company data through an employee's assistant	Your server leaks data across customers or accepts tokens it should reject
Evidence	Inventory, installation source, pinned version, granted scopes, client settings	Code review, authorization tests, logging, vulnerability handling
Owner	IT or security, with each team that installs servers	The engineering team that runs the server

Step 1: Build the inventory, including shadow servers

You cannot audit what you cannot see. OWASP lists unapproved servers as their own risk (MCP09:2025 Shadow MCP Servers). Ask each team, and check client configuration files on managed devices, for every MCP server in use. For each one record:

Name, publisher and where it was installed from (official registry, package manager, a GitHub repository, a vendor).
Transport: local (stdio, running on the user's machine) or remote (HTTP).
The credentials it holds or receives: API keys in environment variables, OAuth tokens and their scopes.
The tools it exposes and what each one really does: read, write, delete, send, pay, run code.
Which agents and users have it enabled.

A useful test at this step: does any single agent combine untrusted input (it reads email, web pages or tickets), access to private data and a way to send data out? That combination is the classic exfiltration path for prompt injection, and it should be flagged in the inventory, not discovered in an incident.

Step 2: Check the supply chain

Install from sources you can verify. In the official MCP Registry, a publisher has to prove control of the namespace a server is listed under; a lookalike name in a package manager proves nothing.
Pin versions. An automatic update can change code and tool descriptions without anyone noticing (MCP04:2025 Software Supply Chain Attacks and Dependency Tampering).
Prefer servers with a security contact, a changelog and a way to report vulnerabilities.
For servers you build: keep dependencies pinned, scanned and reviewed like any production service.

Step 3: Review the tool descriptions

Tool names, descriptions and input schemas are sent to the model and read as instructions. A server can hide commands in them, or change them after you approved it (MCP03:2025 Tool Poisoning). For each server:

Read every tool description in full, including long or unusual text in parameter descriptions.
Record a fingerprint of the tool list (for example a hash of the tools/list response) when you approve the server, and compare it on each review or update. A changed fingerprint means a new review.
Check whether tool annotations match reality: a tool declared read-only should not be able to change anything. Annotations are hints from the server, not guarantees, so verify them for servers you do not control.
Remove tools the agent does not need. Fewer tools means fewer ways to misuse them.

Step 4: Test authorization and tokens

For remote servers that use authorization, the specification is precise. These are checks you can test, not opinions:

Requirement	What to check	Source
Protected Resource Metadata	The server publishes OAuth 2.0 Protected Resource Metadata telling clients which authorization server to use	MCP Authorization; RFC 9728
Audience-bound tokens	Clients request tokens for this specific server (resource parameter), and the server rejects tokens issued for any other audience	MCP Authorization; RFC 8707
No token passthrough	The server never forwards the client's token to another API; it uses its own credentials for upstream calls	MCP Authorization; Security Best Practices: Token Passthrough
Tokens not in URLs	Access tokens are sent in the Authorization header, never in the query string	MCP Authorization
Minimal scopes	Initial scopes cover low-risk read operations only; more scope is requested when a privileged tool is first used (step-up)	Security Best Practices: Scope Minimization
Issuer check	Clients verify that the authorization response comes from the authorization server they started with (mix-up protection)	MCP Authorization; RFC 9207
Consent for proxies	A server that proxies a third-party API gets per-client consent and validates redirect addresses	Security Best Practices: Confused Deputy Problem

Then test the negative cases: an expired token, a token for a different server, a token with too little scope. Each must be refused (401 for invalid or expired tokens, 403 for insufficient scope). Long-lived tokens, secrets in logs and tokens stored in plain text fall under MCP01:2025 Token Mismanagement and Secret Exposure.

Step 5: Contain local servers

A local server runs as a program on the user's machine, with that user's rights. The specification says local (stdio) servers should take credentials from the environment rather than use the OAuth flow, and it describes how a one-click configuration can run an arbitrary command. Check that:

Clients show the exact command before a new local server runs, and users are told not to approve commands they do not understand.
Local servers run with limited file system and network access (a container or sandbox where possible).
Credentials given to local servers are scoped to the task and stored outside the code.
No local server can be reached from the network unless that is intended.

Command injection in server code is MCP05:2025 Command Injection and Execution; test any tool that builds shell commands or file paths from model input.

Step 6: Block server-side request forgery

During sign-in, a client fetches URLs that a server gives it. A malicious server can point those at internal addresses or a cloud metadata endpoint. The specification's mitigations: require HTTPS, block private, loopback and link-local ranges, and validate redirects. Clients must also reject dangerous URL schemes (javascript:, data:, file:) for authorization URLs and must not open them through a shell. The same applies to any tool that fetches a URL the model chose.

Step 7: Assess prompt injection exposure

There is no complete fix for prompt injection, so the audit looks at impact. OWASP lists it twice: MCP06:2025 Prompt Injection via Contextual Payloads and MCP10:2025 Context Injection and Over-Sharing. Check that:

Agents that read untrusted content cannot also send data to arbitrary destinations: outbound tools have allowlisted domains or recipients.
Actions that send data out, delete, pay or change records need a human confirmation.
Tool results are treated as data; nothing in a result can change which tools are allowed.
Context shared with a server is limited to what the task needs, and one user's data cannot reach another user's session.

Step 8: Logging, rate limits and response

Every tool call is logged with the agent, user, server, tool and result, without storing sensitive arguments you do not need (MCP08:2025 Lack of Audit and Telemetry).
Servers and agents are rate-limited, so a runaway loop cannot run up costs or hammer an API.
There is a tested way to revoke an agent's tokens and disable a server at once.
MCP incidents are covered by your incident process: see incident response for AI agents.

Score it and write it up

Give each check a severity and a result (pass, partial, fail, not applicable), then group findings by area. Report the worst findings first: a single failed audience check or an agent with the exfiltration combination from step 1 matters more than ten missing log fields. Each finding needs an owner and a date, and the audit should be repeated when a server is added, its tool fingerprint changes, or at least once a year.

Audit, not scan. These checks need someone to look at configuration, code and behaviour. Automated scanners can help with parts of steps 2 and 3, but they cannot tell whether a scope is justified or whether an agent should be allowed to send email.

A worked example: our own MCP server

We ran these steps against the ClevSec MCP server. Results that are public on our Trust Center: every tool is declared read-only and computes an answer without changing anything; there is no language model on the server, so a prompt cannot change a result; inputs are validated against a JSON Schema and never logged; calls are limited to 300 per minute per IP address; outbound requests can reach public addresses only; and the Pro endpoint uses OAuth 2.1 with one-hour access tokens and a consent page that cannot be framed. The free endpoint needs no token at all, which removes most of step 4 for it.

How the audit maps to the regulations

Regulation	Where the audit helps
NIS2	Supply chain security (Art. 21(2)(d)), security in acquisition, development and maintenance (Art. 21(2)(e)), and access control and asset management (Art. 21(2)(i)).
DORA	MCP servers are ICT assets: identify and classify them (Art. 8) and limit access to what approved functions need (Art. 9(4)(c)). A provider-run server is an ICT third-party service.
GDPR	Security of processing, including regular testing and evaluation of measures (Art. 32(1)(d)).
Cyber Resilience Act	If you publish an MCP server as a product, the Annex I essential requirements and vulnerability handling apply; see CRA requirements.

Run the audit with a ready workbook. The MCP Security Audit Kit ($29) has 57 checks in 11 areas with a weighted score, a server and tool inventory with automatic flags and a tool-list fingerprint, a threat model and an audit report template. The Agent Security Bundle ($79) adds the AI Agent Governance Pack and the Vendor Security Pack.