Is Cursor safe? How to use it securely

Not with Privacy Mode on. Cursor says that with Privacy Mode, your data isn’t used for training and it has zero data retention agreements with its model providers. One exception is written in its data use page: prompts that trigger a provider’s abuse detection may be stored for investigation.

With Privacy Mode off, Cursor may store and use your codebase data, prompts and code snippets to improve its features and train its models. Privacy Mode is available on every plan, including the free one, and a team admin can turn it on for everyone.

Using your own API key doesn’t take Cursor out of the loop: Cursor says those requests still go through its backend, where the final prompt is built.

Not through the editor by default. Cursor ignores the files in your .gitignore and a default list that includes .env*, and you can add more paths to a .cursorignore file at the root of the project.

Cursor’s own documentation lists two limits. The terminal and the MCP tools used by the agent can’t be blocked from those files, so a command like cat .env still works, and complete protection isn’t guaranteed because models are unpredictable.

The safest habit is to keep production secrets out of your laptop altogether. Use test keys locally, with the lowest rights that work, and keep live keys in your host’s environment settings. A test key that leaks costs you a rotation, not your users’ data.

It depends on the run mode, set in Settings, Agents, Approvals & Execution:

• Auto-review, the recommended default, runs the commands on your allowlist, runs other shell commands in a sandbox when it can, and asks a classifier about the rest. Cursor says plainly that it isn’t a security boundary, because the classifier can make mistakes.
• Allowlist runs only the actions you listed, without asking.
• Run Everything runs every tool call with no sandbox and no review.

Avoid Run Everything, and keep the allowlist to commands that can’t delete files, push code or send data out, such as running tests or a linter. This matters because the agent reads files, web pages and issues written by other people, and any of them can contain instructions aimed at it.

An MCP server gives the agent new tools, with whatever access its credentials allow. Cursor’s advice is to install servers only from developers you trust and to review what data and APIs each one can reach.

Give each server the smallest token that works: read-only database credentials, a key scoped to one project, never a Supabase service_role key or a production admin token. If a server is compromised or tricked, that token is all it can use.

Only as secure as the code you accept. The mistakes it makes most often are the ones every AI tool makes: secret keys in frontend code, API routes that don’t check who is calling, and database tables without access rules. Our guide on securing a Cursor app goes through each one, with a project rule that makes Cursor write the safe version more often.

Our free scan checks the live site for leaked keys, exposed files and missing security headers in about a minute. The code scan runs on every pull request and is free for public repositories and 2 private ones a month. Neither one signs in, so test by hand that a second account can’t read the first one’s data.

• Cursor: data use
• Cursor: ignore files
• Cursor: run modes
• Cursor: security