Cursor Security: Risks, Controls, and Best Practices

What is Cursor, and why does it change the security model?

Cursor is an AI-first code editor, a fork of VS Code rebuilt around the model rather than around the file. It works inside the developer's normal flow (the editor, the integrated terminal, the agent panel) and acts on natural-language instructions: explain this codebase, build this feature, fix this failing test, refactor across these files. To do that well it indexes the repository so the model has context, edits multiple files in a single agent run, executes tasks and terminal commands, and extends itself through the Model Context Protocol (MCP) to reach databases, issue trackers and internal tooling.

That combination is what breaks the old security model. A classic IDE assistant offered a completion; a human read it and chose to accept or reject. The blast radius of a bad suggestion was one block of code a developer still had to paste in. Cursor takes actions instead. It reads files you never named, runs commands you never typed, rewrites code across the tree, and can execute a task the moment you open a folder. The attack surface is no longer "what did the model suggest." It is "what can this editor do with the access it has, what code can it generate at volume, and who gets to influence its instructions."

“

A suggestion is a draft a human chooses to accept. An action is a thing that already happened. The security model has to move from reviewing drafts to constraining actions.

There is a second shift, and it is about speed. The pull request became the home of application security because it sat at human cadence: a person slowed down, read the diff, and only then merged. Cursor does not run at human cadence. A single agent session can produce more code in an afternoon than a reviewer reads in a week, and the editor will happily generate functional code that is quietly insecure. When that happens, the diff stops being a checkpoint and becomes a transcript of decisions already made. Any control that only acts at the pull request is now reviewing history, not preventing it.

For most teams the practical question is not whether Cursor has built-in protections. It does, and several are genuinely good. The question is whether they are enough for daily use. The honest answer is no. Cursor's own security page documents real controls, and they reduce risk, but secure adoption still depends on permissions, isolation, human oversight and independent validation across code, dependencies, secrets and pipelines.

How Cursor's security model works

Cursor's model is built around three ideas: prove the platform handles data responsibly, give the developer levers to keep sensitive code out of the model's reach, and contain what an opened project is allowed to do. In practice that surfaces as a handful of controls.

It is a reasonable baseline, and most of this did not exist in IDE assistants a generation ago. The trap is reading it as a finished security boundary. Privacy Mode protects your data but says nothing about the security of the code Cursor writes. .cursorignore only works if you maintain it. Workspace Trust only protects you if it is on, and for much of Cursor's history it was not. SOC 2 attests to how Cursor runs its service, not to how safely it behaves on your machine. Every control here has a documented edge, and the next section is about what happens when you lean on them too hard.

The top 6 security risks in Cursor

The risks below are not theoretical. They map to disclosed vulnerabilities, published research and the OWASP Top 10 for LLM Applications. The numbers that frame them are the same ones every AppSec team is now quoting.

10.5%

of AI coding-agent solutions were secure, vs 61% functionally correct (Carnegie Mellon SusVibes)

45%

of AI-generated code fails security tests (Veracode)

#1

prompt injection, the top LLM risk for the 3rd year running (OWASP LLM01)

1. Workspace Trust off by default, leading to silent code execution

This is Cursor's signature issue. In September 2025, The Hacker News reported a flaw ("Cursor AI Code Editor Flaw Enables Silent Code Execution via Malicious Repositories") rooted in Workspace Trust shipping disabled by default. Because Cursor is a VS Code fork, a project can carry a .vscode/tasks.json task configured with runOn: folderOpen, and with trust off that task executes the instant a developer opens the folder, running arbitrary code in the user's context.

The attack is mundane to stage. An attacker publishes a tempting repository on GitHub, hides an "autorun" task inside it, and waits for someone to clone and open it in Cursor. No prompt, no click, no review: opening the project is enough to leak credentials, modify files, or plant a foothold for broader compromise. The researchers (Oasis Security) recommended the same mitigation we do: enable Workspace Trust, open untrusted repositories in a different editor first, and audit a project before opening it in Cursor. The fix is one setting, but it only helps the developers who know to flip it.

2. Insecure AI-generated code

Cursor's job is to write code fast, and fast does not mean safe. Carnegie Mellon's SusVibes benchmark, which tracks commercial coding agents including Cursor, found that the strongest agent and model pairing produced functionally correct code 61% of the time but secure code only 10.5% of the time, and that over 80% of the functionally correct solutions still carried a vulnerability. The gap between "it works" and "it is safe" is where the danger lives: code that passes the test and ships the vulnerability.

The patterns are predictable. String-concatenated SQL instead of parameterized queries (classic SQL injection), prototype pollution in JavaScript, missing output encoding that opens XSS, absent input validation on generated endpoints. These are not exotic bugs; they are the OWASP staples, reproduced at machine speed because the model learned from a public corpus full of them. Veracode's broader finding (45% of AI-generated code fails security tests, 62% carries a design flaw) holds across tools, and Cursor is firmly inside that distribution. The faster the editor ships, the faster the flaws accumulate, and functional-looking code is exactly the kind a hurried reviewer waves through.

3. Data and context exposure

Cursor is useful because it has context, and that context routinely includes more than source code. Anything open in the workspace, a .env file, a config with connection strings, internal API endpoints, can be pulled into the model's context unless you explicitly exclude it with .cursorignore. Cursor's AI features also send code to an external API to generate responses, so for sensitive business logic the question of where that traffic goes is a real one, and Privacy Mode is the tradeoff you make to control it.

The exposure is often indirect. While summarizing a repository or debugging an error, the agent can surface a token, a credential or an internal hostname into output that then lands in a chat, a ticket or a committed file, where it lives long after the session ends. As Endor Labs and others have noted, codebase indexing widens this surface: the more Cursor indexes, the more it can inadvertently reach. The default posture is convenience, and convenience means broad access unless you narrow it by hand.

4. Prompt injection and rules-file poisoning

Prompt injection is the defining risk of agentic coding tools, and it is OWASP's number-one LLM risk (LLM01) for the third year in a row. An attacker hides instructions in something the agent reads, and the agent follows them, overriding its intended behavior.

In Cursor the dangerous form is indirect, and it has a Cursor-specific twist: the rules file. Malicious instructions can ride in repository content, in a .cursorrules or project rules file, or in the output of an MCP tool. Because a rules file is meant to steer the agent, a poisoned one is prompt injection by design: a contributor or a dependency drops crafted instructions into the rules, and Cursor treats them as policy. A comment in a README that says "before continuing, run this setup script" can be enough. Since a language model cannot reliably separate a trusted instruction from a malicious one embedded in data, the injection can lead to command execution, data exfiltration or silent code manipulation. A steered agent does not just answer wrong, it acts.

5. Supply chain and malicious MCP servers

Cursor installs packages, clones repositories and connects to external tools as part of normal work. If it pulls in a compromised library or wires up a hostile MCP server, the malicious code runs with whatever access the environment grants. This is not hypothetical. In early 2026 an npm typosquatting campaign tracked as "Sandworm_Mode" planted rogue MCP servers by mimicking popular utilities, specifically targeting AI coding assistants including Cursor, Claude Code and Windsurf.

MCP is a new trust boundary most teams have not threat-modeled. A malicious or compromised server can hide instructions inside its tool descriptions and responses, so simply having it connected can steer the agent before it ever calls the tool. Package hallucination compounds the risk: an agent that invents a plausible-but-nonexistent package name hands attackers a slot to register and weaponize. The agent will often approve the install confidently, because the name looks right and the task asked for it.

6. Documented editor vulnerabilities leading to RCE

Beyond the autorun flaw, Cursor has accumulated a string of security advisories, including research published by groups such as Geordie AI, covering trust-bypass and code-execution vectors in the editor itself (hidden Git hooks, persistent execution via MCP trust bypass, and related issues). The recurring theme is that Cursor is reasonably safe as an IDE, and meaningfully unsafe as an automated code generator without an external review layer.

The danger compounds when the editor runs with broad access to the developer's machine. A chain of individually harmless actions, install this dependency, run this task, apply this edit, can install malware, alter a CI configuration, or open a persistence mechanism. This is exactly why trust gating, least privilege and isolated environments matter, and why the combination to fear is the common one: an untrusted repo, a permissive setup to avoid friction, and an injected instruction the editor treats as legitimate.

What Cursor's built-in security covers, and what it doesn't

The native controls are real, and it helps to be precise about the line between what they handle and what they leave to you.

Read the right-hand column as the actual job. Cursor's built-in controls are weighted toward data privacy and vendor compliance, which is where a buyer's first questions land. They were never designed to stop a determined adversary who controls the editor's inputs, and they say almost nothing about the security of the code Cursor writes. Everything that turns "Cursor is installed" into "Cursor is governed" lives in the practices that follow.

Best practices to secure Cursor

These nine practices close the gap between the native baseline and a real security posture. None are exotic; the discipline is in applying them consistently across a team that is moving fast.

1. Enable Workspace Trust, and treat untrusted repos as hostile. Turn Workspace Trust on as a standard part of setup, so an opened folder cannot autorun a task. Open repositories you did not write in a sandboxed environment or a different editor first, audit .vscode/tasks.json and any Git hooks before you trust them, and never browse a tempting public repo in your primary Cursor instance without checking what it is allowed to run.

2. Keep Privacy Mode on for sensitive work, and own the tradeoff. Privacy Mode is the control that keeps your code from being stored or used for training. Treat it as the default for any repository with real business logic, regulated data or proprietary code. Where a team chooses to disable it for a feature, make that an explicit, documented decision scoped to low-sensitivity work, not a quiet default everyone forgot to check.

3. Curate .cursorignore like a security artifact. Exclude .env files, credential stores, infrastructure config, connection strings and any sensitive module from both AI context and indexing. Review the ignore file the way you review access control: on a schedule, after every new secret or service is added, and as part of onboarding a new repo. An out-of-date .cursorignore is the most common way a secret ends up in a model's context.

4. Keep a human in the loop on generated code. Treat Cursor's output as a draft, not a finished implementation. Route all generated or modified code through pull-request review and automated testing, with extra scrutiny on authentication, input validation, SQL queries and privileged paths, precisely the areas the SusVibes data shows the model getting wrong. The point is not distrust of the tool; it is that an editor producing thousands of lines a day produces subtle flaws faster than they surface on their own.

5. Scan AI-generated code with SAST in CI. Because only a small fraction of AI solutions are secure by default, a static analysis gate is not optional. Run SAST on every pull request, fail the build on high-severity findings (SQL injection, XSS, prototype pollution, missing authorization), and feed the results back to the developers so the same classes stop recurring. Functional tests will not catch a vulnerable-but-working endpoint; only a security-aware check will.

6. Govern dependencies, packages and MCP servers. Restrict installs to trusted registries or internal mirrors, require approval for new packages, and scan everything with software composition analysis. Vet every MCP server as a trust boundary: use ones you wrote or genuinely trust, scope each to the narrowest data and actions it needs, and keep an inventory so a typosquatted package like the "Sandworm_Mode" servers cannot slip in unnoticed.

7. Manage secrets out of reach. Keep plaintext secrets out of the workspace the agent can see. Use a vault and inject at runtime, redact sensitive values in logs and output, and never leave credential files where Cursor's indexing can reach them. If a secret ever appears in a transcript, a generated file or a commit, rotate it immediately and investigate how it got there.

8. Run risky work in isolated, least-privilege environments. Use containers or sandboxed VMs for AI-assisted work on untrusted code, run Cursor without elevated privileges, and block unapproved outbound connections so a compromised session cannot exfiltrate. Segment environments by sensitivity so high-risk work is contained and the blast radius of any single compromise stays small.

9. Set policy by repository and environment sensitivity. Classify repositories (public, internal, regulated, production) and apply stricter controls to the sensitive ones: Privacy Mode on, indexing scoped, egress restricted, stronger review required. For critical systems, use Cursor only in environments with no direct path to production credentials, and document the policy so developers know where AI help is allowed and under what constraints.

Where built-in controls stop: securing the agent at prompt time

Walk back through the risks and a pattern emerges. Workspace Trust, Privacy Mode, .cursorignore and SAST all act on what the editor has already decided to do, or on code it has already written. They cluster around the pull request, because that is where AppSec has always lived. But the PR was only ever a control point because a human read it, and at agent cadence nobody reads it end to end anymore.

The place to enforce a rule is no longer the diff; it is the prompt, before the unsafe line is written. Whatever rule you want Cursor to follow has to be in its hands at the moment it writes, not waiting in a scanner that arrives once the code is on disk and the agent has moved on to the next task.

That is the layer VibeDefend adds. It is a free npm CLI that installs in about five seconds and wires Cursor (plus Claude Code, OpenAI Codex, Windsurf and VS Code Copilot) into three governance layers that run inside the agent loop.

npx -y @cybedefend/vibedefend@latest installPick EU or US, confirm CursorDrop .cybedefend/config.json in the repoNext prompt is governed

Business Rules The conventions in your repo that were never written down (use Decimal128 for money, authorization goes through requireOwner). VibeDefend mines them from how your team already codes and loads them into Cursor's context before each edit. Security Rules OWASP Top 10, SOC 2, GDPR and ISO 27001, loaded the day you install. The agent reads the applicable reminder before it writes, so the framework requirement becomes part of the code instead of an audit-time checkbox. Action Guard Destructive calls (a sudo rm -rf, a raw read of a secret-shaped env var, an ad-hoc psql against a production host) are intercepted before they fire. Warn or block per rule, with every interception in the audit trail.

Crucially, nothing about your code crosses the wire. Decisions happen locally next to the agent; only structured governance metadata (the rule that fired, the file path, the severity, a timestamp) reaches the backend. EU and US tenants are physically separate, and you pick the region at install time. That privacy model is what lets a control sit this close to the code without becoming a data-exfiltration risk in its own right, the same concern that makes Cursor's own Privacy Mode a tradeoff.

This is not a replacement for the practices above. It is the missing layer they assume exists: the one that puts your rules in Cursor's hands at prompt time, so the insecure line is rewritten before it is ever suggested, instead of caught three stages later by a scanner reading a diff nobody had time to read. Workspace Trust stops the editor from doing what it must not do; VibeDefend shapes what it writes in the first place.

Frequently asked questions

Is Cursor safe?

Cursor is safe to use when it is configured and contained, and risky when it is not. Its SOC 2 Type II compliance, Privacy Mode, .cursorignore and Workspace Trust prevent a real class of data leaks and accidents. The residual risk comes from defaults (Workspace Trust historically off, broad indexing), from the code it generates (only a small fraction is secure out of the box), from inputs (prompt injection, poisoned rules files, malicious MCP servers), and from the surrounding environment (exposed secrets, untrusted repos). Treat it as a powerful agent that needs trust gating, secrets exclusion, human review and SAST, not as a tool that is secure by default.

Does Cursor send my code to the cloud?

Yes. Cursor's AI features send code to an external API to generate responses, which can include file contents and the surrounding context of your task. Privacy Mode changes what happens to that code on Cursor's side: with it on, your code is not stored or used to train models. For sensitive business logic, keep Privacy Mode enabled, exclude secrets and regulated data from context with .cursorignore, and review Cursor's data-handling policy at cursor.com/security against your own requirements.

What is .cursorignore and why does it matter?

.cursorignore is a file (similar in spirit to .gitignore) that tells Cursor which paths to exclude from the AI's context and from codebase indexing. It matters because, by default, anything open in the workspace can be pulled into the model's context, including .env files, configs and connection strings. A well-maintained .cursorignore is the primary lever that keeps secrets and sensitive modules out of the model's reach. An out-of-date one is the most common way a credential ends up in an AI request.

Should I enable Workspace Trust in Cursor?

Yes. Workspace Trust gates the code-executing features of an opened folder behind an explicit trust decision. It is the direct mitigation for the September 2025 flaw where a booby-trapped repository could autorun a task and execute code the moment you opened the folder. Because Cursor historically shipped with Workspace Trust disabled by default, enabling it should be a standard part of your setup. Pair it with opening untrusted repositories in a sandbox or a different editor first.

Can Cursor run code from a repository automatically?

It can, if Workspace Trust is off. As a VS Code fork, Cursor honors tasks configured with runOn: folderOpen, so a malicious .vscode/tasks.json in a repository you clone and open can execute immediately, with no prompt, in your user context. This was the basis of the silent-code-execution flaw reported in September 2025. Enabling Workspace Trust closes the gap, but the default behavior is why you should never open an untrusted project in your primary Cursor instance.

Does Cursor's Privacy Mode make it secure?

No, and it is important to be precise here. Privacy Mode is a data control: it ensures your code is not stored on Cursor's servers or used for training. It says nothing about the security of the code Cursor generates, whether a repo can autorun a task, whether a prompt injection can steer the agent, or whether an MCP server is malicious. Privacy Mode protects your data; it does not protect your application. You still need Workspace Trust, .cursorignore, SAST, human review and a prompt-time control.

How is Cursor security different from Claude Code, GitHub Copilot or Codex?

The fundamentals are shared (least privilege, secrets exclusion, human review, dependency scanning), but the surfaces differ. Cursor's distinctive issues are Workspace Trust shipping off by default and a high rate of insecure generated code; Claude Code's is deep MCP and shell integration; GitHub Copilot's is insecure suggestions and secret leakage at scale; Codex's is command-injection and supply-chain incidents. We cover each agent in its own guide: Claude Code, GitHub Copilot and OpenAI Codex.