MCP server security is the practice of finding and closing the ways a Model Context Protocol server can be abused, before it becomes the weak point in an AI agent. The Model Context Protocol, introduced by Anthropic in late 2024, is now the common way to connect a model to tools, data and services, and each server you connect gives the model new actions it can take. That is the point of MCP, and it is also the risk: a tool that reads email or queries a database turns a prompt injection into a real action, and a malicious or compromised server can steer the model through tools it was never meant to touch. This guide explains where the risk sits and how we test an MCP server, mapped to the protocol’s own security guidance and the OWASP MCP Top 10.
It is written for teams planning an MCP security audit or MCP penetration testing, and it is a companion to how we test the model itself. If you are shipping an agent, read it alongside how integrations expand the LLM attack surface and indirect prompt injection explained, the mechanism most of these attacks build on.
What an MCP server exposes
An MCP server offers a client three kinds of capability: tools (functions the model can call), resources (data for the model or user) and prompts (templated workflows). The client is the connector inside a host application; the host is the app the user runs. The protocol uses JSON-RPC over stdio (a local process) or Streamable HTTP (a network service), and the current revision, dated 2026-07-28, made the protocol stateless: it removed protocol-level sessions and the Mcp-Session-Id header, so servers that need state now mint their own handles and receive them back as ordinary tool arguments.
Two things about that design drive the testing. First, tool descriptions are instructions the model reads and acts on, so they are an injection surface, not just documentation. The specification says so directly: “descriptions of tool behavior such as annotations should be considered untrusted, unless obtained from a trusted server” (MCP specification). Second, a server-minted handle is now just a string in a tool call, so the server has to check that the caller owns it rather than trusting possession.
MCP server security risks we test for
The OWASP MCP Top 10 (2025, in beta) is the clearest catalog of what goes wrong. Its ten items:
| ID | Risk |
|---|---|
| MCP01 | Token mismanagement and secret exposure |
| MCP02 | Privilege escalation via scope creep |
| MCP03 | Tool poisoning |
| MCP04 | Software supply chain attacks and dependency tampering |
| MCP05 | Command injection and execution |
| MCP06 | Prompt injection via contextual payloads |
| MCP07 | Insufficient authentication and authorization |
| MCP08 | Lack of audit and telemetry |
| MCP09 | Shadow MCP servers |
| MCP10 | Context injection and over-sharing |
The rest of this guide groups these into the tests we run.
Tool poisoning and rug pulls (MCP03, MCP06)
A tool’s name and description are read by the model when it decides what to call. Malicious text there, whether in the description or elsewhere in the schema, can redirect the model: exfiltrate data through a normal-looking search query, call a different tool, or ignore a safety instruction. The OWASP MCP Security Cheat Sheet tells you to treat the whole tool schema, not only the description field, as a potential injection surface. A rug pull is the same attack over time: a server that “changes its tool definitions after initial user approval, turning a trusted tool malicious.” We test by reviewing every tool definition for hidden instructions, changing definitions after approval to see whether the host re-verifies, and attempting cross-tool influence where several servers are connected.
The defenses we check for: pinning tool definitions with a cryptographic hash and alerting on change, showing the user the real tool name and parameters before a call, and re-verifying definitions before each execution rather than only at discovery.
Authentication and authorization (MCP07, MCP02)
Authorization is optional in MCP, so the first question for any server reachable over HTTP is whether it has any at all. Where it does, the spec is specific about what good looks like, and we test against it:
- Audience validation. A server “MUST validate that access tokens were issued specifically for them as the intended audience.” We send tokens minted for another resource and confirm they are rejected.
- No token passthrough. The spec forbids a server accepting a token not issued for it and forwarding it downstream; this is the confused-deputy pattern. We check the server does not relay tokens.
- Tokens out of the URL. Access tokens “MUST NOT be included in the URI query string,” because query strings end up in logs and history.
- State handles. The spec’s security guidance says a server must not treat possession of a state handle as authentication. We replay one user’s handles as another user and try guessing sequential ones.
- OAuth handling. For servers that proxy a third-party API, we test the confused-deputy flow the spec describes, where a consent cookie lets an attacker skip the consent screen, and check that the proxy enforces per-client consent, exact redirect-URI matching and single-use
statevalues.
Scope creep (MCP02) is the authorization failure over time: a token granted broad scopes up front so nothing has to ask again. We check that the server follows least privilege, challenges for scopes as operations need them, and does not publish an omnibus scope.
SSRF and injection (MCP05)
SSRF runs in two directions. A server’s own tools often fetch URLs that a user or a document supplies. And on HTTP transports, the client fetches OAuth metadata URLs that the server supplies during discovery, so a malicious server can point the client at internal addresses: cloud metadata endpoints like 169.254.169.254, private ranges, or localhost services. The spec tells clients to enforce HTTPS, block private and link-local ranges, validate redirect targets and consider an egress proxy. We test whether your tools and your client honor those limits, and we test the tools themselves for command injection where they shell out, which is the core of MCP05.
Local server compromise and supply chain (MCP04, MCP09)
A local MCP server is a binary that runs on the user’s machine with the user’s privileges. The spec’s own example shows the danger: a malicious startup command in a client config that exfiltrates SSH keys, or a payload inside the server itself. We review how a local server is installed and whether the host shows the exact command before running it, whether the server runs sandboxed, and whether an HTTP-transport local server is exposed to other processes or DNS rebinding. Supply chain (MCP04) covers the dependencies and the distribution: we check that the server is signed, that its dependencies are pinned, and that the pipeline that builds it is locked down (our guide to CI/CD pipeline security covers what to check there). Shadow servers (MCP09) are the ones nobody sanctioned; we look at how the host decides which servers to trust.
Secrets, logging and over-sharing (MCP01, MCP08, MCP10)
MCP01 covers hard-coded credentials, long-lived tokens and secrets that end up in model memory or protocol logs, where they can be retrieved later. We look for secrets in config files, environment variables, prompt templates, logs and context, and for tokens that outlive the task that needed them. For logging (MCP08), we check that tool invocations are recorded with parameters, user and timestamp, because without that trail an abuse cannot be investigated. Context over-sharing (MCP10) is what happens when context is shared, persistent or scoped too loosely, so information from one task, user or agent reaches another. We test whether one user’s data can surface in another user’s work through shared context, or through a server that returns more than the task needs.
How we test an MCP server
Our AI and LLM penetration testing covers MCP servers as part of AI agent security testing. A typical engagement:
- Map the server. Enumerate every tool, resource and prompt, the transport, the auth model and what each tool can reach. Static, no exploitation.
- Review the tool schemas for injection surface and for tools whose reach is wider than their purpose.
- Test authentication and authorization against the spec: audience validation, token passthrough, scope handling, and the OAuth proxy flows for HTTP servers.
- Test the tools for injection, SSRF and unsafe actions, in a staging environment with sandboxed accounts and dry-run modes so nothing real is sent or changed.
- Test tool poisoning and rug pulls end to end, including whether the host re-verifies changed definitions and whether one server can influence another.
- Check secrets, logging and sandboxing for the local and supply-chain risks.
- Report and retest. Findings mapped to the OWASP MCP Top 10 and the MITRE ATLAS techniques they enable, with a free retest after you fix.
We prove an injection would have sent the email or read the record without it actually happening, the same way we test any agent with tool access. Our page on balancing LLM security and usability covers how to keep those controls without breaking the product.
What it costs
MCP server testing is scoped inside an AI and LLM engagement. Those start at $4,500 for a single LLM feature with no tool access, but an MCP server gives the model tools, so MCP work usually sits in a higher tier. An application with a retrieval pipeline and one or two tools the model can call is the medium tier at $7,500. An agentic system with many tools, several models and multiple MCP servers is the large tier, from $12,000. The price is fixed in writing before work begins and every engagement includes a free retest. See the AI penetration testing cost page for what moves the number, and scope your test to get a fixed figure for your architecture.
Frequently asked questions
Does MCP require authentication? No. Authorization is optional in the protocol. Servers on stdio are expected to read credentials from the environment; HTTP servers that choose authorization should follow the OAuth 2.1 based flow in the spec, including validating that every token was issued for that server.
Which MCP weaknesses do you check first? Authentication on any server exposed over HTTP, because authorization is optional in the protocol, and tool descriptions or scopes that carry more authority than the tool needs. Both let one prompt or one connected server reach further than intended.
Can you test an MCP server without touching production? Yes, and we prefer to. We test in a staging environment with real tool definitions and sandboxed accounts, and use dry-run or read-only tool modes so we can prove an action was possible without carrying it out.
How is testing an MCP server different from a normal API test? An API test checks the endpoints. An MCP test also treats the model as an attacker-influenced caller: tool descriptions become an injection surface, and the question is not only whether an endpoint is secure but whether the model can be steered into misusing a legitimate tool.
Which standards do you test against? The Model Context Protocol specification and its security best practices, the OWASP MCP Top 10, and the OWASP Top 10 for LLM Applications for the model behind the server. Findings map to MITRE ATLAS.
Fixed price, fixed scope, free retest. Scope your MCP and agent test and get the price in writing.
Written by
Invadel Team
Senior penetration testers writing from real engagements, the same team that scopes, tests, and reports for our clients. About Invadel →