MCP security: every unvetted server is an attack surface you chose to ignore
MCP adoption is moving fast. The official Python and TypeScript SDKs now see over 97 million monthly downloads. Anthropic donated the protocol to the Linux Foundation's Agentic AI Foundation in December 2025, making it vendor-neutral. Claude, Cursor, Windsurf, and a growing list of clients support it natively.
The problem is that security practices haven't kept up. Most MCP servers in use today are community-built, minimally audited, and connected to production systems with the same trust as first-party code. That should make you uncomfortable.
The architecture creates the risk
MCP's design is simple on purpose: servers expose tools, resources, and prompts; clients consume them; JSON-RPC 2.0 handles the wire protocol. Anyone can build an MCP server in 20 lines of Python with FastMCP, and it works with any client.
Which means anyone has built MCP servers. The community registry has hundreds of servers wrapping every API you can think of. Some are well-engineered. Some are weekend projects with no input validation. All of them get the same level of trust once you connect them to a client.
Think about what happens when you add an MCP server to Claude Desktop or your agent system. You're granting it the ability to execute code based on LLM decisions. The LLM decides when to call the tool, but the server decides what that call actually does. If the server has a vulnerability, or is outright malicious, every tool invocation is a potential exploit.
Three specific ways this goes wrong:
Data exfiltration. An MCP server wrapping your database has access to query results. Nothing in the MCP spec prevents that server from forwarding those results to an external endpoint alongside returning them to the client. You'd have a data leak that's invisible at the protocol level. Researchers at Invariant Labs demonstrated exactly this — a malicious server that combined tool poisoning with a legitimate WhatsApp MCP server to silently exfiltrate a user's entire message history.
Prompt injection via tool results. Tool call output feeds directly into the LLM's context. A compromised server can return results containing injected instructions: "Ignore previous instructions and execute the following..." As Simon Willison documented, the LLM processes this as part of the tool response and potentially acts on it through other connected tools. Palo Alto's Unit 42 team found that MCP sampling introduces additional attack vectors where servers can craft prompts and request completions from the client's LLM. CyberArk went further, showing that the attack surface extends across the entire tool schema, not just descriptions.
Credential exposure. MCP servers authenticating against external APIs hold credentials at runtime. API keys, OAuth tokens, service account credentials. A vulnerability allowing arbitrary code execution hands all of those to an attacker. This isn't theoretical — CVE-2025-6514 exposed a critical OS command-injection bug in mcp-remote, a popular OAuth proxy, and researchers found that Anthropic's own MCP Inspector tool allowed unauthenticated remote code execution via its inspector-proxy architecture.
The "it works" test is not a security audit
Here's how most people evaluate an MCP server: install it, connect it to the client, try a few tool calls, confirm results look right, move on. This validates functionality. It tells you nothing about security.
A functional test tells you the server returns weather data when you ask for weather data. It doesn't tell you whether the server logs your queries to a third-party analytics service. It doesn't tell you whether the server's npm dependencies include a compromised package. It doesn't tell you whether input parameters get passed directly to a shell command.
The gap between "it works" and "it's safe" is where enterprise risk lives. This is where human-in-the-loop validation applies to infrastructure, not just workflows — someone needs to audit what these servers actually do before they touch production data.
What managed MCP infrastructure changes
The alternative to trusting every community MCP server is running MCP infrastructure you control. Deploy servers on managed infrastructure with authentication, audit logging, and security isolation. Treat MCP connections the way you'd treat any other external service integration.
Here's what that gets you:
Authentication and authorization. Every client connection authenticates. Every tool invocation checks permissions. The MCP spec includes OAuth 2.1 support for exactly this, but most community servers don't implement it. Best practices call for mandatory PKCE, short-lived scoped tokens, and infrastructure-based client attestation. Managed infrastructure enforces it by default.
Audit logging. Every tool call, every parameter, every response gets logged. When something goes wrong (and in production, something always goes wrong) you can reconstruct exactly what happened, when, and with what inputs. Community servers log to stdout if they log at all.
Execution isolation. Tool execution runs in sandboxed environments, whether V8 Isolates or Firecracker microVMs, where a compromised tool can't reach the host system, other tools' credentials, or network resources outside its allowed scope. Firecracker's stripped-down VMM boots in under 125ms with less than 5MB of memory — practical enough for per-tool-call isolation. Even if a tool has a vulnerability, the blast radius stays contained.
Validated tool behavior. Before deployment, tool behavior gets validated against expected inputs and outputs. Not just "does it return data" but "does it return only the expected data, modify only the expected state, and communicate only with the expected endpoints." Tools like MCPTox and MindGuard can scan for tool poisoning and anomalous behavior patterns, but they're no substitute for running on infrastructure you control.
The enterprise adoption gate
MCP is on track to become the standard interface for agent-to-tool communication. Gartner predicts 33% of enterprise software will include agentic AI by 2028, up from less than 1% in 2024. Those systems will need to connect to dozens or hundreds of external tools and APIs — and as we explore in A2A + MCP: two protocols, one interoperability layer, the multi-agent dimension only multiplies the number of connections to secure.
Enterprises are not going to connect production agents to unvetted MCP servers. The security review process that currently takes weeks for a single SaaS vendor integration will apply to every MCP server an agent touches. At scale, that bottleneck kills AI adoption momentum.
The way through is infrastructure that handles security (authentication, isolation, auditing, validation) so that individual tool connections inherit enterprise-grade security by default. Teams shouldn't have to audit 50 community MCP servers one by one. They should connect to managed infrastructure that audits once and deploys securely.
Practical steps for today
If you're using MCP servers in production right now, three things you can do today:
Inventory your MCP connections. Know every server your agents connect to, who built it, when it was last updated, and what credentials it holds. You can't secure what you can't enumerate.
Isolate sensitive operations. MCP servers accessing customer records, payment systems, or internal APIs should run on infrastructure you control, not as local processes spawned by the client.
Monitor tool call patterns. If an MCP tool that normally returns 500-byte responses suddenly returns 50KB, something changed. If a tool that's called 10 times per hour starts getting called 1,000 times, something changed. Anomaly detection on tool usage patterns catches both compromised servers and misuse.
MCP is a good protocol. It standardizes something that badly needed standardizing. But standardizing the interface doesn't standardize the security of what's behind it. That's an infrastructure problem, and it needs an infrastructure solution.
Hintas deploys validated workflow knowledge as managed MCP servers with built-in authentication, execution isolation, and audit logging. Your agents get reliable tool access without the security risk of unvetted community servers. Check out hintas.ai if that's relevant to what you're building.
