Is Cursor AI safe? Security, Privacy Mode and data use

Is Cursor AI safe? Cursor’s own security page says it holds a SOC 2 Type II attestation plus ISO/IEC 27001:2022, ISO/IEC 42001:2023 and AIUC-1 certifications, and that with Privacy Mode on it does not train on your data and its model providers keep zero data retention (Security, Data Use). Safety in practice also depends on your settings: agents run as your user, so the docs ask you to keep approvals, sandboxing and .cursorignore in place.

Applies to: Cursor’s Security page (updated August 25, 2026), Data Use & Privacy Overview (September 3, 2026), Privacy Policy (September 29, 2026) and Cursor docs as of October 2, 2026. Last checked: October 2, 2026.

On this page

What Cursor’s security page commits to

The Security page is Cursor’s summary of its controls. In its own words:

The company behind Cursor is Anysphere, Inc., which is the party named in the Privacy Policy.

Privacy Mode decides whether your code is used for training

Privacy Mode is the main switch for data use. The Security page says it is available to anyone, free or paid, can be turned on in settings or by a team admin, and new team members inherit the team’s setting. The Data Use & Privacy Overview describes the two states:

Two notes on the same page matter for a security review:

• Requests made with your own API key still pass through Cursor’s backend, where the final prompt is built.
• File contents are cached temporarily on Cursor’s servers, encrypted with client-generated keys that exist on the server only for the duration of a request, and are “never used as training data when privacy mode is enabled.”

The Privacy Policy adds that Anysphere does not use Inputs or Suggestions to train models unless they are flagged for security review, you report them as feedback, or you explicitly agree. It also says the policy does not apply where your employer provisions the account; then the customer agreement governs the data.

Models that need data retention

The Privacy and Data Governance page names Claude Fable 5.1 and Claude Fable 5 as models outside the ZDR agreements: Anthropic stores their inputs and outputs for harm-prevention reviews, not for training. With Privacy Mode on, requests to them fail until an admin approves the model’s data retention in the dashboard.

Where your code goes

Cursor’s Privacy and Data Governance page lists two ways data leaves your machine:

1. LLM requests. Prompts and code context go to model providers such as OpenAI, Anthropic and Google, and to Cursor’s inference providers for its own models (Composer).
2. Cloud Agents. The docs call them “the only feature that requires Cursor to store code”: encrypted copies of the repository, kept while the agent runs and deleted afterwards. They are optional.

Data is encrypted with TLS 1.2+ in transit and AES-256 at rest. Enterprise customers can add customer-managed encryption keys (CMEK) and US-only data residency. For code search, the Search docs say file paths are encrypted before they are sent and code content is never stored in plaintext.

Agents are guarded by approvals, Run Modes and a sandbox

The bigger risk with any coding agent is what it can do on your machine. Cursor’s LLM Safety and Controls page is direct about it: agents “can read files you can read, write files you can write, execute commands you can execute,” and “there is no security boundary between agents and your user account.”

The guardrails the docs describe (Agent Security, Run Modes):

Cursor calls Run Modes “best-effort guardrails rather than a hard security boundary.” Extra protections can still force a prompt: Browser Protection, File-Deletion Protection (including rm) and External-File Protection for files outside the workspace.

Warning

Cursor’s docs say that with auto-approval “agents might run destructive commands without your knowledge, commands execute before you can review them, and bugs or prompt injection could cause unintended operations” (LLM Safety and Controls). The documented safer setup is Auto-review with sandboxing on, plus hooks that block commands such as git push or require approval for sudo, rather than Run Everything (Security and Privacy Hardening).

The sandbox uses Seatbelt on macOS and Landlock plus seccomp on Linux (kernel 6.2 or later); on Windows, Cursor’s sandboxing post says it runs its Linux sandbox inside WSL2. By default sandboxed commands can read and write the workspace, network access is limited to an allowlist, and paths such as .git/config, .git/hooks, .vscode and .cursorignore stay write-protected. Settings go in ~/.cursor/sandbox.json for all projects or .cursor/sandbox.json in a project. This is the example from the sandbox.json reference, for a project that installs packages, pulls container images and reads a shared design-tokens folder:

{
  "networkPolicy": {
    "default": "deny",
    "allow": [
      "registry.npmjs.org",
      "registry.yarnpkg.com",
      "pypi.org",
      "files.pythonhosted.org",
      "*.docker.io",
      "ghcr.io",
      "*.googleapis.com"
    ],
    "deny": [
      "*.internal.corp.example.com"
    ]
  },
  "additionalReadwritePaths": [
    "/home/me/.docker"
  ],
  "additionalReadonlyPaths": [
    "/opt/shared/design-tokens"
  ],
  "enableSharedBuildCache": true
}

Cloud Agents work differently: they run in per-agent Firecracker microVMs in a separate AWS account and auto-run terminal commands, which Cursor says carries a prompt-injection exfiltration risk; network egress allowlists, runtime secrets and draft pull requests are the documented mitigations (Cloud Agent security).

Keep secrets out of reach with .cursorignore

A .cursorignore file in the project root, in .gitignore syntax, blocks listed files from Agent, Tab, Inline Edit and @ references (Ignore file). Cursor already ignores everything in .gitignore plus a default list that includes .env*. The docs suggest these global patterns for all projects:

**/.env
**/.env.*
**/credentials.json
**/secrets.json
**/*.key
**/*.pem
**/id_rsa

Two limits are stated on the same page: terminal and MCP tools used by the agent “cannot block access to code governed by .cursorignore,” and “complete protection isn’t guaranteed due to LLM unpredictability.” Test a pattern with git check-ignore -v [file].

Extensions come from a filtered Open VSX registry

Cursor installs extensions from Open VSX through its own proxy, marketplace.cursorapi.com, which runs malware and supply-chain analysis before an extension is offered; teams can add an install cooldown, allowed-extension lists and signature checks (Extensions). The page warns that the same publisher.extension ID can point to different code on Open VSX than on Microsoft’s marketplace, so treat extension IDs like dependencies.

For what each plan includes, including team-wide Privacy Mode and admin controls, see the Cursor Hobby, Cursor Teams Standard seat and Cursor Enterprise listings. For how Cursor’s settings compare with Copilot’s, see GitHub Copilot vs Cursor.