Cursor MCP lets the Cursor AI editor connect to external tools and data through the Model Context Protocol, and while that unlocks powerful workflows, every MCP server you add is code and instructions your AI agent will trust, which makes vetting them a genuine security requirement. The Model Context Protocol is an open standard (originated by Anthropic) for exposing tools, resources, and prompts to AI clients. Cursor's implementation reads server definitions from an mcp.json config and lets the model invoke those servers during a session. The security problem is structural: the agent acts on tool descriptions and tool output it cannot fully verify, and a hostile or compromised server can turn that trust against you. This guide explains the attack surface and how to reduce it.
By early 2026, MCP security had moved from theoretical to documented. Security researchers, OWASP, and national security agencies published guidance on a recurring set of failure modes, and multiple MCP-integrated platforms, Cursor among them, have had security issues disclosed. Understanding the patterns matters more than memorizing any single advisory.
How Cursor MCP works
You register MCP servers in Cursor's configuration, typically an mcp.json file. Each server exposes tools with names and natural-language descriptions. When you chat with the agent, Cursor sends those tool descriptions to the model, and the model decides when to call a tool and with what arguments. Servers can run locally over the STDIO transport (Cursor launches a process) or remotely over HTTP.
{
"mcpServers": {
"example": {
"command": "npx",
"args": ["-y", "some-mcp-server"]
}
}
}
That small config carries a lot of trust. Cursor will launch the process, the model will read the server's tool descriptions as authoritative, and it may pass those tools your files, environment, or credentials. Two things follow: the server's code runs on your machine, and its tool descriptions influence the model's behavior. Both are attack vectors.
Tool poisoning: the signature MCP attack
The defining MCP risk is the tool poisoning attack. A malicious server embeds hidden instructions inside a tool's description, text the model reads but that is not clearly surfaced in the UI. Because the model treats tool descriptions as trustworthy context, those instructions can steer it into actions you never asked for.
Researchers have demonstrated poisoned tool descriptions that instruct the agent to read sensitive local files, such as the mcp.json config itself (which may hold credentials for other servers) or SSH keys, and send their contents to an attacker-controlled endpoint, all while the visible tool appeared to do something benign. The agent complies because, from its perspective, following the tool description is the job.
This is not a bug in one server; it is a consequence of the model trusting text it was given. The defense is to never connect a server you have not vetted, and to assume any server's descriptions could be adversarial.
Prompt injection through tool output
Related to tool poisoning is prompt injection through the data a tool returns. If an MCP server fetches web content, reads a file, or queries an issue tracker, the returned text enters the model's context. Attacker-controlled content in that data (a crafted README, a malicious comment in a fetched page) can carry instructions the agent then acts on. This was documented as a structural risk of the protocol in 2025 and remains one: the model cannot reliably tell "data to process" from "instructions to follow" when both arrive as text.
The practical implication for Cursor MCP: a server that reads untrusted external content widens your prompt-injection surface every time the agent uses it.
Cross-server contamination
When you connect several MCP servers to the same Cursor session, they share the agent. A malicious server can poison its descriptions to exfiltrate data accessible through a different, trusted server, or to override the instructions of other servers. This means the security of your setup is only as strong as the least-trustworthy server you have connected. One bad server compromises the session, not just its own tools.
Local command execution risk
The STDIO transport launches a local process and exchanges data with it. Disclosed issues in MCP tooling have shown that improperly sanitized configuration or parameters passed toward a host shell can lead to command execution on the machine running the client. The takeaway is not a single patch level; it is that STDIO servers execute with your privileges, so treat installing an MCP server the same way you treat running any untrusted binary: only from sources you trust, pinned to known versions.
Authorization gaps on remote servers
The MCP authorization spec defines an OAuth 2.1 framework but leaves authentication optional. Internet scans have found large numbers of publicly reachable MCP servers responding to unauthenticated requests. If you connect to a remote MCP server, confirm it actually requires authentication and runs over TLS. An unauthenticated remote server is exposed to anyone who can reach it, and connecting to one can pull attacker-influenced data into your agent.
A hardening checklist for Cursor MCP
- Vet every server before adding it. Read the source, check the publisher, and prefer well-known, maintained projects. An unvetted MCP server is arbitrary code plus adversarial instructions.
- Pin versions. Do not let
npx -ysilently pull the latest of an untrusted package. Pin to a reviewed version and treat updates as code changes. - Minimize connected servers. Fewer servers means a smaller cross-contamination surface. Connect only what a given task needs.
- Keep secrets out of reach. Do not store credentials in files the agent can casually read; scope tokens narrowly so a leaked one has limited blast radius.
- Be cautious with servers that ingest untrusted content. Anything that fetches web pages or reads external documents raises your prompt-injection exposure.
- Review actions before they execute. Use Cursor's approval prompts rather than auto-approving tool calls, especially for file writes and shell commands.
The same principle underlies all of these: an MCP server is a supply chain dependency with an unusual property, which is that it also injects instructions into your AI agent. Treating MCP servers with the scrutiny you apply to any dependency is the core discipline. An SCA tool such as Safeguard can help track which packaged MCP servers you have pulled in and flag known-bad ones, and our deeper writeup on the Cursor IDE security model covers the editor's broader trust boundaries. The Safeguard Academy has material on securing AI-assisted development workflows.
FAQ
Is Cursor MCP safe to use?
Cursor MCP is safe to the extent that the MCP servers you connect are trustworthy. The protocol has the agent act on tool descriptions and tool output it cannot fully verify, so a malicious or compromised server can manipulate the agent. Vet every server, pin versions, and connect only what you need.
What is a tool poisoning attack in MCP?
A tool poisoning attack hides malicious instructions inside an MCP tool's description, which the AI model reads and treats as authoritative but which are not clearly shown to the user. Demonstrated attacks have used this to make agents read and exfiltrate credentials and SSH keys. The defense is to only connect vetted servers.
Can a malicious MCP server affect my other connected servers?
Yes. When multiple servers share a Cursor session, a malicious one can poison its tool descriptions to exfiltrate data reachable through a trusted server or override other servers' instructions. Your setup is only as secure as the least-trustworthy server connected, so minimize how many you connect.
How do I connect MCP servers to Cursor safely?
Read and vet each server's source, install from trusted publishers, pin exact versions instead of auto-pulling the latest, keep credentials out of files the agent can read, verify that remote servers require authentication over TLS, and use approval prompts rather than auto-approving tool calls.