AI & Developer Tools
What are the security risks of MCP servers?
MCP (Model Context Protocol) servers are external services that AI coding agents connect to, giving them access to tools, data sources, and APIs. The security risk: developers can connect their AI agents to any of the 13,000+ MCP servers launched on GitHub in 2025 without IT approval or visibility. Each connection creates a potential data exfiltration path, supply chain compromise vector, or unauthorized access channel that traditional security tools cannot see.
What Is / Definition
The Model Context Protocol (MCP) is a standard that allows AI coding agents — such as Claude Code, Cursor, and Windsurf — to connect to external tools and services. An MCP server is any service that exposes capabilities through this protocol. Think of it as a plugin system for AI agents: an MCP server might give an agent access to a database, a file storage service, a Slack workspace, an internal API, or a code repository. The ecosystem has grown rapidly. Over 13,000 MCP servers were published on GitHub in 2025 alone. Developers use them to extend their AI agents' capabilities — connecting them to Google Drive for document access, to databases for query execution, to monitoring tools for log analysis, and to deployment services for infrastructure management. The security concern is structural. Unlike traditional SaaS integrations that go through IT procurement and security review, MCP server connections are configured by individual developers on their local machines. There is no centralized approval process. There is no visibility for security teams. A developer can connect Claude Code to an unvetted MCP server in seconds, granting it access to sensitive data and internal systems. MCP servers run with the permissions of the AI agent, which typically inherits the developer's own access. This means a compromised or malicious MCP server can potentially access anything the developer can — source code, environment variables, API keys, internal documentation, and customer data. The protocol itself does not enforce authentication, sandboxing, or permission scoping by default. Security depends entirely on the implementation of each individual MCP server — and with 13,000+ servers of varying quality and provenance, that is not a reliable assumption.
Why It Matters
MCP servers matter for security teams because they represent an entirely new class of shadow IT that existing tools cannot detect. Traditional shadow IT involved employees using unauthorized SaaS applications — something network monitoring and CASB tools could at least partially address. MCP servers operate differently. They are configured locally on the developer's workstation, often through a JSON configuration file. The connection between the AI agent and the MCP server may use local sockets, HTTP, or stdio — none of which generate the network signatures that existing security tools look for. The risk scenarios are concrete. A developer connects an MCP server that provides database access. The AI agent, following instructions from a prompt injection embedded in a repository, queries the database and includes sensitive data in its output. The developer does not notice because the agent's actions are mixed in with legitimate code generation. Or consider a malicious MCP server that impersonates a legitimate tool — it provides useful functionality while silently exfiltrating environment variables, SSH keys, or API tokens. The scale compounds the problem. With 13,000+ MCP servers available, the ecosystem is too large for manual security review. New servers appear daily. Many are open-source projects maintained by individuals, with no security audit, no update cadence, and no accountability for vulnerabilities. For security teams, the question is straightforward: do you know which MCP servers your developers have connected to their AI agents? For most organizations, the honest answer is no — and they have no mechanism to find out using their current tooling
How It Works
MCP server security risks manifest through several specific mechanisms. Configuration and connection. Developers add MCP servers to their AI agent's configuration file — typically a JSON file stored locally on their machine. This configuration specifies the server's location (local process, URL, or socket) and what capabilities it exposes. No IT approval is required. No security scan is triggered. The connection is live immediately. Permission inheritance. An MCP server operates with the permissions of the AI agent process, which runs as the developer's user account. This means the MCP server can access the local filesystem, read environment variables (including API keys and tokens), execute shell commands, and make network requests — all with the developer's full privileges. Data flow risks. When an AI agent connects to an MCP server, data flows in both directions. The agent sends context — including source code, file contents, and conversation history — to the server. The server sends back responses that the agent incorporates into its work. A malicious server can harvest the context it receives, exfiltrate sensitive information, or return manipulated responses that inject vulnerabilities into generated code. Supply chain attacks. MCP servers can depend on third-party packages, just like any other software. A compromised dependency in an MCP server affects every developer who has it configured. Unlike npm packages that might be caught by CI/CD scanning, MCP server dependencies are installed and run locally with no pipeline visibility. Lack of runtime monitoring. EDR solutions do not distinguish between legitimate MCP server activity and malicious behavior. The AI agent process is trusted. Its network connections are expected. There is no baseline for what "normal" MCP server behavior looks like, making anomaly detection ineffective without purpose-built tooling.