Cursor security: privacy mode, run modes and what .cursorignore covers

Cursor security has two parts: how your data is handled, which Privacy Mode covers, and what the agent may do on your machine, which run modes, the sandbox, MCP approval and ignore files control. Cursor's own documentation calls its agent guardrails best-effort and not a hard security boundary, so a team should enforce the settings that matter and keep secrets out of reach.

What do Cursor's defaults protect?

Cursor's Agent Security page says sensitive actions need manual approval by default. Reading files and searching code do not need approval, agents can edit workspace files without approval (configuration files are the exception), and terminal commands need approval unless you change the run mode. Every MCP connection needs approval, and after that each tool call still needs its own approval unless you allowlist the tool. With default settings the built-in tools only make network requests to GitHub, direct link retrieval and web search providers.

One warning from the same page: with auto-reload on, agent changes can execute before you review them. Keep version control on.

What does Privacy Mode do?

Privacy Mode is the data side. Cursor sends prompts and code context to model providers such as OpenAI, Anthropic and Google. With Privacy Mode on, Cursor states that your code is never used for training by Cursor or other providers, and that most models run under zero-data-retention agreements. A few models need the provider to retain data. For Enterprise customers and for Privacy Mode users, those need admin approval before use.

It is on by default for team accounts, Enterprise included. Admins can enforce it for the whole team and use the Allowed Team IDs policy so people cannot sign into personal accounts on company devices. Privacy Mode says nothing about commands, so it is not an agent control.

Should you enable workspace trust?

Cursor supports VS Code's workspace trust and ships it disabled. Enable it in user settings:

"security.workspace.trust.enabled": true

Opening a new folder then asks for normal or restricted mode. Cursor warns that restricted mode breaks AI features, and advises using a basic text editor for untrusted repositories. Organizations can enforce the setting through MDM.

Which run mode should a team allow?

Settings > Agents > Approvals & Execution holds the choice, and it governs shell, MCP and Fetch calls.

Mode	What runs without asking
Auto-review	Allowlisted calls; other shell commands in the sandbox where possible; the rest go to a classifier
Allowlist	Only what is on your allowlist, with optional sandboxing
Run Everything	Every tool call, with no sandbox and no classifier

Cursor calls Auto-review the safest useful setup for most people and also says it is not a security boundary, since the classifier can allow something you would have blocked. Auto-review reads plain-English instructions from ~/.cursor/permissions.json or <project>/.cursor/permissions.json, merged when both exist; a team configuration in the dashboard takes priority and the local files are ignored:

{
  "autoRun": {
    "allow_instructions": [],
    "block_instructions": [
      "Every AWS CLI command should go through approval first."
    ]
  }
}

Enterprise admins who block certain models should check the classifier requirement. Cursor documents that blocking Claude 4.5 Haiku can disable Auto-review, and members then fall back to Allowlist.

How does the Cursor sandbox work?

The sandbox applies to terminal commands. On macOS it uses Seatbelt. On Linux it uses Landlock and seccomp and needs kernel 6.2 or later with unprivileged user namespaces, and if those are missing Cursor falls back to asking for approval. By default sandboxed commands can read and write the workspace, have no network until opened by your network mode and sandbox.json, and cannot write protected paths such as .git/config, .git/hooks, .vscode and .cursorignore.

Read access matters for secrets. The default System mode lets the agent read files outside the workspace without approval. Workspace mode asks first, and sandboxed commands then see less of the machine. Set it per machine or project with sandbox.json:

{
  "readBoundary": "workspace",
  "additionalReadPaths": ["/opt/shared/design-tokens", "~/notes/*.md"]
}

Enterprise admins can enforce Workspace read control for the team. Read access needs Cursor 3.23 or later.

What does .cursorignore protect, and what does it not?

.cursorignore uses .gitignore syntax and blocks listed files from code the Agent and Tab can access and from @ mention references. Cursor also ignores everything in .gitignore plus a default list that includes .env*. You can add global patterns in user settings, and Cursor suggests **/.env, **/.env.*, **/credentials.json, **/*.key, **/*.pem and **/id_rsa. The global list is empty by default.

The limits are stated plainly in the docs. The terminal and MCP tools the agent uses cannot be blocked from code governed by .cursorignore, and complete protection is not guaranteed because of LLM unpredictability. A command such as cat .env run in the terminal is a terminal action, not a file read, which is why the sandbox read boundary and approvals matter. For the cross-tool answer, see keeping secrets out of AI coding agents.

How does Cursor handle MCP?

Approval comes first: every connection, then every tool call. Run modes apply, so in Auto-review allowlisted MCP tools run immediately and the rest go to the classifier. Enterprise admins can set an MCP Allowlist in Team Settings with command entries for local stdio servers and URL entries for remote ones, plus per-server tool allowlists. Allowlisting approves a configuration and does not install the server. Cursor's own guidance is to install only from trusted sources and use restricted API keys. Our MCP security guide covers review in depth.

Are rules files a control?

No. Rules (.cursor/rules/*.mdc, user rules, team rules and AGENTS.md) are instructions put into model context. Cursor's hardening guide says to treat rules as suggestions and pair them with deterministic controls. They are also an injection surface, because a pull request can change them.

Hooks are the deterministic option. hooks.json at ~/.cursor/ or <project>/.cursor/ can run scripts on events such as beforeShellExecution and beforeReadFile. Project hooks also run in cloud agents, and user-level hooks do not.

What about the Cursor CLI?

The CLI has its own permission tokens, set in ~/.cursor/cli-config.json or <project>/.cursor/cli.json. They take the forms Shell(commandBase), Read(pathOrGlob) and Write(pathOrGlob), and the documentation uses Read(.env*) as an example of denying environment files. Settings in the editor do not carry over, so configure both if your developers use both. The CLI also reads sandbox.readBoundary from cli-config.json, and sandbox.json overrides it.

Where tooling fits

Cursor's controls stop at its own settings, and most teams run more than one agent (the AI coding agent security overview covers the wider rollout). Rechazo, which is in waitlist stage, adds checking of prompts for credentials before they leave the company, across Cursor and the other agents a team uses.

What to do this week

1. Turn on Privacy Mode for the team and enforce it with Allowed Team IDs.
2. Set the team run mode to Auto-review or Allowlist, and take Run Everything away.
3. Switch read access to Workspace and enable the sandbox.
4. Add global ignore patterns for env files, keys and credentials, and still keep secrets out of the repo.
5. Configure the MCP Allowlist with command and URL entries.
6. Review rules files and .cursor/hooks.json in pull requests.
7. Consider enforcing workspace trust by MDM for machines that open unknown code.