Cursor Privacy Mode and Enterprise Controls: What Admins Can Actually Enforce

Cursor's enterprise story leads with Privacy Mode: with it enabled, per the Cursor docs, your code is never used for training by Cursor or other AI model providers, and most requests run under zero-data-retention agreements so providers do not store inputs or outputs. That is a real, contractual guarantee, and on the Business and Enterprise tiers an admin can force it on so members cannot turn it off. The question this post asks is narrower and more practical: once you have enforced Privacy Mode and the rest of Cursor's admin policy, what is left unmanaged on the actual machine. The short answer is the local artifact layer, and it is the same layer we keep returning to in securing AI coding agents and CLIs.

Privacy Mode and the enterprise control set govern where your data goes and who can sign in. They say very little about what code, MCP servers, and editor extensions are already sitting in a developer's config. That distinction matters because the two MCP-related CVEs that hit Cursor in 2025, CurXecute and MCPoison, both lived in that local layer, untouched by tenant-level data policy. So does the kind of git-hook sandbox escape tracked as CVE-2026-26268. Knowing your model traffic is private tells you nothing about what is running locally to generate it.

What Privacy Mode actually guarantees

Privacy Mode is a data-handling guarantee, not a runtime control. The Cursor docs describe it as zero data retention: most models run under Cursor's ZDR agreements with providers including OpenAI, Anthropic, and Google, so those providers do not store the prompts and completions or train on them. During codebase indexing, Cursor stores vector embeddings rather than your original source. There are documented exceptions worth knowing before you assume blanket retention is off: some models require retention approval because the provider stores inputs and outputs to run abuse-prevention reviews, and Cloud Agent repositories are held encrypted and temporarily until the run completes. Read the model list and the exceptions rather than treating Privacy Mode as a single switch.

On the Business and Enterprise tiers an admin can enforce Privacy Mode at the team level so individual members cannot disable it. The enforcement is not set-and-forget: Cursor re-verifies the setting on a short interval (the system checks roughly every five minutes and falls back to Privacy Mode if verification fails), and new members inherit the team setting automatically. For machines under MDM, the Allowed Team IDs policy prevents users from signing into personal accounts that would sidestep the org's protections. This is a genuinely strong data-residency control, and it is the part of Cursor's posture that maps cleanly to a compliance and audit trail requirement.

The enterprise control set, tier by tier

Cursor's admin controls are real and split across tiers, which is the first thing to get straight before you write a policy that assumes a capability you do not have. SSO and SAML are available on Teams and Enterprise. SCIM provisioning and deprovisioning, audit logs with SIEM streaming, the Repository Blocklist, Model Access Restrictions, and MCP configuration are Enterprise-only. Agent Sandbox Mode and hooks exist across tiers but are enforced org-wide and distributed through MDM or server-side mechanisms on Enterprise. SOC 2 Type II is available on request, with annual penetration testing. The table below summarizes the controls and what each one governs.

Three of these reach toward the local layer and are worth calling out. Agent Sandbox Mode plus the Auto-run, Browser, and Network controls decide whether the agent can run commands without asking. MCP configuration lets an Enterprise admin define which MCP servers members are allowed to use. And MDM can push a managed ~/.cursor/permissions.json to set a per-user MCP auto-run allowlist using server:tool syntax. These are the closest Cursor gets to governing the artifact layer, and they are an upgrade over nothing. They also point directly at where the gap reopens, which the next section covers. The pattern of governing tool calls at the agent boundary is exactly what we mean by runtime governance at the hook.

What these controls do not see

Every control above is scoped to the Cursor tenant or, in the MDM cases, to files Cursor itself reads. None of them inventory what is actually present on the endpoint. An MCP allowlist tells Cursor which servers a member may run; it does not tell you which MCP server definitions, with what commands and what credentials, are sitting in that developer's project and home directories right now. A model blocklist constrains Cursor's own traffic; it does nothing about a second AI CLI the same developer installed last week. Extension policy through MDM governs the editor's marketplace; it does not enumerate the binaries those extensions shell out to.

This is the same blind spot the Cursor MCP CVEs exploited. The MCPoison trust bypass worked because a previously approved MCP entry could be silently rewritten, and the approval was per-name rather than per-content. The CurXecute prompt-injection RCE turned a poisoned context into MCP-driven command execution. In both, the dangerous object was a local config file, and the data-retention guarantee was entirely orthogonal to whether that file was safe. Privacy Mode being on, verified every five minutes, would not have flagged either one.

What to check on your endpoints

If you have rolled out Cursor's enterprise tier and want to know what its controls are not covering, here is the practical checklist. None of these are answered by the admin dashboard.

• Which MCP server definitions exist in project and user config across the fleet, and what command and arguments each one launches.
• Whether any approved MCP entry has been modified since approval, since trust is typically keyed to the name, not the content.
• Which editor extensions are installed beyond what MDM policy expects, and what local binaries they invoke.
• Which other AI agents and CLIs are installed alongside Cursor on the same endpoint, outside any single tenant's policy.
• Where credentials and tokens sit in plaintext in agent and MCP config files, regardless of whether model traffic is under ZDR.
• Which git hooks or auto-run settings could let an agent execute outside the intended sandbox, the failure mode behind the git-hooks escape.

Cursor's admin team can answer some of this for the Cursor tenant on the Enterprise tier. It cannot answer it for the endpoint as a whole, because that is not what a vendor control plane is built to do. A practical comparison of where vendor controls end and endpoint inventory begins is laid out in how the layers compare.

Closing the local gap

Cursor's Privacy Mode and enterprise controls are a solid data-governance and identity foundation, and you should enforce them. They are simply scoped to one vendor's tenant and traffic, while the risk lives in the artifacts on the machine: the MCP servers, extensions, secrets, hooks, and the other CLIs running next to Cursor. That is the layer Anomity inventories on every managed endpoint, classifying each artifact and keeping a queryable audit trail, and on agents that expose a hook it returns allow, deny, or log on each tool call before it runs. It complements Cursor's controls rather than replacing them. If you want to see what is actually on your endpoints underneath the admin dashboard, start with the fleet inventory of AI artifacts or request early access.