Top 10 MCP Security Risks: Tool Poisoning, Token Passthrough and Over-Permissioned Servers

Most Model Context Protocol (MCP) incidents come from ordinary identity and supply chain failures that the protocol makes easier to commit: long-lived tokens in config files, servers granted every scope, tools installed from whoever published first, and no record of what the agent actually called. This page ranks the ten MCP security risks practitioners should know, using the ten entries of the OWASP Top 10 for Model Context Protocol, which OWASP's project page shows in beta as of November 2026 (risk IDs carry the suffix :2025). For each risk it gives what goes wrong, how to spot it and the first controls, drawing on the MCP specification's own Security Best Practices for token passthrough, confused deputy and session attacks. It is written for platform, security and AI engineering teams approving or running MCP servers. For the per-server review procedure, use the MCP Server Security Checklist; for the wider architecture, the MCP Security Guide.

The Top 10 at a glance

The order follows OWASP's numbering. OWASP labels the list a beta, so names and order may change before a final release; confirm against the project page. Entry names follow the OWASP list; OWASP's detailed section for MCP06 currently uses the alternative title "Prompt Injection via Contextual Payloads". The "first control" column is our recommendation.

1. Token Mismanagement and Secret Exposure (MCP01:2025)

OWASP describes this as hard-coded or long-lived credentials that expose connected systems. In practice the commonest form is a personal access token or API key pasted into a client's JSON config, readable by any process on the laptop and copied into dotfile repositories. The second form is token passthrough: an MCP server accepts a token from the client and forwards it to a downstream API without checking it was issued to the server. The MCP specification forbids this outright: servers MUST NOT accept tokens that were not explicitly issued for the MCP server, because passthrough bypasses rate limits and monitoring keyed to the audience, breaks the audit trail and lets a stolen token use the server as an exfiltration proxy.

• Spot it: grep client configs and repositories for tokens; check whether the server validates the aud claim; look for downstream API logs showing the user's token rather than the server's.
• Control: one credential per server, issued for that server, short-lived and held in a secrets store or OS keychain. The authorization specification requires clients to send the RFC 8707 resource parameter naming the MCP server, and servers to reject tokens whose audience is not themselves; test both. When a server calls an upstream API it uses a separate token from the upstream authorisation server. The Smithery.ai MCP hosting breach shows the platform-side version: a single deployment token on a build machine reached more than 3,000 hosted apps.

2. Privilege Escalation via Scope Creep (MCP02:2025)

An MCP server granted files:* or admin:* turns any compromise of the agent into a compromise of everything those scopes reach. The specification's scope minimisation section lists the common mistakes: publishing every scope in scopes_supported, wildcard or omnibus scopes, bundling unrelated privileges to avoid future prompts, and treating scopes in a token as sufficient without server-side authorisation logic.

• Spot it: compare scopes granted with tools actually called over 30 days; flag servers whose token scope set has grown since approval.
• Control: start with a minimal scope set and use WWW-Authenticate scope challenges for step-up when a privileged tool is first used, as the specification recommends. Log every elevation. See the OWASP Agentic Top 10 ASI03 Guide for agent privilege more broadly.

3. Tool Poisoning (MCP03:2025)

Tool names, descriptions and schemas are read by the model as trusted context. A poisoned description can tell the model to read a file and include it in an argument, or to prefer one tool over another. Because servers can change their tool list during a session (the notifications/tools/list_changed message), a tool that was safe at approval can change later.

• Spot it: hash tool definitions at approval and alert on drift; scan descriptions for instruction-like text, hidden Unicode and references to other tools.
• Control: pin approved tool definitions at a gateway, show users the full description on change, and limit which tools may be combined in one session.

4. Software Supply Chain Attacks and Dependency Tampering (MCP04:2025)

Most local MCP servers are installed with a package manager command, which runs publisher code with the user's privileges. The postmark-mcp malicious MCP server is the reference case: an unofficial npm package that worked normally until version 1.0.16 added a hidden blind copy of every email the agent sent. The real vendor's service was not involved.

• Spot it: inventory installed servers with package name, publisher and version; compare with the official publisher's repository.
• Control: install only from an approved internal registry or the official publisher, pin exact versions, review diffs before upgrades and prefer servers with signed provenance. See the MCP Registry and Server Publishing Security Guide.

5. Command Injection and Execution (MCP05:2025)

Servers that build shell commands, SQL or file paths from tool arguments inherit every classic injection flaw, with the model as the unwitting source of the input. The specification adds client-side cases: clients MUST NOT use shell commands to open authorization URLs and MUST reject javascript:, data:, file: and similar schemes, because a malicious server can supply a URL that becomes code. One-click local server installs MUST show the exact command before running it.

• Spot it: code review for exec, spawn with a shell, string-built queries; dynamic testing with crafted arguments in a sandbox.
• Control: parameterised calls, argument allowlists, no shell, and run local servers in a sandbox with restricted file system and network access. See the Local MCP Server Security Guide.

6. Intent Flow Subversion (MCP06:2025)

This is indirect prompt injection delivered through MCP: content returned by a tool (an issue, an email, an error report, a web page) contains instructions that redirect the agent. The Sentry MCP agentjacking research showed the pattern in a controlled test: a fake error event returned through an MCP server carried a "resolution" command that coding agents ran with the developer's credentials.

• Spot it: log tool outputs alongside the actions that follow; flag actions with side effects that were not in the user's request.
• Control: treat every tool output as untrusted data, require human approval for commands, payments, sends and permission changes, and keep long-lived secrets out of agent environments. See the Prompt Injection Guide.

7. Insufficient Authentication and Authorization (MCP07:2025)

Remote MCP servers exposed without authentication, or with a single shared key, give anyone who finds them the server's full reach. Three specification requirements cover most of this risk:

• Verify every request: servers that implement authorization MUST verify all inbound requests and MUST NOT use sessions for authentication; session IDs must be secure and non-deterministic, and should be bound to the user (for example a <user_id>:<session_id> key).
• Prevent confused deputy: MCP proxy servers that use a static client ID with a third-party authorisation server and allow dynamic client registration MUST obtain per-client consent before forwarding, validate redirect_uri by exact match and use single-use state values. See the Confused Deputy in AI Agents Guide.
• Guard discovery: clients fetching OAuth metadata URLs supplied by a server SHOULD require HTTPS and block private, loopback and link-local ranges, including 169.254.169.254, to prevent SSRF.

The full flow is covered in the MCP Authorisation Specification Guide.

8. Lack of Audit and Telemetry (MCP08:2025)

Without a per-call record, responders cannot answer which agent, on whose behalf, called which tool with which arguments. Passthrough tokens make it worse, because downstream logs show the user rather than the server.

• Spot it: pick a recent tool call and try to reconstruct it end to end from logs. If you cannot, this risk is open.
• Control: route remote servers through a gateway that logs user identity, agent or client ID, server, tool, arguments (redacted), result status and scope elevations with a correlation ID, and send it to the SIEM. See the MCP Gateway and MCP Server Governance Guide.

9. Shadow MCP Servers (MCP09:2025)

OWASP describes unapproved deployments outside security governance, often with default or permissive settings. Developers add local servers to IDE and desktop clients in seconds, and teams stand up remote servers for internal data without review.

• Spot it: collect MCP client config files from managed endpoints with EDR or MDM, watch for npx and uvx launches by client processes, and scan internal networks for MCP endpoints.
• Control: publish an approved list with a fast request route, so the approved path is easier than the shadow one. See the Unsanctioned AI Agents and MCP Servers Guide.

10. Context Injection and Over-Sharing (MCP10:2025)

When context is shared or poorly scoped, data from one task, user or tenant becomes visible in another. Multi-tenant remote servers that key sessions or caches only by session ID, and agents that keep one long context across unrelated tasks, are the usual causes.

• Spot it: test with two users and two tenants; check whether resources, prompts or cached results cross between them.
• Control: partition server-side state by user and tenant, return only fields the task needs, and clear context between unrelated tasks.

Mapping to OWASP

The MCP list overlaps with OWASP's LLM and agentic lists. The mapping below is our reading, to help teams reuse existing test cases; OWASP does not publish it in this form.

For control frameworks, the same risks sit under NIST SP 800-53 AC-6 Least Privilege (MCP02, MCP07), CM-7 Least Functionality (MCP03, MCP09) and the audit family (MCP08).

Where to start

1. Inventory (week 1): collect every MCP client config on managed endpoints and every remote MCP endpoint. You cannot manage MCP09, MCP04 or MCP01 without this list.
2. Remove static secrets (weeks 1 to 4): move tokens out of config files and give each server its own credential issued for that server. Confirm no server passes client tokens through.
3. Put remote servers behind a gateway (month 2): one place for authentication, tool pinning, logging and scope enforcement covers MCP03, MCP07 and MCP08 together.
4. Gate side effects (month 2): require approval for tools that send, pay, delete, deploy or change permissions, which limits the damage from MCP06 and MCP03.
5. Test (quarterly): run injection, cross-tenant and token audience tests against approved servers. See the MCP Security Testing Guide.

Measure progress with: share of MCP servers in the approved inventory; share holding a dedicated short-lived credential; share of remote traffic through the gateway; tool definition drift alerts reviewed within one working day; and the number of tools with side effects that run without approval (target zero). These targets are ours.

Standards and references

• OWASP: Top 10 for Model Context Protocol (project page)
• Model Context Protocol: Security Best Practices (2025-11-25)
• Model Context Protocol: Authorization (2025-11-25)
• OWASP GenAI Security Project: LLM Top 10 2025
• IETF: RFC 9700 Best Current Practice for OAuth 2.0 Security
• IETF: RFC 9728 OAuth 2.0 Protected Resource Metadata
• MITRE ATLAS: AML.T0051 LLM Prompt Injection

Related NHI Mgmt Group resources: MCP Server Security Checklist · MCP Security Guide · MCP Security Best Practices Explained · Remote MCP Server Hardening Guide · MCP Incident Response Playbook