MCP Trust Assessment
The Model Context Protocol is becoming the USB standard for AI agents. Like USB, the question is what happens when you plug in something you shouldn't trust.
What Is MCP?
The Model Context Protocol, introduced by Anthropic in November 2024, is an open standard for connecting AI models to external tools and data sources. Instead of building custom integrations for every tool, MCP provides a universal interface: one protocol, any tool. It's been adopted by Claude, Cursor, VS Code, and thousands of community implementations.
It solved a real problem. And in doing so, it created a new attack surface that the security community is still mapping.
What It Does Well
MCP's architecture has genuine security advantages. The spec team shipped three major authorisation revisions in 2025 alone, responding actively to discovered issues. The security research community mobilised quickly with OWASP publishing a dedicated MCP Top 10 framework.
Protocol-Level Boundaries
Security policies enforced at the protocol layer. The client/server/host separation creates natural trust boundaries that enable Zero Trust principles.
Local-First Design
In the stdio transport model, data doesn't leave the device unless explicitly approved. Human-in-the-loop confirmation is built into the spec.
Rapid Spec Iteration
Three auth revisions in 2025 (March, June, November). The team responds to vulnerabilities. OAuth 2.1 with PKCE is now the recommended baseline.
The Core Problem
The spec is sound. The ecosystem isn't.
MCP is not insecure by design — it's insecure by default in practice. The protocol assumes careful implementation, user vigilance, and trusted servers. The real world delivers none of these consistently.
Technical Detail ▸Technical Detail ▾
315 documented vulnerabilities as of 2025, accounting for 14.4% of all AI vulnerabilities. 43% of tested implementations contain command injection flaws. 53% rely on static API keys. 5.5% of servers in the wild exhibit tool poisoning vulnerabilities. The gap between specification and implementation is where the attacks live.
Risk Matrix
Tool Poisoning
Malicious instructions can be hidden inside MCP tool descriptions. They're invisible to users in most client UIs but fully visible to the AI, which follows them as if they were legitimate. Invariant Labs demonstrated success rates above 70%.
Technical Detail ▸Technical Detail ▾
Hidden directives embedded in tool descriptions using tags like <IMPORTANT> are rendered by the LLM but stripped or summarised by client UIs. The “shadowing” variant is worse: a malicious server's tool description modifies the behaviour of a different, trusted server's tools. For example, a weather tool's description can instruct the LLM to BCC an attacker on all emails sent via a separate email tool. Cursor's confirmation dialog was confirmed to hide full tool inputs, making exfiltrated data (e.g., SSH keys) invisible during approval.
Cross-Server Data Exfiltration
When multiple MCP servers connect to the same client, a malicious server can instruct the AI to read data from your other servers and send it externally. Invariant Labs demonstrated full WhatsApp message history exfiltration this way.
Technical Detail ▸Technical Detail ▾
This is architecturally fundamental to MCP's design. Any installed server gains indirect access to all other servers' data through the AI. Simon Willison calls this the “lethal trifecta”: private data + untrusted instructions + exfiltration pathways. The attack bypasses traditional DLP systems because it looks like normal AI behaviour. Docker documented the WhatsApp exfiltration case in detail.
First Malicious MCP Server on npm
In September 2025, the postmark-mcp package was discovered on npm — a deliberately malicious MCP server designed to harvest and exfiltrate emails from AI workflows. The supply chain attack vector is now proven.
Technical Detail ▸Technical Detail ▾
The package used standard npm distribution, making it discoverable through normal installation flows. Snyk and Semgrep independently confirmed the malicious behaviour. This coincided with a broader September 2025 npm supply chain attack compromising 200+ packages including debug and chalk (2.6B weekly downloads).
Rug Pull Attacks
A tool behaves legitimately on Day 1 to earn trust and approval. After approval, the server silently updates its behaviour to include malicious actions. Most MCP clients don't re-notify users when tool definitions change.
Technical Detail ▸Technical Detail ▾
No built-in mechanism in the MCP spec detects or prevents post-approval tool redefinition. Tool descriptions and server-side logic can change without triggering re-consent flows. Acuvity documented this as “silent redefinition” — the tool still appears as the same version while its behaviour has fundamentally changed. Version pinning is recommended but not enforced by the protocol.
Credential Exposure at Scale
A study of 5,200 MCP servers found only 8.5% use OAuth. Over half rely on static API keys, and 79% pass credentials through environment variables. These keys rarely rotate and have no usage monitoring.
Technical Detail ▸Technical Detail ▾
Astrix Security's research revealed the credential management gap: 53% of servers use long-lived static secrets (API keys, PATs) with no scoping, rotation, or monitoring. The MCP spec now recommends OAuth 2.1 with PKCE, but compliance is voluntary and adoption is minimal. The Smithery registry path-traversal bug (August 2025) exposed credentials across 3,000+ tenants.
Command Injection in Implementations
Elastic Security Labs found 43% of tested MCP implementations contained command injection flaws. 30% permitted unrestricted URL fetching, opening doors to SSRF attacks against internal networks.
Technical Detail ▸Technical Detail ▾
Common patterns include unsanitised input passed to shell commands (as in CVE-2025-53967 against Framelink Figma MCP Server), shell command construction from user-controlled parameters, and URL fetching without private IP range blocking. The MCP spec warns against these but enforcement depends entirely on implementation quality. Cloud metadata endpoints (169.254.169.254) are reachable from many deployments.
Output Poisoning
Tool responses — not just descriptions — can contain hidden instructions. CyberArk demonstrated that even error messages and return values can manipulate the AI's subsequent actions.
Technical Detail ▸Technical Detail ▾
CyberArk coined “Full-Schema Poisoning” (FSP): the attack surface extends across the entire tool schema including dynamic content like error messages and outputs. Advanced techniques include injecting invisible zero-width Unicode characters that appear benign to users but alter downstream AI behaviour, potentially leading to data exfiltration or unauthorised execution.
Enterprise Auth Spec Immaturity
The MCP authorisation spec has been revised three times in 2025 alone. Enterprise integration remains difficult, and what you build today may need significant revision as the protocol evolves.
Technical Detail ▸Technical Detail ▾
Christian Posta (Solo.io) called the spec “a mess for enterprise.” The June 2025 revision reclassified MCP servers as OAuth Resource Servers (not Authorization Servers) and added Resource Indicators (RFC 8707). The November 2025 revision added XAA (Cross App Access) for enterprise IdP visibility. Each revision required breaking changes to existing implementations. The token passthrough anti-pattern persists despite being explicitly forbidden in the spec.
Shadow MCP Servers
Developers can connect MCP servers to their AI tools without IT knowledge or approval. OWASP lists this as a Top 10 MCP risk — invisible integrations that bypass organisational security policy.
Technical Detail ▸Technical Detail ▾
MCP servers are configured per-user in local config files (e.g., claude_desktop_config.json). No central registry, discovery mechanism, or organisational approval flow exists. A developer connecting a personal MCP server to their work AI client creates an unmonitored data path between corporate systems and external services.
Anthropic Doesn't Audit the Ecosystem
Anthropic explicitly states they do not manage or audit any MCP servers. Their guidance is “only connect to trusted MCP servers” — but trust verification is left entirely to the user.
Technical Detail ▸Technical Detail ▾
From the official security guidance: “Either write your own MCP servers or use MCP servers from providers that you trust.” No centralised vetting, signing, or certification mechanism exists for community servers. 20,000+ implementations on GitHub with no quality or security baseline. The Vulnerable MCP Project (vulnerablemcp.info) exists as an educational resource, which speaks to the state of the ecosystem.
CVE Timeline
Eight months of escalating discoveries. The pattern is clear: vulnerabilities are being found faster than they're being fixed.
The Lethal Trifecta
Simon Willison identified the fundamental architectural risk that makes MCP uniquely dangerous compared to traditional API integrations:
Private Data
MCP servers connect to your files, databases, messages, and credentials. The AI sees everything the server exposes.
Untrusted Instructions
Tool descriptions, responses, and error messages can all contain hidden directives that the AI follows without question.
Exfiltration Pathways
Other MCP servers, HTTP requests, and tool outputs provide multiple channels to send private data externally.
When all three conditions are present, any MCP server can potentially access and exfiltrate data from any other server connected to the same client.
The Practitioner's Dilemma
Here's the uncomfortable truth: if you're already working in an agentic coding environment with shell access, you can do most of what MCP does through the CLI. Direct tool access, battle-tested security models, full command transparency, no extra protocol layer.
MCP's real value is at the ecosystem level — standardising how any AI talks to any tool. At the individual practitioner level, it often adds complexity and attack surface for marginal convenience. The protocol is most valuable for tool discovery (advertising what's available), structured schemas (typed inputs and outputs instead of string parsing), portability across AI clients, and making tool access possible for non-developers who would never open a terminal.
This assessment was written using an AI agent running MCP servers for research and content management. The protocol being critiqued is the one powering the critique. That's the dilemma — MCP is genuinely useful, which is exactly why getting the security right matters.
Hardening Recommendations
The trust model needs to shift from "trust the user to vet everything" to "trust nothing, verify everything, contain blast radius."
For All MCP Users
- • Only install MCP servers from sources you can audit. First-party and well-known open-source only.
- • Never enable auto-approval for tool calls. Review every action the AI takes through MCP tools.
- • Minimise the number of servers connected simultaneously. Cross-server exfiltration requires multiple servers.
- • Pin MCP server versions. Don't allow automatic updates without review.
- • Use dedicated API keys with minimal scopes and spending limits. Rotate regularly.
For Organisations
- • Maintain an approved MCP server registry. Vet and sign servers before allowing deployment.
- • Run MCP servers in containerised environments with network isolation. No direct access to production systems.
- • Integrate secrets management (Vault, AWS Secrets Manager) instead of environment variables.
- • Deploy mcp-scan or equivalent tooling in CI/CD pipelines. Automated scanning for tool poisoning and known vulnerabilities.
- • Monitor for Shadow MCP Servers. Developers connecting unapproved servers is an OWASP Top 10 MCP risk.
Technical Detail ▸Technical Detail ▾
Emerging security tooling worth evaluating:
- mcp-scan (Invariant Labs/Snyk) — Security scanner for MCP servers and agent skills
- MindGuard — Decision Dependency Graph-based poisoning detection; 95.3% accuracy
- MCP Manager — Description-change detection to block rug pull attacks
- Microsoft MCP Azure Security Guide — OWASP MCP Top 10 mapped to Azure mitigations
Hard No-Go Criteria
Do not deploy MCP in production if any of these apply:
- • Auto-approval is enabled for tool calls (no human in the loop)
- • MCP servers have direct access to production databases or credentials
- • No process exists for vetting and approving new MCP server installations
- • Regulatory data (HIPAA, PCI-DSS, SOX) is accessible through connected MCP servers
- • Multiple untrusted MCP servers connect to the same client session
Bottom Line
The right standard with the wrong defaults.
MCP solved the right problem — AI needs a universal way to connect to tools. The architecture is sound, the spec is improving, and the security community is engaged. But 315 vulnerabilities in year one, the first malicious server already on npm, and an ecosystem where 53% of servers rely on static credentials tells you where we are. Use MCP. Harden it first.
Sources & Further Reading
- OWASP MCP Top 10
- Invariant Labs — MCP Tool Poisoning Attacks
- Simon Willison — MCP Prompt Injection
- CyberArk — Full-Schema Poisoning
- Astrix Security — State of MCP Server Security 2025
- AuthZed — Timeline of MCP Breaches
- MCP Specification — Security Best Practices
- Docker — MCP Horror Stories: WhatsApp Exfiltration
This is the protocol layer assessment in the Adoption Curve series — tracking how each layer of the AI stack democratizes faster than it's secured.