playbook

Cursor Privacy Mode checklist for small teams

A practical checklist for verifying Cursor Privacy Mode before a small engineering team uses Cursor with private source code.

Bottom line

Cursor Privacy Mode should be enabled before a small team uses Cursor with private source code, but it should not be treated as a complete security program. It changes the data-handling posture around model-provider retention and training. It does not remove the need for repository classification, secret scanning, .cursorignore, human review, and rules for agents and terminal commands.

Use this operating rule:

Privacy Mode is required for company code, but approval still depends on the repository, data, secrets, agent permissions, and review process.

Cursor’s current Security page says Privacy Mode can be enabled in settings or by a team or enterprise admin, and that it is enabled by default for team members. The same page says Cursor uses technical controls and contractual requirements, including Zero Data Retention terms with model providers, so code data is not stored by model providers or used for training. Treat that as a strong baseline, not as permission to expose secrets.

Privacy Mode decision table

Team situation	Default decision	Why
Solo founder using Cursor on prototype code	Enable Privacy Mode	Keep the habit before the code becomes sensitive.
Small team using Cursor Team	Require Privacy Mode for every member	Team work should not depend on each developer remembering the setting.
Repository contains customer data or production logs	Block Cursor until data is removed	Privacy Mode does not make customer exports safe to paste or index.
Repository contains .env, private keys, or real credentials	Block until secrets are removed and rotated if exposed	Privacy Mode is not credential storage.
Developer wants background agents, terminal actions, or MCP tools	Require separate approval	Tool access can expose files, commands, logs, or network output outside the simple chat setting.
Team wants to disable Privacy Mode for productivity features	Require owner approval and written risk acceptance	Disabling privacy controls should be a business decision, not an individual convenience.

For secret-heavy repositories, use the Cursor rules for repositories with secrets before approving the workflow.

Setup checklist

Before the first team rollout:

• Create or use a team workspace for company work.
• Confirm Privacy Mode is enabled for every developer.
• Assign at least one technical admin and one backup admin.
• Document whether the setting is user-controlled, team-enforced, or enterprise-enforced.
• Classify repositories as approved, restricted, or blocked.
• Remove real .env files, private keys, customer exports, and production logs from approved workspaces.
• Add .cursorignore and .gitignore rules for local secrets and generated data.
• Run local and CI secret scanning before pilot use.
• Require code review for AI-generated changes.
• Require explicit approval for terminal commands, deployment scripts, cloud CLIs, package installs, and git history edits.

Record the owner and decision in the Small Team AI Security Checklist.

Admin verification record

Keep a short record instead of relying on memory:

Field	Value
Team owner	TBD
Cursor workspace	TBD
Privacy Mode status	Enabled / enforced / not confirmed
Verification date	2026-05-24
Verified by	TBD
Approved repositories	TBD
Restricted repositories	TBD
Blocked data types	Secrets, customer exports, production logs, regulated data
Agent permissions	Read only / edit only / edit plus approved terminal commands
Next review date	TBD

This record matters because Privacy Mode is a setting, not a durable operating process. Teams change, repos change, and new Cursor features can change the risk surface.

What Privacy Mode does not solve

Risk	Why Privacy Mode is not enough	Additional control
Real secrets in files	A model-retention setting does not rotate or hide credentials already in the workspace.	Secret scanning, secret managers, .env.example, rotation plan.
Customer data in prompts	Private data can still be processed during a request.	Redaction, synthetic fixtures, approval for customer workflows.
Terminal output	Command output can contain tokens, paths, account IDs, logs, or customer data.	Command allowlist and human review.
AI-generated insecure code	Privacy controls do not prove code correctness or safety.	Code review, tests, dependency review, security review for auth and data paths.
MCP or extension access	Extra tools can expand what the assistant can read or do.	Tool inventory, allowlist, least privilege.
Shared personal accounts	Privacy Mode does not fix identity, ownership, or offboarding gaps.	Company accounts, admin roles, SSO where available.

If a risk remains high after this table, run the AI Tool Risk Checker before allowing Cursor in that workflow.

Developer rule

Give developers this rule in plain language:

Do not put anything into Cursor that you would not put into a reviewed pull request, a CI log, or a trusted external security review packet.

That means no production API keys, no customer exports, no private keys, no payment records, no copied support tickets, and no confidential contracts. Privacy Mode is a guardrail around model-provider retention and training posture; it is not approval to share every sensitive file in the repository.

Two-week rollout

Time	Action
Day 1	Confirm Privacy Mode status for every developer and record the owner.
Day 2	Pick two low-risk repositories for the pilot.
Day 3	Remove local secrets and customer data from those workspaces.
Day 4	Add .cursorignore, project rules, and secret scanning.
Week 1	Allow chat, code explanation, and small edits only.
Week 2	Allow limited agent workflows after review of Week 1 diffs.
End of Week 2	Decide whether to approve, restrict, or block each repository.

Do not start with production infrastructure, authentication, payment, regulated data, customer exports, or incident-response repositories.

Evidence checked

• Cursor Security
• Cursor Privacy and Security docs
• Cursor data-use overview
• Cursor Models docs
• Cursor Members and Roles docs
• AI Tool Risk Checker
• Small Team AI Security Checklist

FAQ

Is Cursor Privacy Mode required for a small team?

For company code, yes. It should be a minimum requirement, especially for private repositories. The team still needs repository approval, secret scanning, review, and data-handling rules.

Does Privacy Mode mean code never leaves the machine?

No. Cursor’s own privacy documentation says requests are routed through Cursor’s backend, and codebase indexing can upload chunks for processing. The important question is how that data is retained, stored, and used, not whether every feature is local.

Can we use Cursor with customer support tickets?

Not by default. Redact tickets first, remove account identifiers and sensitive fields, and approve the workflow separately. Privacy Mode does not turn customer data into safe test data.

Should we let developers turn Privacy Mode off?

Not for company repositories without an explicit owner decision. If a feature requires disabling Privacy Mode, document the benefit, the affected repositories, the data involved, and the rollback rule before allowing it.

Recommended next step

Run the AI Tool Risk Checker for Cursor with your highest-risk repository. Then record Privacy Mode status, repository approval, and blocked data types in the Small Team AI Security Checklist.