Cursor security checklist 2026What to lock down. What to verify.

Knostic published their Cursor disclosure in late January 2026. The finding: Cursor's workspace sync was uploading the .cursor/ directory in its entirety, which includes your AI conversation history, your .cursor/rules/ files, and anything those rules reference. The issue surfaced in a broader look at how AI coding tools persist state to cloud sync services.

That came three weeks before Knostic's separate Claude Code settings.local.json finding in February. Both disclosures share the same shape: a tool that "remembers" your session state writes more than you expected to a predictable path, and that path makes its way somewhere else.

The response from Cursor's team narrowed the sync scope. But the default configuration remains permissive, and Privacy Mode does not do what most developers assume it does. This checklist covers every significant surface in the current Cursor build.

What to know in 60 seconds

• Privacy Mode opts you out of Anthropic/OpenAI training data pipelines. It does not disable workspace indexing.
• Workspace indexing sends file contents to Cursor's cloud for context retrieval. .cursorignore is the only way to exclude files from that.
• .cursor/rules/ files are synced alongside code. If your rules reference secrets paths or contain hardcoded values, those go with them.
• AI Pane conversation history persists locally in ~/Library/Application Support/Cursor/. It also syncs if you use Cursor account sync.
• Telemetry and crash reporting ship data on a different channel from model inference. Turning off Privacy Mode does not turn off telemetry.
• Every Cursor update can reset non-hardened settings. Verify after each release.

Enable Privacy Mode correctly

Open Settings > General > Privacy Mode and set it to Enabled. This opts your codebase out of being used to train Cursor's models and the upstream model providers they route through (OpenAI, Anthropic).

What Privacy Mode does not do:

• It does not stop indexing your codebase for context retrieval.
• It does not prevent crash reports or usage telemetry.
• It does not exclude any specific files from the upload stream.

The confusion comes from the label. "Privacy Mode" signals data hygiene in consumer tools. In Cursor it means training opt-out, which is a narrower thing.

After enabling it, check that the setting persists by restarting Cursor and reopening Settings > General. Some users on the Cursor Discord reported the toggle resetting on the 0.43.x release. If the setting is blank after restart, the toggle did not save.

Enterprise accounts: confirm Privacy Mode at the team level in the Cursor dashboard. The local app toggle is not enough. Individual developers can override it locally, but a team policy set in the dashboard wins.

Lock down workspace indexing with .cursorignore

Cursor indexes your workspace to give the AI context about your codebase. That indexing sends file contents to Cursor's servers. The scope is everything in the workspace unless you exclude it.

.cursorignore follows the same syntax as .gitignore. Create it at your project root:

touch .cursorignore

Add the paths that should not enter the index:

# Secrets and environment
.env
.env.*
.env.local
*.pem
*.key
*.p12
*.pfx
secrets/
credentials/

# Agent state files
.claude/
.cursor/

# Build artifacts (reduce noise)
node_modules/
.build/
dist/
__pycache__/

# Infrastructure that contains interpolated secrets
terraform.tfstate
terraform.tfstate.backup
*.tfvars

After saving, close and reopen the workspace. Cursor's index rebuilds incrementally, not immediately. Wait a few minutes, then open the Composer pane and ask it a question about a file you excluded. If Cursor can still quote the file's contents accurately, the exclusion did not take. Restart Cursor and recheck.

Commit .cursorignore to your repo. Anyone who opens the project in Cursor gets the same exclusions. Unlike a .gitignore entry for secrets, you want this file tracked: the team inherits the policy automatically.

Audit and harden .cursor/rules/

Cursor stores project-specific AI instructions in .cursor/rules/. These files are synced. They are also readable by any process that can access your workspace.

Common mistakes in rule files:

• Hardcoded endpoint URLs with embedded tokens.
• Database connection strings used as example context.
• Internal hostname patterns that reveal infrastructure topology.
• Commented-out credentials from a "quick test" that never got cleaned up.

Audit the directory:

find .cursor/rules/ -type f | xargs grep -l -E "(key|token|secret|password|bearer|api_key)" 2>/dev/null

Any hit needs immediate remediation. Move the sensitive value to a reference, not the literal. The rule can say "use the DATABASE_URL environment variable" rather than including the URL itself.

Rules files should also go in your .cursorignore if they contain context you do not want indexed, but note that excluding them means Cursor cannot use them for AI context retrieval. The alternative is keeping rule files clean enough to be safe in the index.

Control MCP server configuration in Cursor

Cursor supports MCP (Model Context Protocol) servers configured in .cursor/mcp.json. As of early 2026, OX Security counted roughly 7,000 MCP servers in the wild with around 150 million downloads and no signature requirement. An unvetted MCP server installed in Cursor gets model access to your workspace.

Check your current MCP config:

cat .cursor/mcp.json

For each server listed, verify:

1. The server binary is pinned to a specific version, not latest.
2. You recognize the source and have read the server's code or seen a credible third-party audit.
3. The server does not request filesystem permissions outside the workspace directory.
4. You installed the server intentionally, not because a .cursor/mcp.json was committed by someone else.

An MCP server you did not add is a red flag. Treat it the same as an unexpected npm dependency: find out who added it and why before you run it.

Remove servers you do not use. The attack surface for MCP is active; researchers published several prompt-injection-via-MCP findings in early 2026 (Snyk disclosed one involving a GitHub MCP server reading private repo contents through injected instructions). A server you are not using adds risk without adding value.

Turn off telemetry separately from Privacy Mode

Telemetry and crash reporting in Cursor run on a different toggle from Privacy Mode. Go to Settings > Cursor > Telemetry and disable both "Send usage data" and "Send crash reports".

These reports include editor activity metadata, session lengths, feature interactions, and crash stack traces. Stack traces can contain file paths, variable names, and in some configurations, partial file contents.

After disabling, verify the setting survived restart. Then check your system's network monitor or a proxy tool to confirm Cursor is not making outbound calls to telemetry.cursor.sh or similar domains during normal editing. The network check is the only reliable confirmation: managed device policies and Cursor's own update mechanism can both override the UI toggle.

For enterprise deployments: block telemetry.cursor.sh at the network level. You cannot trust every developer's local toggle.

Manage AI Pane history

Cursor stores your AI conversation history locally in:

~/Library/Application Support/Cursor/User/workspaceStorage/

Each workspace gets a subdirectory with a hashed name. Inside, conversation logs contain whatever you pasted into the AI pane, including any secrets you included in prompts.

If Cursor account sync is enabled (Settings > Sync > Turn On Settings Sync), this directory's contents sync to Cursor's cloud. That includes AI pane history.

To clear local history: open Command Palette, search "Clear AI Chat History", run it. This clears the active workspace view but does not delete the underlying workspaceStorage entries immediately.

For a hard clear:

# Close Cursor first
rm -rf ~/Library/Application\ Support/Cursor/User/workspaceStorage/

This deletes history for all workspaces. Cursor recreates the directory on next launch.

The safer practice going forward: never paste credentials into the AI pane. Ask about a secrets management pattern using placeholder names. The model does not need the actual value to help you debug an auth flow.

If you use Cursor's account sync, treat AI pane history as cloud-stored data. The same data minimization rules apply as to any SaaS product holding your codebase context.

Harden Composer permissions

Cursor's Composer (the agentic mode that runs multi-step edits) can read and write files across your workspace. The permission scope is set by what you give it at the start of a session.

Current limitations in Composer's permission model:

• There is no per-directory permission restriction. If Composer can write, it can write anywhere in the open workspace.
• Composer does not have a "dry run" mode that previews file writes before executing them.
• Terminal access in Composer is gated on a per-command confirmation, but that gate is easy to click through quickly during a long session.

Practical mitigations:

• Open only the directory you are working in, not the entire monorepo, when using Composer for significant edits.
• Review Composer's proposed changes before accepting batches. Each edit block shows the diff; read it.
• Keep secrets out of the workspace during Composer sessions. Use a scoped injection tool so Composer's process gets a reference rather than the literal value. Remove the credential from the environment when the session ends. With a broker like hasp, the workspace .env holds a stub reference; Cursor's indexer ships that reference to the cloud, not the live key it points to.
• If Composer requests terminal access during a session and you are not sure why, cancel and ask it to explain first.

The Replit incident from mid-2024, where an agent deleted a production database, is the canonical example of what happens when agentic write access meets insufficient confirmation gates. Cursor's Composer is not Replit's agent, but the permission problem is the same category.

Enterprise SSO and team controls

Enterprise Cursor accounts (Business tier) get controls that individual accounts do not.

Team Privacy Mode enforces the setting at the org level. Individual developers cannot disable it. Find it in the Cursor admin dashboard.

SSO with SAML/OIDC connects Cursor auth to your existing identity provider. Users who leave the org lose access immediately on IdP deprovisioning.

Cursor Business provides per-user audit logs covering Composer activity, model calls, and settings changes.

Domain restriction limits which email domains can join your org's Cursor workspace.

If you are on the Business plan, verify Team Privacy Mode is enabled in the admin panel. Individual settings are not sufficient. The January 2026 disclosure affected individual and team accounts equally because team-level Privacy Mode was not the default; it required explicit admin action.

SSO setup reduces the risk of shared or stale credentials in team tooling. A developer who left the company six months ago but still has a Cursor account with access to your team's shared configuration is a specific, real threat. IdP-linked SSO closes it automatically.

What gets missed in most Cursor hardening guides

Most guides stop at Privacy Mode. That is the wrong place to stop.

Privacy Mode addresses training data use. It does not touch indexing scope, telemetry, AI pane history sync, MCP server trust, or Composer's write permissions. Those are five distinct surfaces, each with its own control.

The second thing that gets missed: settings do not stay set. Cursor ships updates frequently. The January 2026 Knostic disclosure was partly a function of a prior update that silently expanded what .cursor/ sync included. After every Cursor release, open Settings, check Privacy Mode, check Telemetry, and verify .cursorignore is still present in the workspace. This takes two minutes. Do it.

Third: .cursorignore works only if it is in the workspace root that Cursor opened. If you open a parent directory and Cursor indexes subdirectories, each subdirectory needs its own .cursorignore or the parent's rules need to be explicit enough to cover them. Test this by checking what Cursor can see via @codebase references in the AI pane for a file you meant to exclude.

Checklist you can paste into a PR

## Cursor security hardening

- [ ] Privacy Mode enabled: Settings > General > Privacy Mode > Enabled
- [ ] Privacy Mode verified after restart (re-open settings, confirm still set)
- [ ] Team Privacy Mode enabled in Cursor admin dashboard (enterprise)
- [ ] .cursorignore present at workspace root, committed to repo
- [ ] .cursorignore covers: .env, .env.*, secrets/, .claude/, .cursor/, *.pem, *.key
- [ ] .cursor/rules/ files audited for hardcoded credentials or sensitive paths
- [ ] .cursor/mcp.json reviewed: all servers recognized, none running as unknown/latest
- [ ] Telemetry disabled: Settings > Cursor > Telemetry > both toggles off
- [ ] Account sync reviewed: AI pane history sync disabled if not intentional
- [ ] AI pane history cleared of sessions containing credentials
- [ ] SSO configured and IdP deprovisioning verified (enterprise)
- [ ] Cursor audit logs enabled and reviewed (enterprise)
- [ ] Re-verify all settings after next Cursor update

Run this after every major Cursor release. Keep it in your team's SECURITY.md so it does not live only in someone's head.

What this means for your stack

Cursor's hardening controls are mostly present, but they are not on by default and they do not hold through updates automatically. A checklist run by a single developer who then leaves the team is not a durable fix.

The deeper issue is the same category as the Claude Code incident from February: AI coding tools read your environment and persist what they see. The controls Cursor exposes reduce the upload surface. They do not remove it. Secrets that live as ambient environment variables or literal values in your workspace remain at risk even with Privacy Mode on, because the tool needs them to do its job, and "needs them" turns into "indexes them" faster than any settings panel can stop.

The durable fix keeps secrets out of the ambient environment entirely. A local credential broker holds secrets in an encrypted vault, injects them into specific child processes at exec time, and revokes access when the process exits. The tool sees a reference, not the value. hasp is one working implementation: curl -fsSL https://gethasp.com/install.sh | sh, hasp setup, connect a project, hand the next session a reference instead of a key. Source-available (FCL-1.0), local-first, macOS and Linux, no account.

The checklist above is worth running today. The runtime model change is what makes the next Cursor disclosure a non-event for your org.