Cursor for Insurance Dev Teams: IP Protection, ZDR & CMEK (2026)

No, with Privacy ModeCursor's setting that guarantees code data is not used for training by Cursor or its model providers, and that an admin can enforce org-wide; data-retention terms are a separate, contractual layer. Press Enter for the full definition. enabled. Your code is never used to train Cursor or the model providers. Most models also run under zero-data-retention agreements, so inputs and outputs are not stored. For your most sensitive IP, Enterprise CMEK encrypts embeddings with a key you control.

The policy sentence is the weaker half of that answer, and a reviewer who has read a dozen of these will skim straight past it. What survives scrutiny is the storage answer. Cursor does not hold code content in plaintext on its servers. What the index leaves behind is numeric, and Cursor's stated position is that those vectors cannot be turned back into source, which is a claim about the shape of the stored data rather than a promise about anyone's conduct. Lead with that and keep the no-training line as the second point. If a reviewer asks how long any of it lasts, stored embeddings are deleted after six weeks of inactivity.

None of that covers the request itself. Code is transmitted to the model provider every time an agent answers, and Privacy ModeCursor's setting that guarantees code data is not used for training by Cursor or its model providers, and that an admin can enforce org-wide; data-retention terms are a separate, contractual layer. Press Enter for the full definition. is a commitment about training and retention. It says nothing about transmission. CMEK sits on the same side of that line. It is key custody over what Cursor stores, meaning embeddings and cloud-agent data, so it answers who can decrypt the index. Who processes a prompt is a separate question.

A carrier whose actual concern is who reads the code in flight should raise that in the first meeting, because the answer is the provider you selected and the retention terms attached to that model.

Most carrier review boards ask for the same evidence: a current audit report, the list of who touches your data, a signed data agreement, and a clear account of how your IP stays protected. Gather these four items before you open the questionnaire and you spend the review confirming details rather than chasing them.

1. 1Request the SOC 2 Type II report via trust.cursor.com.
2. 2Get the subprocessor list (OpenAI/Anthropic/Google as model providers).
3. 3Sign the GDPR/CCPA DPAData Processing Agreement. The contract spelling out exactly how a vendor may process your data: purposes, subprocessors, retention and breach duties. The document privacy reviews actually read. Press Enter for the full definition. if you process policyholder PIIPersonally Identifiable Information. Data that can identify a person (names, emails, SSNs); regulated and sensitive. Press Enter for the full definition..
4. 4Document CMEK + Privacy ModeCursor's setting that guarantees code data is not used for training by Cursor or its model providers, and that an admin can enforce org-wide; data-retention terms are a separate, contractual layer. Press Enter for the full definition. as your IP-protection controls.
5. 5Note the on-prem gap honestly: inference stays on Cursor's side, though self-hosted cloud agentsCloud agents whose infrastructure runs inside your own VPC, keeping more of the environment under your control and offering configurable retention. Press Enter for the full definition. (Enterprise) keep code and tool execution in your network.

Teams prepare for the first step and get judged on the second. What a carrier's review board wants to know is which third parties can see the code, and the answer is the model providers Cursor routes to. My first instinct was to treat that as a documentation exercise. It is closer to a configuration exercise. Enterprise admins allow or block models at the provider level, so an insurer that has vetted two providers can switch the rest off and answer with those two names instead of defending every provider Cursor supports.

Pin the current behaviour before you change anything. Rating engines and pricing logic tend to be old, thinly tested and the last place you want a change nobody noticed, so the tests that describe today's output have to exist before the agent opens the file. Guardrail tests for legacy refactors covers that loop step by step. The part specific to insurance is that correct output is defined somewhere outside your repository, so a green suite only counts if the suite was written against the behaviour you filed.

Reverse the order and the tests end up describing the refactor, which is the version of this that passes code review. The agent changes the code, the tests arrive afterwards, written against the behaviour that is now there, and they pass, because that is what they were written to describe. Nobody notices until a reconciliation run disagrees with last month, and by then the change is buried under a month of commits.

Run Mode belongs in the same decision. Auto-review runs allowlisted calls, sandboxes shell commands where it can and sends the rest through a classifier that returns allow or block, which is a better default than Run Everything on a repo that prices risk. It is best-effort, though. If there is a command you genuinely cannot afford to have run, back it with a hook and stop relying on the classifier for that one.

For review, Cursor's Security Reviewer checks pull requests before merge and the Vulnerability Scanner works over the codebase at rest. Both require Cloud AgentsAgents that run in a Cursor-managed virtual machine, check out the repo, do the work and open a pull request, then shut down, with no load on your laptop. Press Enter for the full definition., and Cloud Agents put your code on a VM disk inside Cursor's AWS infrastructure for as long as the agent is reachable. Environment snapshots are encrypted point-in-time copies of that disk, kept through 90 days of inactivity, with each resume pushing the expiry out another 90. A policy that bans cloud agents so no code sits on someone else's disk therefore rules those two reviewers out as well. Decide that trade before the policy sentence is written, because reversing it means reopening the vendor-risk file.

Yes, mostly in what triggers the work. A carrier has a vendor-risk function that will ask for all of this whether or not you have it ready. A twelve-person insurtech usually meets the same questionnaire secondhand, arriving with the first distribution deal, which tends to be the worst week of the year to start assembling evidence.

The small-team version skips the control stack and keeps two artifacts. Request the SOC 2 Type II report through trust.cursor.com, and write one page naming the models you allow and the data that stays out of prompts. Both take an afternoon, and between them they answer most of what a first-pass questionnaire asks. Which is enough at that size.

The one control I would add early regardless of size is CMEK, and that is a judgment call, not a requirement. It is Enterprise-only, so on a small team it means paying for a tier you would not otherwise need yet. If your whole differentiator is a pricing model, holding the key that decrypts its index is worth the line item.