What is MCP, and why does it change the attack surface?
The Model Context Protocol defines how an MCP client (the AI application) talks to an MCP server (a wrapper around a tool or data source). A server advertises tools, each with a name, a description and an input schema. The model reads those descriptions, decides which tool to call and with what arguments, and the server carries out the call with whatever credentials it holds.
Three things make this different from an ordinary API integration.
- The model chooses the call. In a normal integration a developer writes the request. With MCP, the model decides at run time which tool to call and with what parameters, based on text it has read. Anything that can put text in front of the model can influence that choice.
- Tool descriptions are instructions. The description of a tool is written for the model, not the user. Most clients show the user a short name, while the model reads the whole description.
- Servers run with real authority. A local server runs with the privileges of the user's machine. A remote server acts with an OAuth token or API key. Either way, the tool call happens with an identity your security team may never have approved for that purpose.
A 2026 review of MCP in ACM Transactions on Software Engineering and Methodology maps threats across the MCP server lifecycle. It lists log audit, centralised log aggregation and integrity-protected storage as safeguards the operator has to add, not features the protocol provides (Hou et al., 2026). Our comparison of what Claude Code, Cursor, OpenAI, Copilot and MCP servers log shows the same gap from the logging side: an MCP server logs whatever its author chose to log.
What are the main MCP security risks?
The risks fall into two groups: attacks on what the model reads, and attacks on the authority the server holds.
Attacks on what the model reads
Tool poisoning. Instructions hidden in a tool description are invisible to the user but read by the model. Invariant Labs demonstrated in April 2025 that a poisoned description can tell the model to read a sensitive file and pass it to the attacker as a tool argument, while the user sees an ordinary tool.
Rug pulls and shadowing. The same research showed that a server can change a tool's description after a user has approved it, and that a malicious server can add instructions that change how the model uses a trusted server's tools. Approval at install time is not approval of what the tool says next week.
Indirect prompt injection through tool output. A web page, ticket, email, README or database row returned by a tool can carry instructions the model follows as if the user had written them. Greshake and colleagues showed this class of attack against real LLM-integrated applications (Greshake et al., 2023), and a 2026 review of prompt injection in agent systems finds that MCP has widened the attack surface, adding vulnerabilities such as tool poisoning and credential theft (Gulyamov et al., 2026). OWASP ranks it first in its Top 10 for LLM applications as LLM01.
Attacks on the authority the server holds
The MCP project's own security best practices name these attacks and their mitigations.
- Token passthrough. A server accepts a token that was not issued to it and forwards it to a downstream API. The authorisation specification explicitly forbids this, because it bypasses controls such as rate limiting and audience checks, and breaks the audit trail.
- Confused deputy. A proxy server using a static client ID with a third-party authorisation server can be tricked into granting an attacker access on a user's behalf if it skips per-client consent.
- Excessive scope. A server that requests every scope up front gives a stolen token a wide blast radius. The guidance asks for a minimal initial scope and step-up requests when a privileged tool is first used. OWASP lists the general pattern as LLM06, Excessive Agency.
- Local server compromise. A local server is a program running on the user's machine. A malicious start-up command in a client configuration, a malicious package, or an insecure local server reachable through DNS rebinding can all lead to arbitrary code execution with the user's privileges.
- Server-side request forgery and session hijacking. A server that fetches URLs supplied during authorisation, or that trusts a session identifier without binding it to the user, can be turned against internal systems or other users.
The supply-chain risk underneath
Most MCP servers are open-source packages installed by developers. That puts them in the same place as any other dependency: typosquatting, compromised maintainers and unpinned versions all apply. OWASP lists this as LLM03, Supply Chain. The difference is that an MCP server is a dependency the model can be persuaded to use.
How do you secure MCP?
The controls divide between the people who build servers, the people who run them, and the security team that has to answer for them.
For server builders, the protocol guidance is specific: validate that every token was issued to your server, never pass tokens through, apply per-client consent on proxies, keep scopes minimal and step up for privileged tools, bind sessions to users, and sandbox anything that runs locally. The UK NCSC's guidelines for secure AI system development set the broader expectation that security is designed in across design, development, deployment and operation.
For platform teams running MCP, the controls are the ones you would apply to any privileged integration, applied to a new kind of client:
- Approve servers explicitly. Keep an allow-list of servers and versions, and block the rest at the client or gateway.
- Pin and re-review. Pin each server to a version and a hash of its tool descriptions. Treat a changed description as a new approval.
- Give each server its own identity. One service identity per server, with scopes that match what its tools actually do.
- Require a human for consequential tools. Anything that deletes, pays, sends, deploys or changes access should need an approval step outside the model.
- Separate untrusted content. Keep tools that read untrusted content (web, email, tickets) apart from tools that can act, or require approval when output from one feeds the other.
- Log the whole chain. Record the prompt context, the tool call, the identity used, the network destination and the change in the target system, and keep it long enough to investigate.
For the security team, the harder question is visibility. Shadow MCP is real: a developer can wire a server into Cursor or Claude Code on a Friday afternoon, and no central system records it unless you look for it. Start with an inventory of which AI clients are in use, which servers they connect to, which OAuth grants those servers hold and who owns each one.
The MCP security checklist
Use this before approving an MCP server, and again when it changes. Each check names the evidence to ask for, so the answer is a record rather than an assurance.
| # | Check | Why it matters | Evidence to ask for | Reference |
|---|
| 1 | The server is on an approved list, with a named owner | Unapproved servers are the most common route in | Allow-list entry, owner, business purpose | NCSC secure AI guidelines |
| 2 | The version and tool descriptions are pinned | Descriptions can change after approval (rug pull) | Version, package hash, hash of tool descriptions | Invariant Labs, 2025 |
| 3 | Tool descriptions have been read in full by a person | Hidden instructions target the model, not the user | Review record of every description | OWASP LLM01 |
| 4 | The server validates the token audience and never passes tokens through | Token passthrough is forbidden by the specification | Code review or vendor statement on audience checks | MCP security best practices |
| 5 | Scopes are minimal, with step-up for privileged tools | A stolen broad token has a wide blast radius | Scope list per tool, step-up flow | MCP security best practices; OWASP LLM06 |
| 6 | The server runs under its own identity, not a user's | Shared identities break attribution and revocation | Service principal or client ID per server | NIST AI RMF, Govern |
| 7 | Proxy servers obtain per-client consent | Static client IDs enable confused-deputy attacks | Consent flow design | MCP security best practices |
| 8 | Local servers are sandboxed and start-up commands are reviewed | A local server runs with the user's privileges | Sandbox configuration, reviewed client config | MCP security best practices |
| 9 | Consequential tools need human approval outside the model | The model can be persuaded to call any tool it holds | Approval policy per tool, approver names | OWASP LLM06 |
| 10 | Untrusted-content tools are separated from action tools | Indirect prompt injection turns reading into acting | Tool pairing rules, approval on crossover | Greshake et al., 2023 |
| 11 | Tool calls are logged with identity, parameters and destination | The protocol does not require a call log | Sample log record joined to identity | Hou et al., 2026 |
| 12 | Logs are retained centrally and protected from change | Local logs vanish with the laptop | Retention period, storage location, integrity control | Hou et al., 2026 |
| 13 | You can revoke the server's access in one step | Incidents need fast containment | Revocation runbook, last test date | NCSC secure AI guidelines |
| 14 | You can reconstruct and reverse one real tool call end to end | Proof is the only test that counts | A worked reconstruction from prompt to target-system change | NIST AI RMF, Manage |
Checks 11 to 14 are where most organisations fail, because the evidence sits in different places: the AI provider holds the session, the identity provider holds the token, the MCP server holds whatever it logged, the network holds the destination and the target system holds the change. Our guide on why provider logs can't prove what your AI agent did walks through that chain.
