Six MCP security risks drive real-world data exposure. Learn why protocol fixes alone fall short and how data-layer tokenization closes the gap.
Model Context Protocol (MCP) is the standard Anthropic introduced in late 2024 for connecting AI agents to external tools, data sources, and services.
Within months, it was adopted by Google, Microsoft, and OpenAI — and the adoption curve has not slowed since. MCP security is the practice of protecting these connections across three layers: the protocol itself, the runtime that executes tool calls, and the data that flows through every tool response.
MCP server security, in particular, has become a top concern for enterprise teams deploying AI data protection strategies.
This guide covers the six core MCP security risks enterprise teams face in 2026, explains the context-overload problem that no security vendor is talking about, and lays out a defence-in-depth framework for protecting MCP deployments.
The core argument: protocol-layer fixes and runtime monitoring leave a gap that only data-layer protection can close.
The shift from isolated LLMs to agent-plus-tool architectures happened faster than most security teams were prepared for.
Anthropic released MCP in late 2024, and adoption spread across every major LLM provider within the first half of 2025. Mend.io reports that more than 4,500 public MCP servers are now available for integration, with NPM installations exceeding 4.7 million per week by mid-2025 — and each one becomes a potential data exposure point inside the enterprise.
MCP security sits inside the broader category of agentic AI security. Every MCP risk is an agentic AI risk, but not every agentic AI risk is an MCP risk.
Agentic AI security covers the full agent workflow — reasoning, memory, identity, coordination. MCP security specifically addresses the integration layer where agents connect to tools.
Understanding this distinction matters because the controls differ: MCP security demands protocol-specific and data-flow-specific protections, while agentic AI security is broader in scope.
The IBM X-Force 2026 Threat Intelligence Index reports a 44% spike in AI-accelerated attacks. Recent audits cited in Datadog research found over 12,000 API keys and passwords exposed due to insecure MCP credential handling.
Securing MCP is no longer optional for organizations deploying agents with tool access — it is a core requirement for any modern data protection strategy.
MCP uses a client-server architecture. An MCP client sits inside the application that talks to the LLM — for example, Claude Desktop, Cursor, or an internal AI assistant.
MCP servers host the actual tools: database query functions, API wrappers, file system access, CRM connectors. Understanding this split is the foundation of MCP server security.
The flow is direct. A user makes a request. The client sends the request plus the available tool definitions to the LLM. The LLM decides which tool to call and with what parameters.
The client forwards that decision to the appropriate MCP server. The server executes the tool, returns the result, and the LLM generates a response for the user.
Every step in this chain is a potential point of data exposure — which is why securing MCP requires a different mental model than securing traditional APIs.
MCP servers run in one of two places, and the distinction drives everything else about how you secure them.
Local MCP servers run on a host you control — your laptop, a Kubernetes pod, a production VM.
Because they execute on infrastructure you manage, they can run OS commands, read local files, and interact with your network. That power creates code-execution risk, which is why organizations pairing data classification with MCP monitoring tend to catch anomalies faster.
Remote MCP servers run on third-party infrastructure. They cannot execute commands on your systems, but they still see the data you send them and return the data they retrieve.
The supply chain risk applies to both, but the attack surface differs: local servers expose you to RCE, while remote servers expose you to data exfiltration.
Enterprise teams evaluating a data security platform for MCP need to inventory which servers are local versus remote and apply appropriate controls to each.
The OWASP GenAI Security Project and the MCP specification itself identify a wide array of MCP attack patterns.
For enterprise security teams, these consolidate into six risks that drive real-world data exposure. Every major MCP security vendor — Red Hat, Datadog, Palo Alto, Docker — covers the first five MCP security issues. The sixth is the one most competitors miss.
Taken together, these MCP vulnerabilities define the MCP cybersecurity baseline every organization deploying agents needs to understand and act on through data-first protection.
Tool poisoning is when an MCP server's tool definitions contain malicious instructions — for example, a tool described as "fetch S3 buckets" that also includes a hidden instruction to delete any buckets it fetches.
These MCP vulnerabilities work because the LLM reads the tool definition as context and follows the hidden instruction.
Three variants exist, and they're often confused:
All three compound the broader data breach risks facing enterprises today.
Real-world attacks are already documented. Trail of Bits research demonstrated a tool poisoning attack that silently exfiltrates a user's entire chat history — including credentials, tokens, and intellectual property.
Mitigating these MCP security issues requires version pinning, signed tool definitions, and continuous monitoring for tool definition changes across every connected MCP server.
Data discovery on MCP tool responses provides a second line of defence by identifying what data is actually being exfiltrated when a poisoned tool executes.
Indirect prompt injection through MCP tool responses is a different class of attack than the prompt injection most teams already understand.
When an MCP tool returns data — from a website, an API, a document — that content enters the LLM's context as trusted input. An attacker who controls the external data source can embed adversarial instructions that redirect the agent's behaviour mid-task.
This is one of the MCP security issues that crosses the line between protocol risk and data protection risk. This attack is distinct from direct prompt injection because it arrives through a trusted channel.
The LLM has no way to know whether a tool response was crafted by an attacker. OWASP lists indirect prompt injection as LLM01 in its Top 10 for LLM applications.
Mitigation requires context isolation, input sanitization, and human-in-the-loop approval for sensitive actions — plus zero-trust principles applied to every tool response that your MCP server security controls can see.
The confused deputy attack exploits how MCP proxy servers handle OAuth flows with third-party APIs.
When an MCP proxy uses a static client ID with a third-party authorization server and allows clients to dynamically register with that same authorization server, an attacker can craft a malicious authorization request that reuses an existing consent cookie.
The result: the attacker receives an authorization code without the user ever seeing a consent screen. This pattern is a persistent MCP cybersecurity concern that OAuth 2.1 — and any well-architected data access control layer — was designed to address.
Token passthrough is a related anti-pattern and a commonly overlooked security failure on MCP servers. When an MCP server accepts tokens not issued to it and forwards them to downstream APIs, it bypasses audience validation and undermines accountability.
The MCP specification explicitly forbids token passthrough. Mitigation requires per-client consent storage, token audience validation, and OAuth 2.1 compliance across every access control decision and every data security management policy applied to MCP traffic.
MCP server configuration files — often stored at paths such as ~/.cursor/mcp.json — typically contain the API keys, database credentials, and service tokens that MCP servers need to perform their work.
Tool poisoning attacks can force an MCP client to read these configuration files and exfiltrate their contents. Of all the MCP vulnerabilities surfacing in 2025 and 2026, credential exposure in config files has produced the most measurable blast radius — which is why CISOs treating data security as a platform problem catch these incidents earlier.
The Datadog security research team cited audits uncovering 12,000+ API keys and passwords exposed through insecure MCP credential handling.
Local MCP servers that execute OS commands compound this risk — a compromised server can read SSH keys, cloud credentials, and environment variables.
Mitigation requires secrets management integration, no plaintext credentials in config files, runtime monitoring that alerts on suspicious file reads, and a defined MCP cyber security runbook for credential rotation when exposure is detected.
Related data access control policies determine which MCP servers can see which credentials in the first place.
Tool name collision happens when a malicious MCP server registers tools with names similar or identical to legitimate tools.
The LLM sees both versions in its tool list and may select the malicious one — the user sees no indication that anything is wrong.
Shadow MCP, a term Mend.io introduced in 2025, describes a related problem: employees installing MCP servers in their development environments without security team visibility. Both patterns feed the broader shadow data problem that enterprises have been fighting for years.
Both problems compound. Shadow MCP servers often use colliding names to shadow the "approved" servers that security teams have reviewed.
The shadow ecosystem mirrors the shadow IT and shadow AI patterns — each unauthorized deployment creates new data exposure points that IT cannot see, audit, or control.
Mitigation requires an MCP server allowlist, tool-name uniqueness enforcement, and inventory discovery across development environments.
Every MCP tool response that returns data from a CRM, database, file system, or internal API can contain sensitive information — PII, PCI, PHI, or proprietary intellectual property.
Once that data enters the LLM's context, it may be logged, sent to LLM providers for processing, cached in memory, or leaked through subsequent tool calls that cross trust boundaries.
No network proxy sees this exposure. The data flows through the MCP client's own process and into the LLM context directly. Traditional data loss prevention cannot intercept it.
Every new MCP connection widens compliance scope: a customer support agent with a CRM MCP connection processes PII; an agent with a payment system MCP connection processes PCI data; an agent with an EHR connection processes PHI.
This is the most common MCP security risk that receives the least attention from traditional data security platforms.
Context overload is different from prompt injection. Prompt injection is an attack. Context overload is a performance degradation that becomes a security risk when agents make worse decisions about sensitive data. No MCP security vendor covers this.
Published research quantifies it. And unlike most data-breach risks, context overload is invisible to traditional monitoring — the agent does not err; it just silently makes worse choices.
Every MCP tool an agent connects to consumes context-window tokens for its definition.
Tool definitions include the tool name, description, parameters, response schema, and usage examples — typically 200–500 tokens per tool.
Fifty MCP tools can consume 10,000–25,000 tokens before the agent starts reasoning about the actual task. This is the hidden cost of expansive AI data protection strategies that rely on plug-in-every-tool approaches.
That context competes with the task content. Published research on MCP tool overload shows that AI accuracy can drop from 87% to 54% when context fills with tool definitions. Milvus benchmarking research found that tool selection accuracy drops from 43% to below 14% as tool count grows.
These are not edge cases — they describe what happens in production enterprise agent deployments that connect to large MCP server ecosystems. The relationship between tool count and agent performance is the core dynamic that security teams need to understand.
Organizations add MCP tools to enhance agents' capabilities. More tools create worse agents.
More tools also create more attack surface, more aggregated credentials, and more opportunities for tool-name collisions.
The security impulse — add monitoring, add logging, add guardrails — typically means adding more tools, which further degrades the agent. This is where a coherent data security platform approach differs from a tool-sprawl approach.
Degraded agents are a security problem in their own right. An agent that selects the wrong tool 57% of the time may retrieve data it shouldn't, send data to wrong endpoints, fail to apply policy correctly, or hallucinate tool use when it should use a real tool.
Each failure mode creates a data exposure risk. Resolving the paradox requires tool consolidation, just-in-time tool exposure, context budget enforcement, and data-layer controls that protect sensitive data without requiring the agent to see more context.
Research and production deployments agree on the shape of the curve.
At 10 tools, agents operate near baseline accuracy and tool selection is reliable. At 25 tools, the first measurable degradation begins. By 50+ tools, tool selection accuracy falls below 50% — meaning the agent is more likely to pick the wrong tool than the right one.
This is a quantifiable data security concern that CISOs cannot ignore.
Enterprise agents regularly exceed 50 tools. A customer support bot might connect to CRM, email, order management, knowledge base, ticketing, and analytics MCP servers — each exposing 5–15 tools. A DevOps copilot can easily cross 100 tools across Git, CI/CD, monitoring, cloud, and secrets management integrations.
The failure modes in these deployments include wrong-tool selection (data leakage via tool-name collisions), missed-tool selection (the agent uses an LLM when it should use a tool), and confused parameter mapping (data sent to the wrong endpoints).
All three are security problems as much as performance problems, which is why zero-trust data controls matter more than ever as tool counts grow.
The modelcontextprotocol.io specification and OWASP guidance agree on the need for defence-in-depth. The three layers are protocol, runtime, and data.
Every mature MCP deployment needs controls at all three. The first two are table stakes. The third — inline data tokenization — is where most organizations have a gap.
Protocol-layer MCP security best practices start with OAuth 2.1 compliance.
MCP proxy servers must implement per-client consent storage — maintaining a registry of approved client IDs per user and checking it before initiating any third-party authorization flow.
Consent cookies must use the __Host- prefix with Secure, HttpOnly, and SameSite=Lax attributes. Redirect URIs must be exactly matched against registered URIs, with no pattern matching or wildcards. These controls sit alongside broader data security management policies that your security team already enforces.
Token passthrough must be explicitly prohibited. MCP servers must only accept tokens issued specifically to them; downstream forwarding of client-supplied tokens bypasses audience validation and breaks access control.
SSRF protection is equally important: MCP clients must block requests to private IP ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 169.254.0.0/16), enforce HTTPS for all OAuth-related URLs, and validate redirect targets.
Runtime controls protect the execution environment where MCP servers operate. Sandboxing local MCP servers limits their ability to execute arbitrary OS commands or access files outside their scope. Version pinning freezes tool definitions after audit, preventing rug pull attacks.
Continuous monitoring logs every tool call, tracks tool definition changes, and alerts on new MCP server installations. Together, these data security best practices form the second layer of MCP server security.
Credential management is a critical runtime control. Plaintext credentials in configuration files are an invitation for tool-poisoning-based exfiltration.
Integration with secrets managers (Vault, AWS Secrets Manager, or similar) ensures that credentials are fetched at runtime and never written to disk in readable form.
An MCP server allowlist — a registry of approved servers that security has reviewed — combined with continuous data security management blocks unauthorized Shadow MCP deployments before they create exposure.
Protocol-layer and runtime controls leave a gap: the data that flows through the MCP tool responses. Even with perfect OAuth flows, perfect sandboxing, and perfect credential management, a correctly permissioned MCP tool returns real sensitive data to the agent.
That data then persists in the LLM context, gets processed, cached, logged, and potentially sent to LLM provider APIs. This is the exposure that traditional data loss prevention tools were never designed to see.
Data-layer protection closes this gap. An MCP proxy — a security component distinct from the MCP client that handles tool integration — intercepts every MCP tool response, discovers and classifies sensitive data in real time, and tokenizes it before the agent sees it.
The agent receives functionally equivalent tokenised data; real PII, PCI, and PHI never enter the LLM context.
The benefits compound. Compliance scope shrinks because regulated data never reaches the agent's processing environment. The risk of context overload decreases because tokenized responses are often shorter and more consistent.
Credential aggregation risk decreases because even a compromised agent holds tokens rather than real values. Data-layer controls do not replace protocol-layer or runtime controls — they complete them. Vaulted tokenization is specifically designed for this pattern.
DataStealth is a data security platform that applies inline tokenization to MCP data flows.
It sits between the MCP client and upstream MCP servers, providing data-layer control that protocol- and runtime-based approaches miss.
The DataStealth MCP proxy transparently impersonates upstream MCP servers.
The MCP client connects to the proxy as if it were the original server — no code changes required to either the client or the upstream server.
The proxy forwards requests to the real MCP servers, intercepts their responses, applies DataStealth's data protection policies, and returns the processed responses to the client. This is the architectural pattern that closes the MCP server security gap every organization faces.
The proxy deploys as a federated SaaS layer that scales with your MCP adoption.
Whether you connect 10 MCP servers or 500, the architecture remains consistent: a single data security control plane, unified policy enforcement, and a centralized audit trail. Integration is measured in hours, not sprints.
Every MCP tool response that passes through the proxy is analyzed in real time by DataStealth's data discovery engine.
The engine classifies sensitive data based on content and context — identifying PII, PCI, and PHI, plus any custom sensitive data types your organization defines. Detected sensitive elements are tokenized inline before the response reaches the MCP client.
The agent processes tokenized data that preserves format and functional utility. Original sensitive values never enter the LLM context, never reach LLM provider APIs, and never propagate through subsequent tool calls.
Compliance scope contracts sharply: tokenized data is not regulated data, so PCI DSS scope shrinks, HIPAA controls simplify, and GDPR data residency requirements become manageable.
Dark data that would previously have surfaced uncontrolled in an MCP response is automatically classified and protected.
Protocol fixes and runtime monitoring cover part of the MCP attack surface. They do not stop sensitive data from flowing through tool responses into your LLM context. DataStealth closes that gap. Key capabilities:
Bilal is the Content Strategist at DataStealth. He's a recognized defence and security analyst who's researching the growing importance of cybersecurity and data protection in enterprise-sized organizations.
