MCP server security starts with a blunt rule: treat every MCP server like software that can touch your data, call tools, and influence an AI agent’s next move. The Model Context Protocol is useful because it connects assistants to resources, prompts, and executable tools, but that same design creates risks around authorization, prompt injection, command execution, and data exfiltration.
Why MCP server security is different from ordinary API security
Anthropic released the Model Context Protocol on November 25, 2024, as an open protocol for connecting AI applications to external data sources and tools. By the November 25, 2025 specification, MCP servers provide three main things: resources, prompts, and tools. Tools are the sharp edge. They’re functions the model can execute.
A normal API waits for a deterministic client to make a request. An MCP server may sit behind an AI host that interprets user intent, reads tool descriptions, selects actions, and sometimes chains several servers together. That makes mcp server security partly an application security problem and partly an agent-control problem.
The official MCP security policy, published on GitHub and referenced in 2026, is refreshingly direct: MCP clients trust the servers they connect to, and local MCP servers should be trusted like installed software. That’s the right mental model. If you wouldn’t install an unsigned desktop app from a random repository on a finance laptop, don’t connect that same machine’s AI client to a random tool server with file-system or network access.
If you’re building agentic workflows, the operational risk looks closer to autonomous software delivery than to a chat widget. The same caution applies to AI coding loops and unattended changes; our guide to loop engineering for AI systems is relevant because MCP tools often become the hands of those loops.
The core threat model: tools, trust, and data movement
Start with what the server can actually do. A read-only server that exposes public documentation is a different creature from a server that can query production databases, send Slack messages, create GitHub pull requests, or initiate payments. Honestly, calling both “an MCP server” can hide the risk difference.
The MCP specification says hosts must obtain explicit user consent before invoking any tool and before exposing user data to servers. Don’t treat that as a UX nicety. It’s a security boundary, and a weak one if your host presents vague prompts such as “Allow access?” without listing the target server, tool name, data category, and consequence.
OWASP’s 2026 practical guide for secure MCP server development emphasizes secure architecture, strong authentication and authorization, strict validation, session isolation, and hardened deployment. Those are familiar words, but MCP gives them a twist: a malicious response can be read by the model as an instruction, not just displayed as data.
Here’s the pitfall many teams miss: the dangerous part may be a tool you didn’t call directly. In a multi-server setup, one low-privilege server can return text that nudges the agent to call a privileged tool on another server. That’s implicit trust propagation, and a January 2026 arXiv paper titled “Breaking the Protocol” reported it as one of three protocol-level concerns, alongside lack of capability attestation and bidirectional sampling without origin authentication.
Where authentication fits in mcp server security
The June 18, 2025 MCP authorization specification defines HTTP-based authorization using OAuth 2.1, OAuth Authorization Server Metadata, Dynamic Client Registration, and Protected Resource Metadata. If your server is reachable over HTTP, you should be reading that spec, not improvising bearer-token handling in a weekend branch.
Authorization is optional in the protocol, though. That sentence should make you pause. The spec says HTTP transports should follow the MCP authorization specification, STDIO transports should retrieve credentials from the environment, and alternative transports should follow their own protocol’s security practices.
Optional protocol auth does not mean optional security. It means the burden moves to you. For mcp server security, you need to decide which identities exist: the human user, the host application, the MCP client, the server, and the downstream service account. If those collapse into one all-powerful token, auditability suffers and compromise hurts more.
A practical pattern is to separate user authorization from tool authorization. A user may be allowed to connect to a CRM MCP server, but not allowed to run “export_all_contacts” or “delete_account_notes.” If you already think in terms of identity hardening, the failure modes resemble the MFA and session-abuse issues covered in our Microsoft 365 MFA warning analysis: authentication alone doesn’t save you when sessions and permissions are too broad.
Known vulnerabilities and what they teach
The most concrete public vulnerability in the supplied record is CVE-2025-6514, published by NVD on July 9, 2025. It affected the npm package mcp-remote versions 0.0.5 through 0.1.15, and NVD classified it as CWE-78 OS Command Injection.
The vulnerability involved connecting to untrusted MCP servers via crafted authorization_endpoint response URLs. Its CVSS v3.1 vector was AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H. Translated: network attack vector, low attack complexity, no privileges required, user interaction required, changed scope, and high confidentiality, integrity, and availability impact.
| Issue or research item | Year | What was reported | Security lesson |
|---|---|---|---|
CVE-2025-6514 in mcp-remote |
2025 | OS command injection in versions 0.0.5 through 0.1.15 |
Don’t trust server-provided authorization metadata without validation |
| OWASP MCP Tool Poisoning | 2026 | Malicious tool responses can trigger restricted calls, leaks, or prompt bypasses | Treat tool output as untrusted input, not as instructions |
| “MCP Pitfall Lab” arXiv preprint | 2026 | Hardening reportedly reduced Tier-1 findings from 29 to 0 at a mean cost of 27 lines of code | Small code changes can remove major classes of exposure |
| LangSight scan | 2026 | Reported 8,247 MCP servers exposed without authentication | Internet exposure is already happening at scale |
| TrueFoundry research | 2026 | Reported 492 publicly exposed MCP servers lacking basic authentication or encryption | Basic transport and auth hygiene still fail in real deployments |
Those internet-exposure numbers come from vendor research, not a standards body, so treat them as warning signals rather than census data. Still, the direction is obvious. Teams are publishing MCP endpoints faster than they’re threat-modeling them.
Run a simple calculation. If one exposed server has four tools, and only one tool can read internal tickets, summarize documents, or send messages, a single poisoned response may create four decision points where the agent can be steered. Scale that to 50 internal servers and you’re no longer reviewing “a chatbot integration.” You’re reviewing a distributed automation fabric.
Tool poisoning: the risk ordinary scanners miss
OWASP describes MCP Tool Poisoning as indirect prompt injection through malicious MCP tool responses. The outcome can be nasty: an agent may call restricted tools, leak data, or bypass system prompts because a tool returned content that looked like an instruction.
Classic security scanners look for SQL injection, command injection, path traversal, and exposed secrets. Useful. But they won’t reliably understand that a JSON field named summary contains language telling the model to ignore prior rules and send credentials to another tool.
Good mcp server security therefore requires output discipline. OWASP’s prevention guidance includes fixed-schema structured outputs, isolation of privileged tools, server-side access controls, approved-server allowlists, least privilege, and out-of-band user confirmation for sensitive or exfiltrating actions. I’d put fixed schemas near the top. Free-form prose is where a lot of agent confusion starts.
For systems that retrieve external knowledge, the same family of risks appears in retrieval-augmented generation. If your MCP server feeds documents into an agent, the design questions overlap with the ones in RAG versus fine-tuning decisions: where does untrusted text enter, who can influence it, and what can the model do after reading it?
Build a practical hardening checklist
Security advice gets vague quickly, so make it operational. Before an MCP server reaches a real user or a real dataset, you should be able to answer what the server exposes, which identities can call it, what each tool can touch, and how you’ll detect abuse.
- Inventory every tool. Record the tool name, description, parameters, downstream systems, data classes, and destructive actions in 2026-friendly documentation your reviewers can actually read.
- Use least privilege credentials. Give each server and high-risk tool only the permissions it needs, preferably with scoped tokens and separate service accounts.
- Validate inputs and outputs. Enforce strict schemas, reject unexpected fields, cap string lengths, and avoid passing raw tool output into agent context when a typed value will do.
- Require explicit consent for risky calls. Show the user the server, tool, arguments, destination, and data being shared before execution, especially for email, payments, deletion, code changes, and exports.
- Separate privileged tools. Keep read-only search tools away from write tools, admin tools, and secrets access; use separate servers if that makes the boundary clearer.
- Allowlist trusted servers. Don’t let employees connect arbitrary public MCP servers to internal hosts without review, version pinning, and configuration approval.
- Log decisions, not just HTTP requests. Capture tool selection, user approval, server identity, arguments, outputs, and downstream effects with retention that matches your incident-response needs.
A counter-argument deserves airtime: too many confirmations can train users to click through. True. The answer isn’t fewer controls everywhere; it’s risk-based friction. A weather lookup shouldn’t feel like a wire transfer, but exporting customer data to a third-party server should require a visible, separate confirmation.
Observability matters because MCP failures can look like “the model did something weird.” Instrument the chain. If you’re building telemetry for agent systems, our breakdown of AI observability architecture at data scale maps well to MCP logging, traces, and event correlation.
Deployment choices that reduce blast radius
Local STDIO servers are tempting because they’re easy to wire into developer tools. The official security policy’s comparison is useful: treat local MCP servers like installed software. Pin versions, review code or provenance, and avoid running them with your normal shell’s full set of secrets unless they truly need them.
Network servers need transport protection, authentication, authorization, and rate limits. If a server is public-facing, put it behind the same controls you’d expect for an internal API: TLS, identity-aware access, monitoring, patching, dependency scanning, and emergency disable switches. Boring controls win here.
The 2026 arXiv “MCP Pitfall Lab” preprint reported that recommended hardening reduced Tier-1 findings from 29 to 0 and reduced its framework risk score from 10.0 to 0.0 at a mean cost of 27 lines of code. Because it’s a preprint, don’t treat the numbers as universal. Treat them as a useful reminder that many MCP mistakes are small and fixable: missing validation, weak origin checks, overbroad permissions, and ambiguous tool descriptions.
Agentic commerce raises the stakes further. A tool that reads inventory is one thing; a tool that spends money is another. The security questions around consent, transaction limits, and human approval overlap with the risks discussed in agentic AI payments and shopping, where a bad action may have immediate financial consequences.
Governance: decide who gets to connect what
Someone in your organization needs ownership of MCP connections. Without it, every team becomes its own integration authority, and the weakest experiment defines your exposure. That’s how “temporary” servers become permanent attack paths.
A clean governance model has three gates. First, approve the server source: vendor, repository, maintainer, license, and update process. Next, approve the capabilities: tools, scopes, data categories, and outbound destinations. Finally, approve the runtime: host application, transport, credentials, logging, and user consent flow.
Public reports in 2026 from LangSight and TrueFoundry claimed hundreds to thousands of exposed MCP servers without authentication. Even if the exact totals shift as scans improve, the lesson for mcp server security is stable: default-deny external exposure, and make exceptions boringly formal.
You’ll also want a kill switch. If a tool starts leaking data or a dependency receives a CVE like mcp-remote did in 2025, you need to disable the server, rotate credentials, revoke sessions, and preserve logs without waiting for a platform team meeting next Thursday.
FAQ
What is an MCP server in simple terms?
An MCP server is a service that exposes resources, prompts, or tools to an AI application through the Model Context Protocol. The risky part is tools, because they are functions the model can execute.
Is MCP authorization required by the protocol?
No. The 2025 MCP authorization specification defines OAuth 2.1-based HTTP authorization, but authorization is optional in the protocol. HTTP transports should follow the MCP authorization spec, while STDIO and other transports need appropriate credential handling for their environment.
What is MCP Tool Poisoning?
MCP Tool Poisoning is an indirect prompt injection attack where malicious tool output influences an agent to call restricted tools, leak data, or ignore system instructions. Fixed output schemas, least privilege, server allowlists, and out-of-band confirmation reduce the risk.
Should I trust public MCP servers?
Only after review. The official MCP security policy says clients trust the servers they connect to, so public servers should be treated like third-party software with access to your agent, data, and sometimes local capabilities.
What is the fastest win for mcp server security?
Inventory every tool and remove unnecessary permissions. Then add strict schema validation and explicit confirmation for sensitive actions; those controls reduce both ordinary software bugs and agent-specific abuse.
EN 
FR 
ES