MCP Pentesting Guide and Checklist

Updated November 2026 6 min read

Quick answer. Test an MCP server as both a web API and an AI attack surface: recon, auth, tool poisoning, transport and supply chain. Treat it as reachable directly over its transport, not only through a cooperative model.

Watch: MCP Pentesting Guide and Checklist 1:37

Video transcript

To pentest an MCP server, treat it as both a web API and an AI attack surface.

An MCP server's tools are server-side actions. An attacker with a low-privilege account can often call them directly over JSON-RPC and skip the model. So every tool handler must enforce authorization.

Work in five phases: recon of tools, resources and prompts, then auth, tool poisoning, transport, and finally supply chain.

Most real findings live in auth. Check PKCE and resource indicators, validate token audience with no passthrough, look for confused deputy proxies, and confirm ownership checks on destructive tools, not just reads.

Treat tool descriptions as untrusted, since hidden instructions can steer the agent. Test for rug pulls, cross-server shadowing, and injection through resources, as Invariant Labs showed with a malicious GitHub issue.

On transport, test Origin validation and SSRF, and check local tooling. The mcp-remote proxy flaw scored CVSS 9.6, allowing command execution via a crafted authorization endpoint.

For crypto teams, a tool with signing or trading access that a poisoned description can steer is a direct path to funds. Give it the scrutiny of a keeper or trading backend.

Guardian's pentests use two independent teams and report only human-verified findings. Read the full checklist, or talk to Guardian at guardian.security.

The Model Context Protocol (MCP) is how AI agents reach tools and data, through servers that expose tools, resources and prompts.

When those servers can send email, touch cloud accounts or move crypto, they become a high-value attack surface. This MCP pentesting checklist is for the people who secure them.

The MCP attack surface

MCP has three roles: the host (the LLM application), clients (one connector per server), and servers (which expose tools, resources and prompts).

The 2026-07-28 revision made the protocol stateless: every request carries its own protocol version and capabilities.

The spec states its security principles plainly:

Users must consent to and control data access and operations.
There should be a human in the loop able to deny tool invocations.
Tool descriptions and annotations should be considered untrusted unless they come from a trusted server.

That last point is the heart of MCP security. Tool definitions are data the model treats as instructions.

And a server’s tools are server-side actions. If the endpoint is exposed, an attacker with a low-privilege account can often call them directly with JSON-RPC and skip the model.

So authorization belongs in every tool handler, not in the model or the client.

Recon and discovery

Inventory every endpoint. Some look like generic HTTP services. Record each one’s transport.
Read server/discover. Servers must implement it in the 2026-07-28 revision. Check what it advertises: protocol versions, capabilities and instructions.
Enumerate capabilities. List tools, resources and prompts. Note what each tool does, the IDs it accepts, and whether it is destructive.
Compare advertised vs callable. The tool list is not an authorization boundary. Every handler, listed or not, must enforce its own authorization.
Tooling. The MCP Inspector lists every exposed tool with no model in the loop; the MCP Attack Surface Detector, a Burp extension, turns MCP endpoints into Burp targets.

HackTricks, the free wiki created by Guardian’s offchain lead Carlos Polop, documents a reported case.

A privileged debug tool omitted from the list was still callable with an ordinary key, with no role check of its own.

Authentication and authorization

Authorization is optional in MCP. When an HTTP transport uses it, the spec is specific, and most real findings live here.

PKCE and Resource Indicators. Clients must use PKCE with S256 (when technically capable) and Resource Indicators (RFC 8707) naming the intended server.
Token audience. Servers must validate that a token was issued for them. Accepting a wrong-audience token, or passing it downstream, is explicitly forbidden.
Confused deputy. A proxy with a static client ID and dynamic client registration can be abused, via the third party’s consent cookie, to send an attacker an authorization code.
Per-client consent. The spec requires such proxies to get consent for each client before forwarding. Confirm it cannot be skipped.
Object-level authorization (BOLA). Check ownership in every tool that takes an object ID, including delete, archive and export, not just reads.

Tool poisoning and prompt injection

This is the MCP-specific class, and the one a generic web pentest is most likely to miss.

Poisoned descriptions. Instructions hidden in a tool’s description or schema reach the model, not the user, and can steer it to exfiltrate files or credentials.
Rug pulls. A server can change a description after approval. Test whether the client re-prompts, and whether definitions are pinned.
Tool shadowing. A malicious server can alter how the agent uses a trusted server’s tools, without its own tool ever being called.
The instructions field. A server’s free-text instructions sit outside per-tool pinning. Review them as untrusted.
Resources and prompts. Content a tool returns, or a resource the agent reads, can carry injected instructions.

Invariant Labs documented tool poisoning in April 2025: a benign-looking tool whose description told the model to read sensitive files and pass them in a side parameter.

In May 2025 they showed a malicious GitHub issue steering an agent with the official GitHub MCP server to pull private-repository data into a public pull request.

Transport, tooling and supply chain

Origin and binding. Streamable HTTP servers must validate Origin against DNS rebinding. Locally they should bind to localhost, not 0.0.0.0, and authenticate connections.
SSRF. In OAuth metadata discovery, a malicious server can point a client at internal URLs such as 169.254.169.254. Clients should enforce HTTPS and block private and link-local ranges.
OAuth URL handling. Clients must reject javascript:, data: and file: authorization URLs, and must not open URLs through a shell.
State handles. Servers should bind each handle to the authenticated user and generate it with a secure random source. They must never treat possession as authentication.
Developer tooling. Dev panels should be loopback-only, authenticated, and not reverse-proxied to the network.

The mcp-remote proxy (CVE-2025-6514, CVSS 9.6) allowed OS command execution via a crafted authorization endpoint in versions 0.0.5 to 0.1.15, fixed in 0.1.16.

The MCP Inspector before 0.14.1 (CVE-2025-49596, CVSS 9.4) let unauthenticated requests from a web page reach the local proxy and execute commands.

For local servers, the MCP project’s Local Server Security guide says to treat a third-party server as untrusted code with exactly the privileges you hand it.

A review checks provenance, sandboxing, per-server credentials, filesystem limits, egress control, and what a one-click install would run.

A malicious startup command in a client configuration is a documented path to code execution.

The MCP pentesting checklist

Mapped to the OWASP MCP Top 10 (currently in beta) where it fits.

Tools, resources and prompts are enumerated, and callable tools are compared against the advertised list.
Every tool enforces server-side authorization and ownership checks, including destructive operations (MCP07, MCP02).
Tokens are validated for the correct audience, with no wrong-audience acceptance or passthrough (MCP01).
Descriptions, schemas and the instructions field are reviewed as untrusted, injectable content (MCP03, MCP06).
The client re-prompts when a tool definition changes, and definitions are pinned (MCP03).
Cross-server shadowing and context over-sharing are tested with multiple servers (MCP03, MCP10).
Every MCP server is inventoried and approved; none runs default credentials or permissive configurations (MCP09).
Streamable HTTP validates Origin, binds to localhost locally, and authenticates connections.
Discovery URLs and redirects are validated against SSRF, including private and cloud-metadata ranges.
Authorization URL schemes are allowlisted and never opened through a shell (MCP05).
State handles are bound to the user and non-deterministic; possession is not authentication.
Dependencies and packages are reviewed, local servers isolated, command-execution paths closed (MCP04, MCP05).
Audit logs record tool invocations for detection and incident response (MCP08).

Where Guardian’s pentests fit

Some MCP servers front a wallet, an exchange account or onchain tooling. There, a signing or trading tool that a poisoned description or injected resource can steer is a direct path to funds.

Such a server belongs with keepers, relayers and trading backends, and deserves the same scrutiny rather than a trust-by-default install. See offchain pentest findings in DeFi.

Underneath, an MCP server is an API that fires actions. Guardian’s API pentest covers key scoping, per-object authorization, abuse resistance, authentication and automation triggers.

The offchain automation pentest covers what bots and keepers do when their inputs are hostile.

Every engagement runs two independent teams, and only human-verified findings reach the client.

For continuous coverage, Managed Security runs Helix, Guardian’s AI security agent pipeline, across contracts, backend services, infrastructure and web apps, with 24/7 monitoring and response.

Frequently Asked Questions

How do you pentest an MCP server?

Enumerate its tools, resources and prompts. Then check authorization and token audience on every tool, treat descriptions as untrusted instructions, test Origin validation and SSRF, and review the supply chain.

What is tool poisoning in MCP?

It hides instructions in a tool’s description or schema that the model reads but the user does not, steering the agent to exfiltrate files or misuse other tools. A server can also change a description after approval: a rug pull.

Does the MCP specification require authentication?

Authorization is optional. When an HTTP implementation supports it, the spec requires PKCE, RFC 8707 Resource Indicators and strict audience validation. Servers must not accept tokens not issued for them, or pass tokens through.

Sources

Pentest the APIs your agents can reach

Guardian’s API and offchain automation pentests cover the endpoints and bots an agent can drive, and Managed Security keeps the full stack under continuous testing.

Talk to Guardian Explore Managed Security