Cursor security risks: the defaults, the CVEs, and what to lock down

Cursor is a fork of VS Code with an agent that reads your files, edits them, runs shell commands, and calls MCP tools. Cursor's own Agent Security page says agents "can modify workspace files without approval" and that "changes save immediately to disk." That is the design, and it is why the editor is fast.

It is also why a security review of Cursor cannot start from the settings panel. Every control Cursor ships, it describes as best-effort. The useful questions are: what can the agent do with no human involved, who can steer it, and what record do you have when the steering goes wrong.

Cursor security starts with what the agent does unasked

Cursor's documented defaults, as of this rewrite: reading files and searching code need no approval. Workspace files are edited and saved without approval, configuration files excepted. Terminal commands "need your approval." Every MCP connection needs approval, and after that "each tool call still needs individual approval" unless allowlisted. Workspace trust is off by default, and for untrusted repos Cursor's advice is a basic text editor instead.

Credit where it is earned. Cursor ships a sandbox for shell commands, hooks such as beforeShellExecution and beforeMCPExecution that can deny an action with exit code 2, a ~/.cursor/permissions.json that MDM can distribute, and an Enterprise-only MCP allowlist.

The approval prompt has been eroding since the agent shipped, and the trail is in Cursor's own release notes.

The Run Modes page lists three modes: Auto-review, Allowlist, and Run Everything. In Auto-review, allowlisted calls run immediately, sandboxable shell commands run in the sandbox, and everything else goes to a classifier running on "Claude 4.5 Haiku or GPT-5.4 Mini." The page's own heading: "Auto-review is not a security boundary. The classifier can make mistakes."

So on a fresh install, what stands between the agent and your shell is a small model's opinion of a larger model's plan. An earlier version of this post told you to set cursor.composer.autoMode; that key does not appear in Cursor's documentation. The real controls are Settings > Agents > Approvals & Execution and ~/.cursor/permissions.json.

The rules file is an instruction channel anyone can commit to

Cursor reads agent instructions from the repository it is editing: .cursor/rules/*.mdc files and AGENTS.md, in the project root or any subdirectory, per the Rules docs. These files are prompts, and they ship inside the code they govern.

In March 2025, Pillar Security published the Rules File Backdoor. The payload hid instructions in a rules file with bidirectional text markers and zero-width joiners, invisible in the editor and in GitHub's pull request view. Asked for an HTML page, both Cursor and Copilot appended an attacker's external script and did not mention it.

Pillar reported it to Cursor on February 26, 2025. On March 6 and again on March 8, Cursor's position was that the risk "falls under the users' responsibility."

GitHub took the same stance on March 12, then on May 1, 2025 added a github.com warning for files containing hidden Unicode. The rule is yours to enforce: a pull request that touches .cursor/rules/ or AGENTS.md changes the behavior of every developer's agent. Review it like CI configuration.

MCP: you approved a name, not a program

MCP servers are configured in .cursor/mcp.json for a project or ~/.cursor/mcp.json for everything, as a command, args, and env. The MCP docs say nothing about version pinning or integrity, and that gap produced three disclosures in 2025.

On April 1, 2025, Invariant Labs published Tool Poisoning Attacks using Cursor as the test client. Their definition of a rug pull: "a malicious server can change the tool description after the client has already approved it." They also noted that Cursor's confirmation dialog did not show the full tool input, so an SSH key passed as an argument was invisible.

CurXecute, CVSS 8.6, was a prompt injection that reached the agent through any MCP data source (Aim's proof of concept used a Slack message) and made the agent suggest an edit to ~/.cursor/mcp.json. The edit landed on disk and the new server's command started before the user had accepted or rejected the suggestion.

MCPoison: when you approved a project's .cursor/mcp.json entry, Cursor bound that approval to the entry's name. A later commit could change command and args under the same name and Cursor ran it with no new prompt. Check Point reported it on July 16, 2025; since 1.3, any change to an MCP configuration re-prompts.

Both fixes shipped. The docs still offer no way to pin what a server is, so pin it yourself.

{
"mcpServers": {
  "github": {
    "command": "/opt/acme/mcp/github-server-1.4.2/bin/server",
    "args": ["--read-only"],
    "env": {}
  }
}
}

No npx -y something@latest. The binary comes from your artifact store with a recorded checksum, the version is in the path, and MDM distributes the config. On Enterprise, the MCP allowlist makes this structural: "only servers matching an allowlist entry can run." The MCP security checklist has the rest.

The chain the classifier approves one link at a time

An ordinary session: the agent decides a dependency is missing and runs npm install, a routine build command under Auto-review. The package has a postinstall script that fetches and pipes to a shell, and the shell reads ~/.aws/credentials. Each step is reasonable on its own, and only one of them was ever a tool call.

Allowlists see even less. Before 1.3, per Cursor's own advisory, an allowlisted command containing a backtick or $(cmd) executed arbitrary commands "without user approval," reachable "if chained with indirect prompt injection." A parser fix closed that one. The class stays open: the control evaluates a string, and the system executes a process tree.

Cursor does not produce the right column. Closing that gap is what runtime security exists to do.

Cloud Agents run on Cursor's machines with write access to your repo

Cursor's docs are direct: "Cloud Agents were formerly called Background Agents," and they run "in isolated VMs in the cloud" on Cursor's AWS infrastructure. Its Secrets and Network page says to "grant read-write privileges to our GitHub app for repos you want to edit," and that the agent "has internet access by default," with egress controls available.

Because it is on its own machine, Run Modes do not apply: "the agent never asks you to approve an action." The hand-off is a pushed branch and a draft pull request.

Two facts for anyone with a data-handling policy. Cursor's enterprise privacy docs state that "Cloud Agents are the only feature that requires Cursor to store code," and VM snapshots containing cloned code are kept for "rolling 90 days of inactivity." If your policy prohibits code storage, Cursor's own guidance is: "don't enable Cloud Agents."

Cursor vs Claude Code vs Copilot, defaults only

All three vendors now ship a classifier tier, so the old "Cursor is YOLO, Claude Code asks" summary is out of date.

Cursor edits workspace files without asking. Shell, MCP, and Fetch calls go through Auto-review by default since 3.6. Cloud Agents have no approval step and hand off through a draft PR. The most capability, the most surface, and the most candid docs about its controls being best-effort.

Claude Code in Manual mode asks before every Bash command, file edit, and web fetch, per its permission modes. But "on Pro, Max, and Team plans, the built-in starting permission mode is auto mode," where a classifier reviews actions instead of you. Enterprise plans and Console API keys start in Manual, and disableAutoMode in managed settings forces it. Deny rules hold in every mode. Covered in depth in Claude Code security risks.

GitHub Copilot in VS Code agent sessions runs "common read-only commands" automatically while "risky commands such as rm and del require approval," per the approvals docs; chat.tools.global.autoApprove and /yolo turn that off. Its cloud agent is the structurally tightest of the three: it pushes only to a copilot/ branch, workflows wait for a human with write access to click "Approve and run workflows," the requester cannot approve the PR, and a firewall restricts internet access by default.

The take: Copilot's cloud agent has the best defaults because GitHub enforces them, not a model. Claude Code has the best local controls if you are on Enterprise or set Manual. All three now share a default local gate that is one model judging another.

What to do Monday

Set the team Run Mode, then ship permissions.json through MDM. A short terminalAllowlist, an explicit mcpAllowlist, and autoRun.block_instructions naming ~/.ssh, ~/.aws, and shell rc files. Allowlist mode with an empty allowlist is the old Ask Every Time.

Pin every MCP server to an artifact you built, and turn on the Enterprise MCP allowlist. Nothing in mcp.json should resolve at run time.

Add denying hooks. beforeShellExecution and beforeMCPExecution that exit 2 on credential paths and unlisted hosts, distributed from the dashboard so no one can remove them per machine.

Treat .cursor/rules/ and AGENTS.md as code. CODEOWNERS on both, and a CI check that rejects non-ASCII bytes.

Keep Cloud Agents off repositories whose pipelines can deploy. Where a team needs them: scope the GitHub App install, set an egress allowlist, and record the 90-day snapshot retention in your data inventory.

Get production credentials off developer laptops. The agent reads what your user can read, and no Run Mode changes that.

Watch at the operating system, not the prompt. Everything above is prevention, and all of it is best-effort by its vendor's own account. Quint runs on macOS developer endpoints and observes agents through the EndpointSecurity framework: file, process, and network activity for every agent on the machine, with no changes to the agent. It also records the declared tool calls at the interception layer, so the gap between the two columns above is the detection signal.

The sequence is scored in real time on the device with no LLM in the decision path: "read config" is fine; "read config, open a socket to an unknown host, touch ~/.ssh" is flagged, and the interception and hook layer can allow, flag, or block it. Every action lands in a hash-chained, Ed25519-signed audit record, and the fleet view includes the agents IT never approved. That is behavioral security as it ships.

Cursor's documentation describes its agent accurately. Read it, configure what it offers, then put a witness at the layer none of the three editors can lie about. To see that on a real session, book a demo.