MCP Security: Risks in Model Context Protocol Servers and How to Test Them

MCP security, or Model Context Protocol security, means protecting the servers, clients and connections that AI assistants and agents use to reach tools and data, so that the protocol does not become a way into your systems. An MCP server can read files, query databases, call APIs and run commands on behalf of a model. That power means a poisoned tool description, an over-privileged token or a malicious package can turn a helpful assistant into an attacker’s proxy.

What is MCP (Model Context Protocol)?

MCP is an open protocol, first published by Anthropic in November 2024, that standardises how AI applications connect to external tools and data. Instead of a custom integration per tool, an application connects to MCP servers that expose capabilities in a common format. The MCP specification defines three roles:

Servers offer three main kinds of capability: tools (functions the model can call, such as “create ticket”), resources (data the model or user can read, such as files or records) and prompts (templated instructions). Messages use JSON-RPC 2.0. A server either runs locally as a subprocess launched by the client, talking over standard input and output (stdio), or as an independent process reached over Streamable HTTP, usually remotely, with authorisation built on OAuth. The specification is versioned by date; in October 2026 the current revision is dated 28 July 2026, so check which revisions your clients and servers support.

Are MCP servers safe?

Not by default. An MCP server is software that runs with whatever privileges you give it, and the protocol cannot enforce security on its own. The specification says so directly: tools represent arbitrary code execution, tool annotations should be treated as untrusted unless they come from a trusted server, and hosts must get explicit user consent before invoking any tool. Safety depends on who wrote the server, what it can reach, how it handles credentials and how your client is set up.

Local servers deserve particular care: they run with the user’s access to files, SSH keys, cloud credentials and internal networks, and are often installed with a single command from a public package registry.

What are the main MCP security risks?

There are six main MCP security risks. Tool poisoning and injection through returned content exist because a model reads untrusted text and acts on it; the other four are familiar problems with permissions, credentials, supply chain and code that MCP makes more dangerous.

Tool poisoning, shadowing and rug pulls

Tool poisoning works because the model reads the full tool definition, while most interfaces show the user only a short name. A description can tell the model to read a sensitive file and put it in a parameter, or to route every email through one particular tool. Two variations matter:

• Tool shadowing: a description in one server changes how the model uses a tool from a different, trusted server.
• Rug pulls: a server’s tool definitions change after you approved them. The protocol lets servers tell clients that their tool list has changed, so approval at install time is not enough on its own.

Why does untrusted content matter so much?

The most serious MCP attacks need three things in one session: access to private data, exposure to untrusted content, and a way to send data out. A model that can read your private repositories, process a public issue written by an attacker and then post a comment can leak data without any software vulnerability at all. Breaking any one of the three, for example by blocking outbound actions once untrusted content has been read, closes that route. The underlying technique is prompt injection, and the wider set of model risks is covered in the OWASP Top 10 for LLM Applications.

Token passthrough and the confused deputy

The MCP specification forbids token passthrough, and its security best practices say a server must not accept any token that was not explicitly issued for it, let alone forward it downstream. A related confused deputy flaw hits proxy servers that use one static OAuth client ID with a third-party API while letting MCP clients register dynamically: without per-client consent, which the best practices make mandatory, an attacker can register a client and ride on the user’s earlier consent.

MCP server security: how do you secure an MCP server?

Build and run MCP servers as you would any privileged API, then add controls for the model. The specification requires servers to validate all tool inputs, apply proper access controls, rate limit tool invocations and sanitise tool outputs. For teams that build or host servers:

1. Choose the right transport. Use stdio for local servers where possible. If a local server uses HTTP, bind it to localhost, validate the Origin header to block DNS rebinding, and require authentication.
2. Authenticate remote servers properly. Use the specification’s OAuth-based authorisation, check every token was issued for your server, and never pass client tokens through.
3. Minimise scopes. Start with a small read-only scope and step up for privileged operations. Avoid wildcard or “full access” scopes.
4. Validate every tool input. Never build shell commands, file paths, SQL or URLs by joining strings. Allow-list paths and destinations, and block internal and cloud metadata addresses.
5. Sanitise outputs. Label untrusted content in results, and keep secrets out of anything returned to the model.
6. Limit and log. Rate limit tool calls, set timeouts, and log each invocation with its caller and inputs.
7. Keep secrets out of config files. Use a secrets manager or the operating system’s keychain, and rotate anything that has ever sat in a repository.
8. Sandbox. Run servers in containers or sandboxes with restricted file system and outbound network access.
9. Secure the release process. Version and sign releases, record every change to tool definitions, and scan dependencies.

What should an MCP configuration review check?

If you use MCP servers through AI assistants, code editors or agent platforms rather than build them, review how those clients are set up:

Back this with a policy naming who may add, approve and own each server.

How do you test an MCP server?

An MCP test combines AI red teaming with conventional application and API testing. It should cover:

• Enumeration: every tool, resource and prompt the server exposes, and the permissions behind each.
• Definition review: names, descriptions and schemas checked for hidden instructions, and how the client handles definition changes.
• Authorisation: token audience checks, per-tool scope enforcement, token passthrough, proxy consent handling, and access to other users’ data, including state handles accepted without checking who owns them.
• Tool inputs: command injection, path traversal, SSRF and injection into downstream systems.
• Indirect injection: instructions planted in returned content, to see whether the model acts on them and what it can then reach.
• Transport and deployment: local exposure, origin checks, TLS, sandboxing and secrets stored on disk.
• Agent context: how the server behaves alongside the agent’s other servers and tools, since attacks often cross between them.

How do Sovereign Secure’s services relate to MCP?

We do not publish a dedicated MCP security assessment. These existing services relate to MCP deployments:

• AI red teaming tests models connected to tools, functions and data sources, including prompt injection and excessive agency.
• Agentic AI security testing focuses on agents and their tools, permissions, memory and approval steps.
• API penetration testing covers HTTP APIs, their authentication and their authorisation.
• Source code review examines application code for injection flaws and unsafe handling of input.

If you are working towards ISO 42001 certification, test results like these are evidence for the verification and validation its Annex A expects.

Tell us how you use MCP and we will say which scope, if any, fits.

Why Sovereign Secure?

• The layers MCP touches, tested by one firm: AI/LLM, API, web, cloud, network and source code testing.
• ISO 27001 certified, so test data, prompts and credentials are handled under a certified information security management system.
• A PCI SSC Qualified Security Assessor (QSA) company, incorporated in 2012, with headquarters in Accrington, Lancashire, and offices in Los Angeles, Singapore, Dubai and Dhaka.

What should you do next?

Start with the configuration review above: list your MCP servers, pin their versions and switch off auto-approval for anything that writes or sends. Then, for the agent or API that relies on MCP, request a fixed-price proposal through our penetration testing quote form, or call +44 161 523 5276.