Cursor Data Residency: Regions, US-Only Mode, EU Gaps

Cursor publishes one residency program and it is enterprise-only. Enterprise customers can opt in to US-only data residency, which Cursor describes as keeping "inference, processing, and storage for supported features" in the United States. Enrollment is required, so no tenant gets it by default, and no other region is offered as a residency program today.

The phrase "supported features" is the part I would read twice. Residency applies to supported features and, in the pricing docs, to eligible models. Neither list sits on the regions page. Cursor's pricing page sends you to its privacy and data-governance documentation for supported regions, models and functions, so get that page during procurement and keep a dated copy in the security review file.

Residency also costs money. Cursor's models and pricing page puts opting in to regional data residency at a 10% uplift on model pricing for eligible models, so the charge scales with usage rather than arriving as a flat platform fee. A cost model that treats it as a fixed add-on will read low for heavy agent users.

Get that number into the budget while the residency requirement is still being drafted, since the two usually get priced by different people weeks apart.

Cursor routes requests to multiple model providers, and each provider has its own regional footprint. Cursor's regions page defers to provider documentation rather than promising anything on their behalf. Anthropic, OpenAI and Google each publish their own supported-regions lists.

The deferral reads like a dodge at first and holds up under scrutiny. Cursor is not the region authority for a Claude or Gemini request, and a commitment made on Anthropic's behalf would not survive an audit. What it costs you is paperwork: your compliance file needs each provider's own region documentation, cited and dated, for every third-party model you allow.

The concrete example that surprises teams: Grok 4.5, developed by Cursor with SpaceXAI and included in Cursor ModelsCursor's plan and usage pool for models it labels as Cursor Models, kept separate from the third-party Other Models pool. Press Enter for the full definition. for billing, launched unavailable in the EU. Cursor states it was "available in every country where Cursor normally offers models, except the EU at launch," with EU availability planned. Pool membership is not an ownership claim. If your rollout standardises on a model, check its current geographic availability before writing the policy.

Firewall reviews turn up a detail that invites the wrong conclusion. The granular allowlist in Cursor's network documentation includes us-only.gcpp.cursor.sh, us-eu.gcpp.cursor.sh and us-asia.gcpp.cursor.sh, described there as Cursor TabCursor's original autocomplete: multi-line, edit-aware suggestions you accept with the Tab key. Press Enter for the full definition. endpoints used depending on your location. I would keep those hostnames out of the residency section of a security review. There is an APAC hostname on that list and no APAC residency program, which is the sharpest evidence that these describe where a Tab request gets served rather than anything Cursor has committed to. Ask Cursor what they imply if your auditor pushes on it.

Partly, and only on the provider side. A BYO key routes the model call through your own provider account, so the region question for that call becomes a term in your contract with the provider.

Cursor supports bringing your own API key for OpenAI, Anthropic, Google, Azure OpenAI and AWS Bedrock. One of the documented reasons to use it is a team needing particular rate limits or a residency guarantee from the provider itself. Nothing published says a BYO key relocates Cursor's own processing or storage.

That move carries the retention guarantee with it, which is the part that catches people out. Cursor's Zero Data Retention policy does not apply to requests made with your own keys, and retention then follows whatever you have agreed with the provider. Billing does not get simpler either. Cursor's pricing page puts the Token Rate at $0.25 per million tokens on third-party model requests for Teams and Enterprise plans, and names BYOK usage alongside included and on-demand usage, so your own key moves the model charge without moving that fee.

Cursor's own hardening guidance points the other way and says to restrict personal API keys. Both positions hold, because an org-held key under a negotiated provider contract is a different object from one an engineer pastes into settings. Reading the docs the first time, BYOK looked to me like the EU workaround. It is narrower than that, closer to a way to move one contract, so reach for it only when your provider agreement is already the document your auditor reads.

Residency is one lever among several; most regulated-industry deployments combine four. Only the first is a residency control in the strict sense.

1. 1Enroll in US-only residency (enterprise): the formal program covering inference, processing and storage for supported features. Confirm the supported-model list and exclusions during procurement, not after.
2. 2Constrain the model list: admins can allowlist models team-wide, which indirectly pins your traffic to providers whose regions you have vetted. Grok 4.5 shows the pattern: on team plans an admin switches it on in team settings before anyone sees it in the picker.
3. 3Reduce what is retained: 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. and Zero Data Retention govern storage duration rather than location, often what the auditor actually cares about.
4. 4Move execution on-prem where offered: self-hosted cloud-agent runtimes keep tool execution and code checkouts on infrastructure you control, while Cursor's cloud still orchestrates.

The order matters because only the first step touches your contract, while the other three are settings you can revise on a Tuesday. Teams that run it backwards tend to start with self-hosted runtimes, the engineering-shaped task of the four, and end up spending the most effort for the least residency, because execution moves onto hardware you own while inference still leaves it. Locking the model allowlist before you have the eligible-model list is the cheaper version of the same mistake, and you unpick the allowlist afterwards.

Below Enterprise the first step is not available at all, so a smaller team's honest answer to a customer questionnaire is about retention and model choice rather than location. That means 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. locked on where you have an admin dashboard, and an allowlist of providers whose own region documentation someone has read rather than filed. What those two settings promise, and what they pointedly do not, is set out in Cursor security and Privacy Mode.

At Enterprise scale the work moves almost entirely into procurement. Put the review hour into the exclusion list and the 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. wording rather than the dashboard.

If a request that was supposed to stay in the US looks like it did not, establish which model served it before anything else. Auto routing picks per request and will switch models on degraded performance or provider downtime, so the model in the picker is not necessarily the model that ran. Then check whether a BYO key signed it. Whether either of those actually affects residency is a question for Cursor, and the answer belongs in writing before anyone repeats it to an auditor.