Top 10 Risks of Using MCP Servers in IDEs

MCP-integrated AI systems might be vulnerable to prompt injection, where maliciously crafted input causes the LLM agent to perform unintended actions. Attackers can embed hidden instructions in code comments, documents, or other context data so that when the AI reads them, it overrides its legitimate instructions. This “context poisoning” can lead to the AI executing commands or divulging information that it shouldn’t, or creating deliberately malicious or vulnerable code in the application that would later serve as an entry point for the attacker.

Compromised MCP servers may log requests, capturing sensitive queries, documents, or conversation history. They could use this information to infer identities, business logic, or trade secrets. Misconfigured or untrusted MCP servers can also exfiltrate files or records without the user realizing. For example, a malicious document or chat message in a connected system (e.g. Slack or Drive) could trick an AI agent into retrieving and transmitting internal files to an attacker’s server. In enterprise settings, this risk is amplified by the sensitivity of data (source code, customer info, credentials) that developers handle.

Authentication and authorization weaknesses in MCP deployments present a serious risk. The MCP standard is still evolving its security model – currently, many MCP servers lack strong authentication by default. This means an MCP server (especially if mistakenly listening on a network port) could accept requests from any client, potentially allowing unauthorized access to your IDE or other connect software development tools. Moreover, lack of user identity propagation means MCP servers might connect to backend systems (code repos, issue trackers, databases) with shared credentials, not the individual user’s privileges. Without careful design, an AI agent could fetch data that a given developer shouldn’t have rights to see, simply because the MCP server was configured with an overly broad access token.

MCP servers often run with broad privileges, and if not properly constrained, they can perform powerful actions that may be abused. In local deployments, the MCP server inherits the user’s permissions – meaning it can read/write files, access internal networks, or even execute code with the same rights as the developer. This creates a wide blast radius if the AI agent is tricked into doing something nefarious. A key governance concern is how user consent and tool permissions are handled in IDE integrations. Some clients (e.g. Claude or VS Code extensions) prompt the user the first time a tool is used, but if the user selects “Allow all” or if the client reuses the initial grant, the AI can continue performing actions without further user oversight.

A malicious or badly configured MCP server might trigger recursive calls or expensive queries, leading to denial-of-service attacks or exhausting system resources.

By returning plausible yet incorrect results, MCP servers can either deliberately subtly distort decision-making processes, or overly rely on poorly prompted LLMs, leading to erroneous outcomes or failed operations, or simply bad quality of code.

When integrated with tools like file systems or databases, MCP servers might trigger unsafe plugin actions or cross-plugin injections, causing significant damage. For example, in a development context, an MCP might exploit Jira integration to open false tickets for bugs that don’t exist, or ones that encourage support engineers to input credentials for stealing.

A compromised MCP server can install harmful project rules, code, or logic within the IDE. These rules might corrupt workflows, compromise sensitive data, or disrupt essential functions in ways that are difficult to identify and trace.

MCP servers and clients often rely on open-source packages, community-developed connectors, or third-party services – introducing supply chain vulnerabilities. Using an unverified MCP implementation is akin to installing any other dependency from the internet, but with access to your code and IDE. A compromised or trojanized MCP package could inject malicious code into the development environment, since MCP servers run with substantial privileges. An attacker might publish an MCP server that claims to integrate with a popular tool (like Jira or GitHub) but actually contains backdoors or data-harvesting code. Even without overt malware, poorly maintained dependencies pose risks: an outdated library in an MCP server could have known exploits (like an old YAML parser leading to RCE). There’s also the risk of dependency confusion – if an internal MCP tool has the same name as a public package, a build or update system might pull the wrong one. Unofficial implementations are especially risky if they don’t undergo security review (many are new and have “minimal security review” to date).

Attackers can use methods like typo-squatting to fool users into using them instead of official ones from known vendors. Tool poisoning attacks use a malicious MCP server to seem legitimate to the client but embed hidden malicious instructions in the tool descriptions. The AI model “sees” those hidden directives and can be manipulated into actions like reading sensitive files or sending data to an attacker, all while the user only sees a benign tool name/description. Teams must therefore be extremely cautious about which MCP servers they integrate: prefer official or vetted servers, verify the source code if open-source, and consider running them in a restricted environment.