Cursor AI Security: MCP Security, Data Security and Enterprise Controls for Cursor Agents
Two Cursor vulnerabilities scored CVSS 9.8 and needed no click at all. Both started as prompt injection and ended as code running outside the sandbox, with your developer's privileges.
Direct answer
Cursor AI security has three distinct layers, and most teams only look at one of them. The first is the product itself: in June 2026 two critical vulnerabilities were published against Cursor, CVE-2026-50548 and CVE-2026-50549, both scored CVSS 9.8, both allowing prompt injection to escape Cursor's sandbox and run code on the developer's machine with no user interaction. Cato AI Labs named the pair DuneSlide, and Cursor fixed both in version 3.0. Patching handles that layer. The second layer is what Cursor deliberately leaves to you, and its own documentation is direct about it: MCP servers "can access external services and execute code on your behalf," and Cursor does not vet them. The third layer is data: what leaves your codebase, where it goes, and which of those flows a team administrator can actually enforce rather than request. This page covers all three, cites Cursor's own documentation and the published CVE records rather than summaries of them, and includes a table of the risks a runtime policy layer does not fix, because several of the most important ones it does not.
Try it live
Watch Agentshield block an attack in real time.
Pick a scenario and drive the inspection lane yourself. No signup needed.
Run a request
Inspection lane
INSPECTINGPolicy trace
High-risk action held for approval
Audit trail
- § · → → →
The risk
Your engineering org adopted Cursor the way engineering orgs adopt developer tools: quickly, from the bottom up, on a corporate card. It now has read and write access to production source, a terminal, and whatever MCP servers individual developers connected to it last month. Security found out when someone asked whether the SOC 2 questionnaire needed updating. Nobody can currently answer which repositories it has indexed, which MCP servers are connected across the team, or what happens when an agent reads a poisoned issue comment and decides to run a shell command.
How Agentshield handles it
Split it into what Cursor fixes, what Cursor configures, and what only your side can enforce. Cursor fixes product vulnerabilities, so version floor and auto-update policy are a real control: everything below 3.0 carries two published CVSS 9.8 sandbox escapes and everything below 2.5 carries a third. Cursor configures approval behavior, MCP allowlists, workspace trust and Privacy Mode, and on team plans an administrator can set those centrally instead of hoping. What neither of those reaches is the blast radius of a tool call that Cursor legitimately allows. When a Cursor agent calls an internal API, opens a database connection or pushes to a repository through an MCP server, the credential it uses is usually a long-lived token sitting in a config file, scoped to a human. Routing those calls through a control point gives the agent its own scoped identity, a default-deny egress path, an approval gate on irreversible actions, and an append-only record held off the developer's laptop. That is the layer that keeps working on the day a fourth sandbox escape is published.
The controls
The controls that secure the Cursor agents your developers run against your codebase, your MCP servers and your internal systems.
Cursor AI security vulnerabilities: what DuneSlide actually did
Three published CVEs matter for a security review, and they all share one shape: content the agent reads becomes code the agent runs, outside whatever boundary was supposed to hold it. Cato AI Labs, who found two of them, put the significance in one line: "There is no click to fall for and no approval box to ignore."
| CVE | What it is | Severity | Fixed in |
|---|---|---|---|
| CVE-2026-50548 | Cursor runs agent terminal commands in a sandbox that grants write access to the command's working directory. The agent could modify the working_directory parameter so the sandbox included writable paths outside the workspace. NVD describes the result as writing "arbitrary files outside the workspace under the user's privileges," for example by overwriting the sandbox helper binary so later commands run unsandboxed | CVSS 3.1 base 9.8 critical (CVSS 4.0: 9.3). CWE-22 path traversal. Published June 25, 2026 | Cursor 3.0 |
| CVE-2026-50549 | The other half of DuneSlide. Before writing, Cursor resolves symlinks to confirm the destination sits inside the project. When that check fails, because the target does not exist or read access is removed from a directory in the path, Cursor falls back to trusting the link's in-project path and writes outside the project anyway, reaching the same sandbox helper | CVSS 9.8 critical | Cursor 3.0 |
| CVE-2026-26268 | Separate and earlier. NVD: "A malicious agent (ie prompt injection) could write to improperly protected .git settings, including git hooks, which may cause out-of-sandbox RCE next time they are triggered. No user interaction was required as Git executes these commands automatically" | Scored 9.9 critical by NIST and 8.0 high by the CNA. Both numbers are real; the gap is a scope and privilege disagreement. CWE-862. Published February 13, 2026 | Cursor 2.5 |
The DuneSlide disclosure timeline is worth reading as well, because it is a fair illustration of how new this problem class still is for everyone. Cato reported both issues on February 19, 2026. On February 23 Cursor initially declined them on the grounds that the threat model did not cover MCP misuse. Cato escalated on February 26, Cursor reopened and triaged, and the fixes shipped in Cursor 3.0 on April 2. CVE identifiers were assigned on June 5. There is no bad actor in that sequence, just a genuine disagreement about whether "a connected MCP server returned hostile text" is an attacker-controlled input. It is, and the industry is still converging on that.
The injection vector in DuneSlide is the part to carry into your own threat model. The hostile instructions did not arrive by a developer pasting something reckless into the chat box. They arrived through content the agent pulled in while doing normal work: results from a connected MCP server, or a web search result. That is indirect prompt injection, and the distinction from a user typing a jailbreak matters a great deal for which controls help, which we cover in prompt injection vs jailbreak.
The practical takeaway is unglamorous. Set a version floor of Cursor 3.0 or later, enforce it, and verify it rather than announce it. Every one of these three vulnerabilities is fixed, and an unpatched install is the only way any of them still reaches you.
Cursor MCP security: the risk Cursor tells you is yours
Cursor's documentation on MCP is unusually candid, and it deserves credit for that. It also, read carefully, hands you a substantial amount of responsibility. The key sentence: "Remember that MCP servers can access external services and execute code on your behalf. Always understand what a server does before installation." Its guidance is to "Only install MCP servers from trusted developers and repositories," to "Review permissions: Check what data and APIs the server will access," to "Use restricted API keys with minimal required permissions," and, for critical integrations, to "review the server's source code."
Note what is absent. Cursor does not claim to vet, audit or verify third-party MCP servers, and it should not be criticized for that: Anthropic says the same thing about MCP servers in its own ecosystem. But it means the security property of your MCP setup is entirely a function of decisions individual developers made, one server at a time, usually by pasting a config snippet from a README.
Cursor's approval model is the mitigating control, and on paper it is strong: "All MCP connections need your approval. After you approve an MCP connection, each tool call still needs individual approval before running." The gap between that sentence and reality is human. Approval prompts that fire on every tool call get approved reflexively within about a day, and Cursor offers Run Modes precisely so that trusted calls can skip the prompt. The moment a team turns that on for convenience, the per-call gate is gone.
Two failure modes deserve naming, because they defeat careful reviewing:
- Tool poisoning. Invariant Labs documented this against Cursor specifically on April 1, 2025: malicious instructions embedded in an MCP tool description, invisible to the user but read by the model as authoritative. Their proof of concept exfiltrated the developer's own
~/.cursor/mcp.jsonand their~/.ssh/id_rsa. Reviewing the server's code does not help if the hostile content is in the description string the model reads at runtime. - Post-approval change. You approve a server once. It updates. Tool descriptions are fetched fresh, so approval at install time is not approval of what the server says next week. This is why definition hashing matters more than one-time review, a point we go into on MCP server security.
At team scale, the fix is not more careful individual reviewing, it is removing the decision from individuals. Cursor supports an MCP allowlist for enterprise control, and that is the first thing to turn on. The second is routing MCP traffic through a single control point so that servers are allowlisted centrally, tool definitions are pinned by hash, and every call is logged whether or not the developer approved it in the moment. That architecture is described on MCP gateway.
Cursor AI data security: what leaves your codebase
This is the question that actually blocks Cursor adoption in regulated companies, and it is usually asked badly. "Does Cursor store our code" is not one question, it is four, and they have different answers.
| Question | Where the answer lives | What you can enforce |
|---|---|---|
| Is our code used to train models? | Cursor's Privacy Mode: "When enabled, we will not train on your data. We also implement technical controls and contractual requirements with our model providers to protect your data." Privacy Mode is available to all users | On team and enterprise plans, enforce Privacy Mode centrally rather than trusting each developer to have toggled it |
| Is there an attestation we can show an auditor? | Cursor states a SOC 2 Type II attestation report is available on request through its trust center | Request it, read the exceptions section, and map it against the controls your own auditor tests. An attestation is evidence, not a guarantee |
| What does codebase indexing send? | Cursor's own security and privacy documentation, which you should read at the version you are deploying rather than trusting a summary, including this one | Scope which repositories are opened in Cursor at all. Nothing is indexed from a repository nobody opens |
| What can the agent reach beyond the repo? | Not a Cursor question. It is a function of the MCP servers connected, the credentials on the developer's machine, and what the terminal can reach | This is the layer you own completely, and it is usually the largest exposure. Scoped credentials and egress policy, not editor settings |
The fourth row is the one that gets skipped, and it is the one that matters most. Teams spend weeks on the training-data question, which Privacy Mode answers, and zero time on the fact that the same laptop holds a production database URL in an environment file that the agent's terminal can read. An assistant that cannot train on your code but can read your credentials and call your internal API is not meaningfully contained.
There is also a workspace trust setting worth knowing about, and Cursor's advice on it is blunt: "For untrusted repos, use a basic text editor instead." If your developers review external pull requests, audit vendor code, or open customer-supplied repositories, that sentence is aimed at exactly your workflow. A repository is attacker-controlled input, and the DuneSlide class of bug is what happens when attacker-controlled input reaches an agent with a terminal.
One more setting deserves a mention because it silently removes a human checkpoint: Cursor warns that "If you have auto-reload enabled, agent changes might execute before you can review them." Anything that shortens the window between an agent deciding and the machine acting is a control you are trading away, usually for a few seconds of convenience.
Cursor AI enterprise security: a checklist for engineering leaders
Ordered by risk removed per hour spent. The first four are configuration and cost almost nothing.
- Set and verify a version floor of Cursor 3.0 or later. This closes all three published sandbox escapes above. Verify by inventory, not by policy document. An unpatched install is the entire remaining exposure for those CVEs.
- Enforce Privacy Mode at the team level. Not as a recommendation in an onboarding doc. As an administrator setting, so it survives new hires and reinstalls.
- Turn on the MCP allowlist and keep it short. Every server on it should have a named owner who can say what it does. Servers that reach production systems deserve a higher bar than servers that read documentation.
- Do not blanket-enable auto-run for terminal commands. Cursor's default is that "terminal commands need your approval," and Run Modes exist to relax it. Relax it for a narrow, reviewed set, not globally, and never on a machine that holds production credentials.
- Keep untrusted repositories out of Cursor entirely. External pull requests, vendor code and customer artifacts get reviewed in a plain editor or in an isolated environment. This is Cursor's own advice and it is correct.
- Get production credentials off developer machines. The realistic worst case in every scenario above is not that the agent reads your source, it is that it reaches something with your source's credentials. Short-lived, narrowly scoped tokens issued at the point of use turn a credential theft into a session. See AI agent access control.
- Give agent traffic its own identity. When a Cursor agent calls an internal service using a developer's personal access token, the request is indistinguishable from that developer in every log you own. Separating the identity is what makes the rest of this auditable at all, covered on AI agent identity.
- Log tool calls somewhere the laptop cannot edit. Local history is not evidence. If you need to answer what an agent touched during an incident window, that record has to live off the host. See agent audit trail.
- Gate irreversible actions on a human. Force-pushes, schema migrations, production deploys, anything that deletes. The pattern and where it breaks down is on human in the loop AI agents.
- Isolate the execution environment. If agents run code, the boundary deserves the same scrutiny as the tool. Practical options are compared in how to sandbox an AI agent and on AI agent sandboxing.
Items one through five are Cursor configuration and belong to whoever administers the tool. Items six through ten are infrastructure, they apply identically to every coding agent your teams use, and they are the reason a review scoped to "is Cursor safe" tends to produce the wrong project. The broader version of that program is on coding agent security.
If Cursor is not the only assistant in the estate, and it rarely is, the same checklist has to be run per vendor because the control sets are not equivalent. The equivalent breakdown for the most widely deployed one, including where GitHub states its own agent firewall and content exclusion stop, is on GitHub Copilot security.
How Cursor compares to other coding agents on security controls
Teams rarely deploy one coding agent. They deploy Cursor for the IDE workflow, something else in CI, and whatever individual developers install themselves. The controls differ, and a policy written for one does not transfer.
| Control | Cursor | Claude Code | What this means for you |
|---|---|---|---|
| Default for terminal commands | Approval required by default; Run Modes let trusted calls skip the prompt | Anthropic states it "uses strict read-only permissions by default" and describes its gate as "a permission gate, not a sandbox" | Both defaults are reasonable. Both are routinely relaxed for convenience, and that is where real deployments diverge from documented ones |
| MCP server vetting | Not vetted. "Only install MCP servers from trusted developers and repositories" | Not vetted. Anthropic states it "does not security-audit or manage any MCP server" | Identical exposure. Neither vendor is your MCP security program, so allowlisting and definition pinning has to happen on your side |
| Per-call approval for MCP tools | Yes by default: each tool call needs individual approval | Yes, with the notable gap that trust verification is disabled under the non-interactive flag | Both weaken in automation. Anything running unattended in CI has effectively no human gate, which is where the strongest case for external policy sits |
| Published sandbox escapes | Three critical CVEs in 2026, all patched (3.0 and 2.5) | Vendor states "no system is completely immune to all attacks" | CVE count measures scrutiny as much as weakness. A widely researched tool with published, patched CVEs is not worse than an unexamined one |
The row that generalizes is the third one. Every one of these tools has a strong interactive approval story and a much weaker unattended one, because a human gate is not a gate when there is no human. If any part of your pipeline runs a coding agent without a person watching, the policy has to live outside the agent. Detail on the Anthropic side is on Claude agent security, and the framework-level version of the same gap is on LangChain security.
What a runtime control point does and does not fix for Cursor
We sell a policy gateway, so read this skeptically. It is written to be accurate rather than flattering, and three of the six rows say no.
| Cursor risk | Does a policy gateway help? | What actually fixes it |
|---|---|---|
| A sandbox escape in the Cursor client, like DuneSlide | No. This is code running on a developer's machine outside anything we sit in front of | Patching. Cursor 3.0 or later, enforced by inventory. Nothing on your side substitutes for the vendor fix |
| Source code sent to a model provider | No. We do not proxy the editor's model traffic | Privacy Mode enforced at the team level, plus your contract with the vendor and its SOC 2 attestation |
| A malicious MCP server installed by one developer | Partly. Servers reached through the control point are allowlisted, definition-pinned and logged. A server the developer configures locally and calls directly is outside it | Cursor's enterprise MCP allowlist plus a central gateway. Both, not either |
| Prompt injection reaching the agent through a repo, a web result or a tool description | Partly. We inspect untrusted content before an agent acts on it, but no filter is complete and we will not claim otherwise | Containment rather than detection. Assume injection succeeds and constrain what the agent can then do. See prompt injection protection |
| An agent using a developer's long-lived credential against production | Yes. Calls carry a scope attached to the agent, so a token lifted from a config file is not a usable one | Per-agent identity with short-lived scoped credentials, enforced where the call is made |
| No record of what the agent touched during an incident window | Yes. An append-only log of requested, allowed and denied calls, held off the developer's machine | An audit trail the endpoint cannot edit, which is the only artifact that survives compromise of that endpoint |
Two flat no, two partial, two yes. If you are running a vendor evaluation, ask every vendor in this market for the same table and treat an all-green answer as a reason to look harder. Our survey of who does what is in AI agent security companies.
The honest summary of Cursor AI security is that Cursor has done reasonable work on the layers it owns, has been explicit about the layers it does not, and the industry keeps discovering that the boundary between an assistant reading text and a machine executing commands is thinner than the interface suggests. That pattern is not specific to Cursor. It showed up in an agent framework on OpenClaw security, and at infrastructure scale in the Hugging Face security incident. The control that survives all three is the same one: constrain what an agent can reach, and keep the record somewhere it cannot rewrite.
FAQ
Common questions about cursor ai security.
Is Cursor AI safe for enterprise codebases?
Yes, with configuration and a version floor. Run Cursor 3.0 or later, which closes the three published critical sandbox escapes, enforce Privacy Mode centrally so your code is not used for training, and keep the MCP allowlist short. The residual risk is not the editor, it is what the agent can reach with the credentials sitting on that machine.
What are the Cursor AI security concerns?
Four, in order of how often they bite. Prompt injection arriving through repositories, web results or MCP tool descriptions. Third-party MCP servers, which Cursor does not vet. Long-lived production credentials on developer laptops that the agent terminal can read. And approval fatigue, where per-call gates get relaxed for convenience and the human checkpoint quietly disappears.
What is CVE-2026-50548?
A critical Cursor vulnerability, CVSS 9.8, in versions before 3.0. Cursor ran agent terminal commands in a sandbox that granted write access to the command working directory, and the agent could change that directory to a path outside the workspace. NVD describes the result as writing arbitrary files outside the workspace under the user privileges, which enables non-sandboxed remote code execution. Upgrading to 3.0 fixes it.
Was there a Cursor security incident?
There were published vulnerabilities rather than a disclosed breach of Cursor. Cato AI Labs found two critical sandbox escapes, named DuneSlide, reported them in February 2026, and Cursor shipped fixes in version 3.0 on April 2, 2026. A separate git hooks escape, CVE-2026-26268, was fixed in 2.5. No known active exploitation was reported at disclosure.
Does Cursor store my code?
Cursor offers Privacy Mode, available to all users, and states that when enabled "we will not train on your data. We also implement technical controls and contractual requirements with our model providers to protect your data." A SOC 2 Type II attestation report is available on request through its trust center. Read the current documentation at the version you deploy rather than relying on any summary.
Is Cursor MCP safe?
MCP is as safe as the servers you connect, and Cursor does not vet them. Its documentation says to only install servers from trusted developers, to review what data and APIs a server will access, and that servers "can access external services and execute code on your behalf." All MCP connections need approval, and each tool call needs individual approval unless Run Modes relax it.
Can prompt injection attack Cursor?
Yes, and it has been the root cause of every published critical Cursor CVE so far. In DuneSlide the hostile instructions arrived through ordinary work: results from a connected MCP server or a web search result, with no user click. That is indirect prompt injection, and it is why containment matters more than detection.
How do I secure Cursor for a development team?
Enforce Cursor 3.0 or later, enforce Privacy Mode as an administrator setting, enable the enterprise MCP allowlist, keep terminal auto-run narrow, and keep untrusted repositories out of Cursor entirely. Then do the part Cursor cannot: remove long-lived production credentials from developer machines and give agent traffic its own scoped identity and audit trail.
Should we let developers use Cursor at work?
For most engineering organizations, yes, with the controls above. A ban usually moves the tool onto unmanaged personal machines where you can enforce nothing and see nothing. Decide instead by machine and by repository: managed device, version floor, enforced settings, short MCP allowlist, and no untrusted repositories opened in it.
Does Agentshield secure Cursor?
Partly, and the split matters. We do not patch the Cursor client, so a sandbox escape like DuneSlide is not ours to stop, and we do not proxy the editor traffic to model providers. What we cover is the reach: scoping tool and network calls to the agent making them, allowlisting and pinning MCP servers behind one control point, holding irreversible actions for a human, and keeping an append-only record off the developer machine.
More use cases