Cursor Privacy Mode and MPL-Licensed Code: Data Handling Versus Licence Obligations

What Privacy Mode is for

Privacy Mode answers a confidentiality question: what happens to the code and prompts your developers send to the assistant. The relevant properties are retention, whether the data can be used for training, and how model providers handle it. Those are the right properties to review when source code is sensitive, and enabling the setting is a reasonable baseline for a security team.

It helps to treat the vendor's statements here as commitments to be recorded. The FTC has said that model-as-a-service companies that fail to honour privacy commitments, including promises not to use customer data to train or update models, may be liable under the laws it enforces. It has also said that commitments made in terms of service or promotional materials count. For your own records, note where each retention and no-training commitment is made and whether it is contractually binding.

None of this is about the licence status of what comes back. A setting that limits how your data is used on the way in says nothing about where the model's output came from on the way out.

Where the residual risk sits for MPL-licensed code

MPL-2.0 is a file-level copyleft licence. The practical consequence is that obligations follow the covered files, not the whole product. If an assistant's output reproduces or closely derives from MPL-covered source, the question for your team is which files in your repository now contain that material and what that means for them. Legal counsel should decide how the licence applies. The engineering task is to make the facts available to them.

Three areas remain open after Privacy Mode is enabled. The first is suggestion origin: nothing about the privacy setting tells you whether a given suggestion resembles licensed code. NIST's generative AI profile notes that outputs displaying memorisation of training data can raise copyright concerns, and it suggests measures to prevent, flag or take other action on outputs that reproduce licensed content.

The second is the file-level obligation itself. Without knowing which files contain material of MPL origin, you cannot scope the obligation or show that you have addressed it. The third is the absence of per-interaction evidence. If the only record is a developer's recollection or a commit message, an auditor has little to examine.

Treat the assistant's output the same way you treat any other code. NIST SP 800-218A does not distinguish between human-written and AI-generated source code and assumes all of it is evaluated before use. That puts AI-assisted changes through your existing pre-use evaluation, with licence checks added to it.

One implementation approach

Trussed is built for the second half of this problem. It enforces policy in the execution path across models, agents, tools, MCP servers and coding assistants, with allow, redact, block, rate limit and escalate for human approval applied to individual interactions and tool calls. Its code provenance covers the origin, licence and security context of code, and enforcement produces continuous audit-ready evidence mapped to frameworks including NIST. It can be deployed self-managed in the customer cloud, with configurable retention and data residency, which matters because provenance records are themselves subject to privacy and security policy.

This complements Privacy Mode rather than replacing it. The privacy setting covers how data is handled by vendors and providers. Runtime enforcement and provenance cover what the assistant was allowed to do and what it did, which is what a regulated enterprise needs to show an auditor.