Model Context Protocol (MCP) is opening up tremendous efficiency and automation as a standard way to connect AI agents with external data, tools, and APIs. The protocol has quickly gained substantial adoption, but at the same time, it’s opened up a new attack surface, combining familiar software security problems with newer AI-native risks that AI and security engineers are just starting to unravel.
Zuplo’s State of MCP Report, released in early 2026, found that confidence in MCP is high, but security and compliance concerns were the top issue preventing increased MCP use. On the builder side, security and access control complexity is similarly the top challenge when developing MCP servers. The report also found that 58% of MCP builders are wrapping existing APIs, which means MCP inherits classic API security problems on top of the new AI-native ones.
Researchers have pointed to MCP vulnerabilities like prompt injection, tool poisoning, jailbreaks, rug pulls, sensitive data leakage, and others. Although MCP security awareness is improving, plenty of implementations still lack the proper access control, credential management, capability scoping, or monitoring to safeguard MCP usage.
The growth of MCP is cause for concern as the volume of agentic-based actions continues to grow. Below, we’ll look at some of the most common flaws within MCP ecosystems. We’ll cover the risks they cause and offer general mitigations on how AI engineers and security teams should respond.
1. Credential mismanagement
A top flaw in MCP ecosystems is poor key and token practices, which can quietly undermine security. When Astrix analyzed 5,200 open-source MCP server implementations, it found the credential layer in rough shape.
88% of servers require credentials, but only 8.5% use OAuth. The majority, 53%, lean on static API keys or personal access tokens (PATs), and 79% of those keys are passed through plain environment variables.
That matters because API keys make poor security tokens. They are long-lived, they leak through logs and telemetry, and a stolen one keeps working until someone notices and rotates it. For this reason, OWASP’s emerging top ten list for MCP, currently in beta, ranks token mismanagement and secret exposure (MCP01) as the number one threat facing MCP ecosystems.
Long-lived credentials might be hardcoded in configurations or leaked into logs, telemetry, memory, or other areas an agent can later access. OWASP states that attackers might attempt to retrieve tokens using prompt injection or debugging traces.
The risks:
- Exposure to sensitive data
- Privilege escalation
- Compromise of connected systems
The mitigations:
- Avoid hardcoding secrets or leaving them in development environments
- Don’t solely rely on API keys for upstream servers
- Abstract MCP access with a layer for proper authentication, token handling, and credential rotation
2. Overpermissioned access
According to IBM’s 2025 Cost of a Data Breach Report, 97% of organizations that reported an AI-related security incident lacked proper AI access controls. Where MCP is concerned, poor identity, access, and permission boundaries can pose serious threats. Agents often have overpermissioned access to MCP tools, meaning that they have excessive privileges and scopes, breaking a least privilege or zero-trust strategy.
MCP ecosystems typically involve many agents, servers, and clients. In this environment, it’s easy for identity and scopes to slip. Sometimes access is broad or not enforced properly, or at all.
Insufficient authentication and authorization is a recurring pain in the MCP space. In Bloomberry’s analysis of 1,400 MCP servers, nearly 40% required no authentication at all, meaning anyone who could reach the server could enumerate and call its tools.
With poor access control and broad scopes, malicious actors that gain access to one system can in effect elevate their privilege elsewhere. When agents have excessive scopes to MCP tools, an attacker could leverage this to perform unintended actions. Alternatively, a large language model (LLM)-powered agent with excessive permissions could take unintended wide-ranging actions on its own accord, behaving as an insider threat.
The risks:
- Malicious actors performing unintended actions
- Critical attack paths to connected systems
- Insider LLM-generated risks
The mitigations:
- Sharing highly scoped MCP tools internally, with granular permissions by user, team, agent, or environment
- Applying just-in-time access and elevating permissions at execution time
- Routing MCP access through an approved compliant gateway
3. Shadow servers
Public MCP directories now catalog over 20,000 public MCP servers. And, as developers begin configuring, using, and even spinning up their own multiple MCP servers, the likelihood for some to fall outside the purview of accepted, governed IT tools is quite high. Due to the variance of MCP servers in use today, some are saying MCP sprawl is the new shadow IT.
Without a proper MCP catalog, you lose the ability to formally inventory which servers, tools, and services developers and agents are using. This flaw can manifest as unsafe resource consumption, unrestricted rogue tool use, or unmanaged access to sensitive systems. Rogue or unmanaged MCP servers can also pose a threat if vulnerabilities are not tracked and patched over time.
The risks:
- Rogue tool use outside of governed IT
- Unpatched vulnerabilities
- Potential for credential leakage or compromise
The mitigations:
- Having a centralized registry to visualize what MCP servers are in use
- Generating “approved” versions of MCP servers for developers to use
- Using an MCP gateway to direct, govern, and limit internal MCP tool use
- Requiring approval workflows for adding new MCP servers or tools
4. Poor visibility
Another security fault in MCP ecosystems is missing telemetry into how MCP servers are being used. This includes what tools were called, by what agent, within what department, at what time, and so on. Beyond tool invocations, important telemetry includes changes made to context and tools as well.
The aforementioned Bloomberry research put the median server at five tools, with most clustered in the 1-to-9 range and a long tail running to 19 or more. Multiply even a modest per-server count by the number of servers wired into a single environment, and you are quickly managing hundreds of tools. Lacking deep observability into tool-level use can hinder debugging or auditing flows.
The visibility issue is not isolated to MCP. Really, it’s a concern for AI systems at large. According to Teramind’s The Shadow AI Behavior Report, 86% of organizations have no visibility into how data moves to and from AI tools.
The risks:
- Poor auditing trails
- Failure to meet compliance requirements
- Unoptimized use of resources
The mitigations:
- Including runtime governance as part of your MCP control plane
- Continually auditing and cataloging the use of MCP servers to ensure visibility
- Using observability traces to inform debugging and auditing efforts
5. Context poisoning
Another big area of risk for MCP is when an attacker is able to tamper with the tools, context, or prompts that an agent relies on. One example is tool poisoning, in which malicious instructions are embedded within MCP tool descriptions or outputs in order to manipulate model behavior. These poisoned instructions might be invisible to the user but allow the attacker to steer the model toward unauthorized actions.
In 2025, researchers at Invariant Labs demonstrated that an attacker could exfiltrate data from a WhatsApp MCP server in an agentic system by using a malicious MCP server to hijack the agent into leaking the user’s context. The setup leveraged a malicious tool that, in effect, poisoned the context the agent depended on.
Without any input validation on the prompts, tools, or context an agent has access to, an adversary could steer an agent away from its original goal and toward the attacker’s intent, a manipulation OWASP’s agentic threat taxonomy calls “intent breaking and goal manipulation.” Context injection could also pollute shared memory, sessions, or other context that the agent relies upon.
The risks:
- Manipulation of agents
- Disruption of user intent
- Nuanced targeted attacks
- Incorrect or falsified information
The mitigations:
- Validate, filter, and constrain untrusted context before it reaches agentic systems
- Runtime monitoring to continually parse and detect malicious abuse
- Generating highly scoped MCP servers that in effect limit tool accessibility
- High-grade access controls on context storage and access to prevent tampering
6. Unsafe tool execution
Command injection and execution can arise when an MCP server or agent uses untrusted input to run shell commands, scripts, API calls, or queries without proper validation or sanitization. In severe cases, this can lead to remote code execution (RCE), one of the worst cybersecurity vulnerabilities due to the damage that can be caused with direct system access.
As the NSA says in its guidance on MCP security, “MCP’s rapid proliferation has outpaced the development of its security model.” Its flexible design has allowed innovation but at the cost of introducing ambiguity on how to use it safely. For instance, the agency specifically highlights arbitrary code execution (ACE) as a top pressing concern.
Independent researchers have discovered RCE vulnerabilities present within many MCP server environments. For instance, 2025 research from Equixly found that 43% of MCP servers have command injection vulnerabilities. While RCE vulnerabilities are not as common as when MCP was first introduced, they’re still a pressing threat.
The risks:
- Remote code execution style attacks
- Completely compromised systems
- Data exfiltration
- Role elevation
The mitigations:
- Diligent validation and sanitization of all input
- Governance into all context and data fed into agentic systems
7. Supply chain risks
MCP servers are now distributed and installed at the scale of a mature package ecosystem. PulseMCP’s tracking shows local servers pulled tens of millions of times in a single recent month, the kind of volume that makes registries an attractive target. Most of those installs arrive with no vetting at all. As such, this introduces classic supply chain issues, like typosquatting, in which developers accidentally download malicious code from package managers.
OWASP includes software supply chain attacks on its in-progress list of MCP threats. As OWASP describes, a software supply chain style attack in an MCP ecosystem could alter an agent’s behavior, or introduce execution-level backdoors. An untrusted MCP server could also change after approval, exposing new tools or altering tool descriptions, which could compromise a system.
The risks:
- Altered agentic behavior
- The creation of backdoors and rug pulls
- Unsafe or unapproved tool execution
The mitigations:
- Careful analysis of new downloads within MCP ecosystems
- Centralized tooling catalogs with approval workflows for new MCP servers
- Code scanning and validation to spot malicious injection
How an MCP Gateway Closes These Gaps
MCP is here to stay. And with it comes a mix of familiar security problems and novel AI-native threats. As such, cybersecurity needs a response that is up for the task. Thankfully, many risks are being minimized by emerging strategies as well as new platforms to reduce the risk of enterprise MCP adoption.
For example, Zuplo’s aforementioned MCP report found that companies are most commonly using a gateway when hosting their MCP servers. Just as it’s common practice to abstract APIs with a gateway layer for safe access, it’s becoming standard practice to use an MCP gateway to secure access to underlying MCP servers.
By using an enterprise-grade MCP gateway, users can quickly mitigate many of the risks above, especially around secrets, authentication, authorization, monitoring, and tooling governance, that naturally arise when scaling MCP in practice. As such, it’s worth considering how an MCP gateway can untangle the MCP sprawl you might find yourself in.