Does Cursor AI Store My Code in the Cloud? (Privacy)

Cursor sends your code to the cloud to generate AI responses, so your code does leave your machine, but whether it is stored depends on Privacy Mode. With Privacy Mode on, Cursor does not store or train on your code, and it has zero-data-retention agreements with its model providers, so nothing survives the request. With Privacy Mode off, Cursor may store and train on your codebase data. There is no fully local AI mode: editing is local, but the AI features require sending code to the cloud.

Short answer

Your code is processed in the cloud, but not necessarily stored. According to Cursor's Data Use documentation, Privacy Mode means Cursor will not train on your data or store your code, while turning it off lets Cursor use and store codebase data to improve its models. Codebase indexing uploads code in small chunks to compute embeddings, but Cursor's security page states the plaintext code is discarded after the request, leaving only obfuscated embeddings and metadata. Cursor also maintains zero-data-retention agreements with its model providers. So the honest answer is: processed in the cloud, yes; stored, only if you leave Privacy Mode off.

Is my code processed locally or in the cloud?

The AI features are cloud-based, so your code is sent to Cursor's servers and to model providers to generate a response. Editing files, navigating, and running your project happen locally as in any editor, but the moment you ask the AI to complete, explain, or refactor code, the relevant context leaves your machine. There is no mode where Cursor's AI runs entirely on your computer.

This is the part that surprises people who assume "AI in the editor" means "AI on the laptop." It does not. The distinction that actually matters for privacy is not local versus cloud processing, because processing is always cloud; it is whether that transmitted code is retained after the request, which is exactly what Privacy Mode controls.

What Privacy Mode actually does

Privacy Mode is the single most important setting for code privacy in Cursor. With it enabled, Cursor does not store your code and does not use it to train models; your code is used only to serve your request and is not persisted afterward. With it disabled, Cursor may use and store codebase data, prompts, editor actions, and code snippets to improve its AI features and train its models.

The table below contrasts the two states so the trade-off is clear.

For teams, Privacy Mode is enforced by default on Business and Enterprise plans, so an organization can guarantee it across everyone rather than relying on each developer to toggle a setting. If proprietary code is a concern, this enforcement is the cleanest way to remove the risk of someone leaving it off.

Does codebase indexing store my code?

Codebase indexing feels like the scariest part, but it is designed to avoid storing your code. When you index a project, Cursor uploads it in small chunks to compute embeddings, and per its security documentation, the plaintext code ceases to exist after the life of the request. What remains in Cursor's database is the embeddings plus metadata such as hashes and obfuscated file names, not your source.

Cursor's secure indexing design goes further: code chunks are encrypted, file names are obfuscated, and when the agent later searches, the chunks are decrypted on the client side. The practical result is that indexing gives the AI a semantic map of your codebase without keeping a readable copy of it on the server. It is a meaningfully different thing from uploading your repository and leaving it there.

What Cursor stores, and what it does not

With Privacy Mode on, the mental model is simple: Cursor stores derived data, not your code. It keeps embeddings and obfuscated metadata so features like codebase search work, but it does not retain the plaintext source, prompts, or snippets for training. Your code exists on their servers only for the instant it takes to answer a request.

With Privacy Mode off, the picture changes: Cursor may retain codebase data, prompts, and code snippets to improve its product and train models. Neither state is hidden; both are described in Cursor's data-use documentation. The choice is yours, and it comes down to whether you want the product-improvement trade-off or the strict no-storage guarantee.

Zero data retention and the model providers

A common worry is not Cursor itself but the third-party models it calls, such as those from major AI labs. Cursor addresses this by maintaining zero-data-retention agreements with its model providers, meaning those providers do not store the code sent to them to fulfill a request. This closes the gap that would otherwise exist between "Cursor does not store my code" and "but the model behind it might."

It is worth being precise about scope. Zero data retention covers the providers processing your requests; it does not change the fact that the code is transmitted to them in the moment. For the vast majority of teams that is an acceptable trade, but if your policy forbids any transmission of source to third parties at all, no cloud AI editor will satisfy it, and that is a reason to reconsider using one rather than a flaw in Cursor's handling.

SOC 2, GDPR, and enterprise controls

For organizations that need documented assurances, Cursor maintains SOC 2 Type II and GDPR compliance, with attestation reports available through its trust portal on request. These are the artifacts a security team typically asks for before approving a tool, and their existence is what lets Cursor be used inside regulated companies.

Enterprise plans add controls beyond the individual settings, including enforced Privacy Mode, along with compliance and monitoring features. If you are evaluating Cursor for a company rather than yourself, these organization-level guarantees, backed by the SOC 2 report, are the right basis for the decision, rather than the default consumer settings.

How to protect proprietary code in Cursor

If you work with sensitive code, a few habits remove most of the risk. The checklist below covers the essentials, in priority order.

The two highest-impact steps are enabling Privacy Mode, ideally enforced at the organization level, and keeping real secrets out of the codebase entirely, so that even the code sent to serve a request never contains a live credential. A .cursorignore file lets you exclude sensitive paths from indexing and context, narrowing what is ever transmitted.

The other risk: what the AI writes

Privacy is only half the story with any AI coding tool, and often the smaller half. The bigger practical risk for a shipped app is not that Cursor stored your code, but that the code it helped you write contains security flaws: a hardcoded API key it suggested, an insecure network call, or a weak permission setting. AI assistants optimize for code that works, not code that is secure, and they reproduce insecure patterns from their training data.

A scanner like PTKD.com analyzes your built .ipa or .apk and returns findings ordered by severity and mapped to OWASP MASVS, so AI-generated code gets checked for embedded secrets, insecure storage, and network issues before you ship. To be clear about the boundary: PTKD has nothing to do with Cursor's data storage or privacy settings, and it does not review your source in the editor. It checks the app you build, which is where an AI-introduced flaw actually reaches users.

What to take away

• Cursor processes your code in the cloud; there is no fully local AI mode.
• Whether your code is stored depends on Privacy Mode: on means no storage or training, off means it may be stored.
• Codebase indexing uploads chunks to compute embeddings but discards the plaintext, keeping only obfuscated embeddings and metadata.
• Cursor holds zero-data-retention agreements with its model providers and maintains SOC 2 Type II and GDPR compliance.
• Beyond privacy, scan AI-generated builds with PTKD.com, because the bigger risk is often the insecure code the AI writes.