- MCP security is not built into the protocol; the specification places all implementation responsibility on server operators.
- Tool poisoning, prompt injection and command injection flaws dominate the MCP threat landscape and drive most recent MCP Common Vulnerabilities and Exposures (CVEs).
- Security teams adopting agentic AI should audit every MCP server for authentication, least-privilege scoping and supply chain provenance.
What Is MCP Server Security?
MCP server security is the set of practices and controls that protect Model Context Protocol servers — and the tools, data, and credentials they connect to — from unauthorized access and abuse.
Model Context Protocol (MCP) is a standardized interface, introduced by Anthropic in November 2024, that lets AI agents discover and invoke external tools through a consistent JSON-based API.
MCP server security covers all the controls that keep that interface from becoming a liability.
The official MCP security specification states explicitly that the protocol does not enforce security at the protocol level, leaving authentication, authorization, input validation and monitoring entirely to implementers.
Why MCP Servers Are a High-Value Target
In practice, an MCP server often aggregates credentials for multiple enterprise services in one place. A single compromised server can expose tokens for every database, cloud service and file system the AI agent has permission to reach, making MCP servers attractive, high-value targets.
Three structural properties make MCP servers unusually risky compared to conventional APIs:
- Credential concentration. A single server may hold API keys, OAuth tokens and service account credentials for a wide range of downstream integrations. Compromise of one server grants an attacker access to everything it proxies.
- No built-in security layer. The MCP spec delegates all security to the implementer, creating a gap that is already being exploited. Trend Micro research found almost 500 MCP servers publicly exposed with no client authentication or traffic encryption.
- Non-deterministic execution. AI agents select tools through natural-language reasoning. An attacker who manipulates a tool’s description or its returned content can redirect agent behavior in ways that static code analysis will not catch.
Common MCP Security Risks
The OWASP MCP Top 10 (Working Draft, 2025) catalogs the ten highest-risk categories for MCP deployments. The five most commonly exploited are detailed in this table:
| RISK | OWASP MCP ID | HOW IT WORKS |
|---|---|---|
| Tool Poisoning | MCP03 | An attacker embeds hidden instructions in tool metadata or descriptions; the agent executes harmful actions while believing it is following normal instructions. |
| Prompt Injection via Tool Output | MCP06 | Malicious content returned by a tool steers the agent to exfiltrate data, call unintended APIs or escalate privileges. |
| Token Mismanagement | MCP01 | Credentials stored in plaintext environment variables or passed through without audience validation expose secrets to log scraping and lateral movement. |
| Confused Deputy Attack | MCP02 / OAuth | A malicious MCP client exploits an existing consent cookie to obtain authorization codes for a third-party API without user approval. |
| Supply Chain Compromise | MCP04 | A server that appears safe at install time is later silently updated to exfiltrate data. Between January and February 2026, researchers filed over 30 CVEs targeting MCP components; 43% were shell injections. |
“While these are examples of the security threats that you see today, in a year or two, there are probably going to be a lot of different security threats out there. You should have a regular process to check for MCP server security threats.” Micah Spady, Director of Product Marketing at SecureW2
MCP Security Best Practices
The OWASP MCP Security Cheat Sheet and the official MCP spec converge on a consistent set of security controls:
- Enforce authentication. Require OAuth 2.1 with Proof Key for Code Exchange (PKCE) for all remote transports. Never bind an MCP server to 0.0.0.0 without an authentication layer.
- Apply least-privilege scoping. Assign each server only the permissions it needs and use separate credentials per server so a compromise stays contained.
- Sandbox and isolate. Run each MCP server in a container with restricted file system and network access.
- Verify supply chain provenance. Install servers only from verified sources, pin package versions, and treat tool schemas as potential injection surfaces.
- Log every tool call. Ship structured logs to a centralized Security Information and Event Management (SIEM) solution, and alert on sudden bursts of file writes, unusual outbound connections or scope-elevation events.
- Require human approval for destructive actions. Surface an explicit confirmation step before an agent executes any irreversible operation.
MCP Server Security After Deployment
Securing an MCP server is an ongoing process. Even if a server is deployed with best practices in place, changes like package updates, new tools and alterations in connected downstream services can introduce vulnerabilities.
New attack techniques may also emerge after the MCP server has passed the initial security review.
Security teams should continually monitor MCP servers for changes that may introduce new risks. MCP security reviews should include:
- Monitoring for new vulnerabilities: Track CVEs and security advisories impacting MCP servers, frameworks and connected tools.
- Reviewing permissions regularly: Remove unused tools, use short-lived credentials and revoke unnecessary access privileges. Verify each server still has only the access it requires.
- Monitoring for unexpected behavior: Monitor tool calls, file access, credential use and other activity for unusual behavior.
- Verifying changes: Treat updates to server code, dependencies, tool descriptions and schemas as potential security events. Review MCP server security when significant changes occur.
- Rotating and revoking credentials: Eliminate long-lived, static credentials and immediately revoke any credentials associated with compromised servers, users or workloads.
An MCP server that is secure when deployed can become a security risk later without continuous monitoring. Since MCP servers sit between AI agents and the systems they can access, a compromise can put connected credentials, systems and data at risk.
Related Terms
Frequently Asked Questions
Does MCP have built-in security controls?
No. The official MCP specification states explicitly that the protocol does not enforce security at the protocol level, so authentication, authorization and input validation must be added by the server operator or developer.
What is tool poisoning in the context of MCP security?
Tool poisoning is when an attacker embeds hidden instructions inside an MCP tool’s name, description or schema so that an AI agent executes harmful actions while believing it is following legitimate instructions.
What makes malicious MCP servers hard to detect?
A malicious MCP server can appear entirely legitimate at install time and later be silently updated to steal credentials or exfiltrate data, a pattern the security community calls an MCP rug pull attack.
How does a confused deputy attack work against an MCP server?
A confused deputy attack exploits an existing OAuth consent cookie to redirect a user’s authorization code to an attacker-controlled endpoint, granting the attacker access to downstream APIs without requiring fresh user consent.
What is the single most important MCP server security best practice?
Enforcing authentication and least-privilege scoping on every MCP server limits how far a breach can propagate across the full set of integrated services and credentials.
Securing AI agents and workloads?
SecureW2 issues short-lived, certificate-based identities to non-human and agent identities so every connection is authenticated. See how it maps to your stack.