Cursor AI Security: What Privacy Mode Covers and What It Leaves to You

The short answer: Cursor's enterprise controls (enforced Privacy Mode, the Allowed Team IDs MDM policy, admin approval for models that retain data) do a good job of securing Cursor itself. They can't see what the same developer pastes into the next AI tool on the same laptop. Our position: Cursor AI security only holds when Cursor is one policy inside an endpoint-wide AI control, and dope.security provides that control by inspecting every process's AI traffic on the device.

Cursor deserves credit here. Its documentation is unusually clear about where code goes and what's retained, which is more than most AI vendors offer. The gap isn't in Cursor. It's in treating Cursor as the whole developer AI problem, a pattern we see constantly in how shadow AI detection actually works on real fleets: the approved tool is locked down and the unapproved ones are wide open.

This guide covers what Cursor's own controls do, where their scope ends, and how to build a Cursor policy that survives contact with real engineers. If you're mapping the broader category first, start with our roundup of shadow AI tools for developer AI.

What does Cursor send off your laptop?

Cursor's privacy and data governance documentation describes two data flows. The first is LLM requests: when developers use AI features, Cursor sends prompts and code context to model providers such as OpenAI, Anthropic and Google, and to its own inference providers for Cursor's custom models. The second is Cloud Agents, which Cursor calls the only feature that requires it to store code. Cloud Agents keep encrypted copies of the repositories they work on in isolated virtual machines while they run and delete them when the agent completes.

That's a clean, honest model. It also tells you the security question isn't “does Cursor see our code?” It does, by design. The question is which accounts, which models and which retention terms apply when it does.

What Cursor's enterprise controls cover

Cursor gives admins real levers, and you should use all of them:

• Privacy Mode: with Privacy Mode enabled, Cursor says your code is never used for training by Cursor or its model providers. It's on by default for Enterprise teams and can be enforced at the team level so members can't turn it off.
• Zero data retention agreements: most models run under Cursor's ZDR agreements, so providers don't store inputs or outputs or train on them.
• Admin approval for retaining models: a few models require retention with their provider. For Enterprise teams and Privacy Mode users, requests to those models fail until an admin approves the retention policy, and admins can limit which groups can select them.
• Allowed Team IDs via MDM: this policy prevents users from logging into personal Cursor accounts, which may not have Privacy Mode on, on corporate devices.
• Data residency and CMEK: Enterprise customers can enroll in US-only data residency (with a 10% uplift on eligible model pricing) and use customer-managed encryption keys for Cloud Agent data.

If you run Cursor Enterprise, turn on enforced Privacy Mode and push Allowed Team IDs through your MDM today. That closes the most common Cursor-specific leak: a developer signed into a personal Cursor account on a work machine.

Where Cursor's controls stop

Every control above governs Cursor. None of them governs the developer. That distinction is where Cursor AI security usually breaks down, for four reasons.

First, developers don't use one AI tool. The same engineer who works in Cursor all morning pastes a stack trace into a personal ChatGPT tab at lunch, runs a CLI agent against the repo in the afternoon, and tries a new model playground on Friday. Cursor's settings can't see any of that.

Second, Cursor's own documentation lists what sits outside its guarantees. For US data residency, it notes that bring-your-own-key setups, custom models reached through an OpenAI-compatible base URL or third-party gateway, and user-configured MCP servers and connectors each carry their own region. Those are exactly the integrations power users add. Our explainer on shadow MCP and the servers hiding in your developer tools covers why that last category is growing fast.

Third, Allowed Team IDs only works for Cursor. There's no equivalent switch that stops the same laptop from reaching a personal Claude or ChatGPT account.

Fourth, Cursor's admin dashboard shows Cursor usage. It can't tell you whether Cursor is 10% or 90% of your developers' AI activity, which is the number you need to size the risk. Without that baseline, a policy review becomes a debate about anecdotes instead of a decision based on what your developers actually do every day.

What a Cursor-adjacent leak actually looks like

Picture a senior engineer on a Cursor Enterprise team. Privacy Mode is enforced, Allowed Team IDs is deployed, and the security review signed off on Cursor last quarter. Everything about Cursor is configured correctly.

On Tuesday she hits a gnarly production bug. Cursor's suggestions aren't landing, so she opens a browser tab, signs into the personal ChatGPT account she's had since 2023, and pastes in a 400-line config file to get a second opinion. That file contains a database connection string and a customer's tenant ID. On Wednesday a teammate installs a new CLI agent he saw on a forum, points it at the monorepo, and lets it call a model API with his own key. On Thursday someone adds an MCP server from a public registry to their Cursor setup to pull tickets from the issue tracker.

None of those events touch a Cursor setting. Cursor's dashboard looks perfect all week. The data still left the building three times, through three different processes, to destinations nobody approved.

This is why we argue the Cursor review is necessary and nowhere near sufficient. The unit of risk isn't the editor. It's the developer's laptop and every process on it that can open a connection to a model. Governing that requires a control that sits below the apps, sees every outbound connection, and knows which process made it.

Govern Cursor from the endpoint, not just the dashboard

dope.security runs a proxy agent on each Mac and Windows device that inspects traffic locally and sends it straight to the internet. Because the agent sits at the endpoint's networking layer, it associates each connection with the process that opened it. That's the detail that makes developer AI governable. A browser tab, the Cursor app, a Python script and a CLI agent can all call the same model API, and the domain alone doesn't tell you which one did. The originating process does.

Here's what that adds on top of Cursor's own controls:

• Discovery across every AI tool: the AI Usage view in dope.console lists every AI app seen on your endpoints, ranked by transactions, users and data volume, with no extra sensors. You see Cursor next to everything else your developers use.
• Policy on the tools Cursor can't reach: allow, warn or block AI apps by name or category with a dope.swg policy, pushed to every device in seconds.
• Personal versus corporate accounts: Cloud Application Control restricts ChatGPT, Claude and GitHub to your enterprise tenants and blocks personal accounts on the same domains, the same idea as Allowed Team IDs, applied beyond Cursor.
• Prompt and upload DLP: Dopamine DLP reads prompts and file uploads on the device and classifies them with an LLM for intellectual property, PII, PCI and PHI. For Claude, coverage includes the desktop app and integrations such as the CLI, VS Code and Cursor.

Explore the full approach on our AI governance page.

Cursor admin controls vs an endpoint AI control

These two layers aren't competitors. They answer different questions, and you want both.

Cursor Enterprise controls

Cursor's controls govern how Cursor handles your code: training, retention, which models are allowed, where inference runs, and which Cursor accounts can log in on managed devices. They're precise and well documented. Their scope ends at Cursor's boundary, by design.

dope.security

dope.security governs what leaves the laptop, whichever process sends it. It sees Cursor alongside ChatGPT, Claude, Copilot, Gemini, CLIs and scripts, controls personal versus corporate accounts on the services that support it, and inspects prompts and uploads for sensitive data before they leave. It works on any network, so the policy follows the developer home and abroad.

• Scope: Cursor governs Cursor. dope.security governs every AI destination the endpoint talks to.
• Personal accounts: Cursor blocks personal Cursor logins via MDM. dope.security blocks personal ChatGPT, Claude and GitHub accounts on the same device.
• Sensitive data: Cursor controls retention and training after code is sent. Dopamine DLP can block a sensitive prompt or upload before it's sent.
• Visibility: Cursor's dashboard shows Cursor usage. dope.console shows all AI usage, per user and per app, exportable for your CISO or auditors.

A practical Cursor security policy in five steps

Here's the rollout we recommend for teams adopting Cursor at scale:

• Step 1, lock down Cursor itself: enforce Privacy Mode at the team level, push Allowed Team IDs via MDM, and keep retaining models disabled unless a group needs them.
• Step 2, baseline everything else: deploy the dope.security agent through Intune, Jamf or Kandji and run the AI Usage view for a week. Expect to find more AI tools than you planned for.
• Step 3, pick sanctioned tools: decide which assistants you'll support alongside Cursor and use Cloud Application Control to allow only the corporate tenants.
• Step 4, turn on Dopamine DLP in Monitor mode: watch what sensitive data shows up in prompts and uploads, then move high-risk groups to Block.
• Step 5, write the policy people will follow: publish which tools are approved and why, and make the approved path the easy one.

For the companion piece on GitHub's assistant, see our guide to GitHub Copilot security risks and controls, and for the wider category, shadow AI tools for AI coding assistants.

Deploying fast without breaking developer workflows

Developers are the least patient users in any company, and they should be. Security that slows a build or breaks a CLI gets bypassed. dope.security inspects on the device with no detour to a data center, stays under 100 MB of RAM, and surfaces SSL errors from certificate-pinned tools so admins can add a bypass in a few clicks. A Fortune 100 company rolled dope.security out from 900 to more than 18,000 devices in weeks, silently through Intune, which is the kind of lift you want when the population is engineers.

The bottom line

Lock Cursor down with its own controls; they're good. Then accept that Cursor is one window on a laptop with a dozen AI destinations, and govern the laptop. Cursor's settings decide what Cursor does with your code, and an endpoint control decides what your code is allowed to reach in the first place. Book a 20-minute demo and we'll show you every AI tool your developers used last week.

Frequently Asked Questions

Is Cursor safe for enterprise use?

Cursor offers strong enterprise controls: Privacy Mode (on by default for Enterprise teams and enforceable), zero data retention agreements with most model providers, admin approval for models that retain data, and US data residency. The remaining risk is everything around Cursor, such as personal AI accounts and other tools on the same laptop, which dope.security covers from the endpoint.

Does Cursor store or train on my code?

With Privacy Mode enabled, Cursor says your code is never used for training by Cursor or its model providers. Cloud Agents are the only feature that stores code, as encrypted copies held while the agent runs and deleted afterward. A few models require provider-side retention and need admin approval before use.

How do I stop developers using personal Cursor accounts on work laptops?

Use Cursor's Allowed Team IDs policy, deployed through your MDM, which blocks logins to accounts outside your approved teams. To apply the same corporate-only rule to ChatGPT, Claude and GitHub, use dope.security's Cloud Application Control, which allows your enterprise tenants and blocks personal accounts on the device.

Can DLP inspect prompts sent from Cursor?

dope.security's Dopamine DLP inspects prompts and uploads on the device and documents Claude coverage across the desktop app and integrations including the CLI, VS Code and Cursor. It classifies content with an LLM for intellectual property, PII, PCI and PHI, in Monitor or Block mode.

Does a cloud proxy work for governing AI coding tools?

Cloud proxies can inspect desktop and CLI traffic when their agents steer it to the vendor's data center, but certificate-pinned developer tools often end up on bypass lists and every request takes a detour. dope.security inspects on the device and attributes traffic to the originating process, so you can tell Cursor from a script calling the same API.