Model Context Protocol (MCP) servers provide a standardized way for AI agents to access enterprise databases, APIs, tools, and internal systems. As enterprise adoption of AI agents grows, securing MCP interactions has become an important part of agentic AI security.
Authorized MCP connections expand the range of actions agents can take. Agent adoption is also accelerating rapidly: 40% of enterprise apps are expected to feature task-specific AI agents in 2026, up from less than 5% in 2025.
As adoption grows, organizations need enterprise AI observability, governance, runtime protection, and clear control over MCP use, with accountability for agent actions. Watch for tool poisoning, indirect prompt injection, token passthrough attacks, local and remote code execution, and sensitive data exfiltration. The most useful controls are least-privilege access, input and token validation, sandboxed execution, and human approval gates.
MCP server security is the practice of protecting the Model Context Protocol ecosystem—including servers, tool interactions, agent activity, and runtime communications that connect AI agents to enterprise systems. It combines MCP server discovery, least-privilege access, input and token validation, sandboxed execution, and runtime approval gates to reduce risks like data exfiltration and unauthorized agent actions.
Key takeaways
- MCP servers are the connective layer for enterprise agentic AI. They give AI agents autonomous access to databases, APIs, and internal systems via a standardized protocol, and adoption is accelerating rapidly.
- Seven specific security risks warrant attention: sensitive data exfiltration, unauthorized agent actions, over-privileged agent access, supply-chain exposure, missing audit trails, privilege escalation, and shadow AI sprawl.
- Attackers exploit MCP-specific vulnerabilities including tool poisoning, indirect prompt injection, token passthrough, SSRF, server chaining, command injection, and the MCP sampling capability. All of these can lead to data exfiltration or unauthorized system actions.
- Continuous discovery of MCP servers, combined with real-time visibility into agent and tool activity, provides the context needed to govern and secure enterprise AI. Attribution then connects agent activity back to the initiating human identity.
Understanding MCP servers
Before working through the risks, it helps to know what MCP servers actually do inside your environment. This section covers the standard, the architecture, and the adoption signals that are pulling MCP into scope for security review.
What are MCP servers?
MCP is an open standard introduced by Anthropic that gives AI agents a consistent way to connect to external enterprise systems, including data sources and APIs. MCP provides a standard connection between AI agents and the external systems they need to access. Since its introduction, MCP has been donated to the Agentic AI Infrastructure Foundation (AAIF) and co-adopted by Anthropic, Block, OpenAI, Google, Microsoft, AWS, Cloudflare, and Bloomberg.
MCP servers let AI agents pull customer records from a CRM, update tickets in a project-management system, trigger automated workflows across departments, or generate and distribute financial reports.
Before MCP, every agent-to-system integration required custom code. MCP standardizes that connection, which is why adoption has accelerated so quickly—and why the security implications are so broad.
What MCP servers actually do
The architecture has three components: hosts (the AI application), clients (the connection managers), and servers (the programs that expose tools and data).
When an AI agent needs to query a database or update a CRM record, it uses an MCP tool call. The same structured requests can call external APIs, and the server executes each request and returns a response. The MCP server returns metadata via a tools/list call, and the client passes it directly into the LLM’s context window without built-in validation.
This metadata gives the tool’s name and description and defines its input schema. The arXiv MCP security analysis identifies this architectural decision as the root cause of tool poisoning. The LLM processes tool descriptions as natural-language instructions, so a maliciously crafted description can manipulate its behavior.
A single agent connected to multiple MCP servers can autonomously read files, write to databases, call external APIs, and modify enterprise systems—all via a single, consistent protocol.
You Can’t Secure What You Can’t See
WitnessAI gives you network-level visibility into every AI interaction across employees, models, apps, and agents. One platform. No blind spots.
Explore the PlatformWhat makes MCP servers a security problem
MCP servers standardize how agents access enterprise resources, but they don’t natively provide the level of compliance, audit, and accountability controls most enterprises require. You should focus on seven MCP-server risks.
1. Sensitive data exfiltration through tool calls
MCP workflows can carry sensitive enterprise data such as credentials, API keys, customer PII, and session tokens whenever agents interact with systems that process it.
Adversaries embed malicious instructions in tool schemas that agents trust as authoritative, exfiltrating data through seemingly legitimate tool usage. OWASP catalogs this as MCP03:2025 Tool Poisoning. Schema poisoning, which involves tampering with the definitions governing agent-to-tool interactions, can map a benign-sounding operation to a destructive action.
A real-world proof-of-concept by Invariant Labs demonstrated this against production MCP servers: a malicious server shared context with a legitimate WhatsApp MCP server, instructing the agent to read the user’s message history and send it to an attacker-controlled number. No user prompt was required, and the poisoned description looked benign in tool review interfaces. A companion attack on GitHub MCP servers exfiltrated private repository contents using the same technique.
Praetorian MCP research documents the mechanism: tool descriptions demand as much data as possible, exploiting the LLM’s drive for quality output. The agent then passes complete sensitive datasets as tool arguments, which the malicious server relays to an attacker-controlled endpoint.
2. Unauthorized actions from compromised tool responses
When an agent calls an MCP tool and receives a response containing embedded malicious instructions, it may treat that response as trusted input and execute unintended actions, such as modifying records or initiating transactions.
This indirect prompt injection vector is compounded when command injection flaws exist in the server implementation. Equixly security assessments found that 43% of tested MCP server implementations contained command injection flaws that allowed remote code execution.
Specific CVEs confirm the real-world scope: CVE-2025-49596 (RCE in Anthropic’s MCP Inspector), CVE-2025-53107 (CVSS 7.5 in git-mcp-server), and a command execution flaw affecting 200,000 exposed MCP servers documented in May 2026, with LiteLLM CVE-2026-30623 patched in v1.83.7-stable and fixes shipped by DocsGPT, Flowise, and Bisheng.
3. Over-privileged agent access with no scope enforcement
Without careful permission scoping, agents can gain elevated access to databases, infrastructure commands, and other sensitive operations—far beyond what their tasks require.
The official MCP specification recommends that servers implementing local transports use the stdio transport to limit access to just the MCP client, and restrict HTTP transports with authorization tokens or unix domain sockets.
However, the spec explicitly warns that without proper sandboxing and consent requirements, a range of attacks becomes possible. Locally hosted MCP servers run as processes on the host machine with user-level privileges. A compromised local server can execute arbitrary commands, access local files, install malware, and exfiltrate data. As described in Praetorian’s MCP research, it can appear to provide legitimate productivity features throughout this activity.
Path traversal is a common sign of over-privileged access: 22% of MCP implementations allowed access to files outside intended directories, and a separate Endor Labs analysis found that 82% of MCP implementations use file operations prone to path traversal.
4. Supply-chain exposure from untrusted MCP servers
Anyone can publish an MCP server. AI supply chain threats can open arbitrary command-execution holes through insecure configurations, and even established vendors aren’t immune.
Supply-chain attacks on MCP servers can also operate at the OAuth layer. The MCP security best practices documentation shows that OAuth authorization URLs from malicious MCP servers can exploit client-side URL-handling vulnerabilities and lead to cross-site scripting (XSS) and remote code execution.
The specification further requires that consent state cookies be set only after user approval. If they are set before consent, an attacker can bypass the consent screen entirely by crafting a malicious authorization request.
Server-side request forgery (SSRF) is another prominent supply-chain risk: Equixly found 30% of popular MCP implementations were vulnerable to SSRF via unrestricted URL fetching, while BlueRock Security found 36.7% vulnerable to SSRF across more than 7,000 servers. SSRF in Markdownify MCP Server (CVE-2025-5276) is a documented instance of this class of vulnerability.
5. No audit trail connecting agent actions to human accountability
MCP deployments can leave an accountability gap when organizations lack an identity layer that connects agent activity back to the human who initiated the workflow.
This gap is particularly acute at scale: the NimbleBrain MCP security report queried the official MCP registry at registry.modelcontextprotocol.io in March 2026 and collected 8,074 total entries across 3,012 unique servers. That footprint is difficult to audit manually. Without automated attribution, tracing a compromised or misbehaving agent connection back to its initiating identity becomes difficult.
6. Agent-to-agent privilege escalation
Multi-agent AI architectures introduce a compounding risk: a compromised agent can escalate privileges across other agents via prompt-injection attack chains. The arXiv MCP security analysis and MDPI research on malicious remote MCP servers describe how one MCP server can shadow another across servers.
In these patterns, a compromised agent in a multi-agent pipeline can manipulate downstream agents’ context windows by injecting instructions that persist through orchestrated workflows.
MCP server chaining compounds this risk further. Praetorian defines the attack explicitly: a malicious local MCP server intercepts data flowing through a legitimate, trusted remote MCP server (such as an official Slack or Google Drive integration). The attack uses data that passes through the authorized integration. The malicious server sits as a machine-in-the-middle between the agent and trusted downstream systems.
7. Shadow AI sprawl
Shadow AI sprawl multiplies every other risk on this list. Engineering teams can spin up MCP server connections without security review.
These connections create blind spots where the above risks can occur undetected. With more than 10,000 active public MCP servers, the surface area for unauthorized, unreviewed connections has grown dramatically.
How Many AI Apps Are Running on Your Network Right Now?
WitnessAI discovers every AI application and agent across your environment, applies intent-based policies, and creates audit trails. No SDKs or endpoint clients required.
See WitnessAI For ApplicationsAdditional MCP attack vectors
Security reviews also need to cover three attack surfaces that are easy to overlook. Each one sits outside the standard tool-call path, which is why they often escape a first-pass review.
Token passthrough and the confused deputy problem
The MCP security best practices specification defines two closely related OAuth-layer attacks. Audience validation failures occur when an MCP server doesn’t verify that tokens were specifically intended for it, for example via the audience claim specified in RFC9068, and accepts tokens originally issued for other services. This breaks a fundamental OAuth security boundary.
Token passthrough adds another problem. An MCP server may accept a token with the wrong audience and forward it unchanged to a downstream service. The downstream API may then trust the token even though the MCP server never checked it, or assume upstream validation happened. In this “confused deputy” scenario, attackers can reuse legitimate tokens on services that never authorized those tokens.
MCP sampling as an attack vector
MCP sampling lets servers proactively request LLM completions from the client. That reverses the normal interaction pattern and creates a distinct attack surface. Palo Alto Unit 42 describes the flow: when a server needs LLM capabilities, it initiates a sampling request to the client, the client invokes the LLM with the server’s prompt, receives the completion, and returns the result to the server. A malicious MCP server can exploit this to manipulate LLM outputs without direct user visibility.
Red Hat’s controls guidance explicitly identifies sampling exploitation as a risk to mitigate. The official MCP specification states that a human should always be able to deny sampling requests.
Applications SHOULD provide UI that makes it easy and intuitive to review sampling requests, allow users to view and edit prompts before sending, and present generated responses for review before delivery. The specification requires these human approval gates.
Arbitrary file execution via init-hook exploitation
Praetorian’s research documents a covert payload delivery mechanism that exploits a common software initialization pattern. MCP servers can implement mandatory “init” tools that all other tools check before executing.
When invoked, the init tool fetches content from a configured URL and opens it using the system’s default application handler. This behavior resembles routine setup and can covertly deliver arbitrary payloads. Because it occurs during legitimate initialization, this attack path may run before controls focused on runtime tool calls are active.
Runtime AI Threats Need Runtime Defense.
WitnessAI’s enterprise AI firewall delivers bidirectional runtime defense, blocking prompt injections, jailbreaks, and data exfiltration before they reach your models or your customers.
Explore ProtectHow to address these 7 MCP server security risks
The seven risks above share three underlying gaps: incomplete visibility, insufficient governance, and inadequate runtime protection. The controls below close those gaps across three tracks—visibility and inventory, attribution and tool-call protection, and intelligent policies. If your security team is already leading AI evaluations, this list extends that work rather than replacing it.
Visibility and inventory
Start with a live picture of what’s actually running before you try to control it. Maintain a living inventory of every MCP server, including deployments that haven’t undergone security review. With MCP servers now present in 80% of enterprise environments, manual tracking is insufficient.
From there, gain real-time visibility into agent activity across APIs, IDEs, native applications, and MCP connections, and automate discovery at the network layer so you can parse traffic and distinguish standard chat from autonomous agent activity. Apply audience claim validation to every token the MCP server receives, verify that tokens were specifically issued for that server per RFC9068 requirements, and never forward unvalidated tokens to downstream services.
Attribution and tool-call protection
Once you can see agent activity, tie each action to a human and inspect it before it executes. Attribute every agent action to a human identity and capture immutable audit trails, then detect and block unauthorized actions before execution by inspecting MCP tool calls and parameters in real time.
Enforce human approval gates for sampling requests so users can review, edit, and deny server-initiated LLM calls before they execute, as the MCP specification mandates. Validate tool responses as well as requests, and inspect response payloads for embedded malicious instructions before the agent acts on them.
Intelligent policies and unified governance
Static allow/deny patterns break down once agents start chaining tools, so use policy that understands intent. Intent-aware enforcement reads context rather than relying on static patterns, and applying the same policy framework to humans and agents through unified governance lets you enforce least-privilege scoping at the individual tool level rather than at the server level.
Maintain an allow-list of approved MCP servers and tools, and block agent connections to unreviewed or unauthorized servers before tool calls execute.
Blocking AI Isn’t a Strategy. Governing It Is.
WitnessAI enforces intent-based policies, routes prompts to the right models, and redacts sensitive data in real time so your teams keep moving while your data stays protected.
Explore ControlHow WitnessAI addresses MCP server security risks
The implementation principles above map directly to the visibility, policy, runtime protection, and testing capabilities below.
WitnessAI is a unified AI security and governance platform that provides observability, intelligent policy enforcement, runtime protection, and proactive validation across enterprise AI:
- Observe—discovery and visibility across MCP servers, tools, and agentic activity. It provides real-time awareness of every agent connection and tool call across your environment.
- Control—intelligent policy enforcement based on identity, context, and intent, with allow-list governance of approved agents, tools, and MCP servers. WitnessAI Agentic Control (launched June 17, 2026) allows pre-execution blocking of unauthorized tool calls. Agents can invoke only explicitly approved tools. The live WitnessAI MCP Catalog provides a verified, continuously updated inventory of MCP servers that security teams can use to build and maintain allow-lists. This directly addresses the shadow AI and supply-chain risks.
- Protect—runtime defense for prompts, tool calls, and responses, with inspection of both inbound tool calls and outbound tool responses to detect and block embedded malicious instructions before agents act on them.
- Witness Attack—proactive testing before deployment, which validates that MCP server integrations don’t introduce tool poisoning, injection, or over-privilege risks before they reach production.
WitnessAI combines network-level observability and tool-access governance with lightweight API-based runtime protection for custom enterprise agents. It delivers a full agent-action audit trail that connects every tool call back to the initiating human identity.
Getting started with your MCP server security
MCP servers now appear across 80% of enterprise cloud environments. Equixly has documented command injection and SSRF vulnerabilities in real-world implementations.
Its findings also cover path traversal, while OWASP has cataloged tool-poisoning risks. Before expanding deployment, inventory MCP connections, assign human identities to tool calls, validate token audiences, and test approval gates. Build AI governance strategy alongside adoption so these controls remain consistent as agent use grows.
Request a demo to see how WitnessAI provides observability, governance, runtime protection, and policy enforcement across MCP servers, tools, and enterprise AI agents.