Security, Governance & Architecture

Inside a strategic account, the deal does not die on price. It stalls on one question a security lead asks in the first 20 minutes: where does our code go?

As the post-sale SA, you inherit accounts that already bought Cursor for one team and now want to expand. Expansion routes straight through the security org, so the privacy answer is your unblock, not a footnote. Get it precise and you open the door to every other team. Get it vague and the account freezes at its current seat count.

What Privacy Mode actually guaranteessay it precisely

Privacy ModeCursor's setting that routes requests under zero-data-retention terms so providers don't store or train on your code. with zero-data-retention terms means code sent for inference is not stored and is not used to train models. That is the claim a customer can put in front of their own legal team, so state it as a bounded fact rather than a comfort blanket.

How a request actually flows

Reviewers trust people who can draw the data path. Walk it concretely: the editor builds context from the open files and indexed codebase, sends only what the request needs to Cursor's backend, which routes to a model provider for inference and returns the completion.

1. 1Editor. Your local Cursor client assembles context - the active file, relevant indexed snippets and the prompt. Indexing computes embeddings; the plaintext code is not warehoused for training.
2. 2Cursor backend. Receives the request over TLS, applies your org's policy (model allowlist, Privacy ModeCursor's setting that routes requests under zero-data-retention terms so providers don't store or train on your code.) and forwards to the selected provider.
3. 3Model provider. Runs inference and returns the completion. Under managed inference with ZDRZero Data Retention. A contractual guarantee that the model provider won't store your code or train on it., that request is not retained provider-side.
4. 4Return path. The completion comes back to your editor as a diff you review like any other change.

Addressing IP-leak fear head-on

The fear under the question is rarely about retention mechanics. It is the nightmare of proprietary source landing in a model's training corpus and resurfacing for a competitor. Name that fear out loud, then hand back specifics: ZDRZero Data Retention. A contractual guarantee that the model provider won't store your code or train on it. terms, the SOC 2 report, Privacy ModeCursor's setting that routes requests under zero-data-retention terms so providers don't store or train on your code. as an enforceable org setting and private connectivity options for traffic that must stay off the public internet.

At a few seats, identity is a login. At a few thousand seats, identity is a lifecycle and the lifecycle is what a security reviewer audits.

Your job as SA is to wire Cursor into the identity machinery the customer already runs, so that provisioning, access and offboarding happen without a human touching a console. Three primitives carry the weight.

The three identity primitives

Admin controls and org-wide policy

Identity decides who is in. Policy decides what they can do once in. For a large org you set org-wide defaults so an individual developer cannot quietly weaken the posture.

• Privacy ModeCursor's setting that routes requests under zero-data-retention terms so providers don't store or train on your code. enforced as an org policy, not a per-user toggle.
• Model and MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. allowlists that bound what tools and providers are reachable.
• Team-scoped settings so a regulated business unit can run a stricter policy than a platform team.
• Admin-only control of billing, member management and analytics access.

Audit & visibility for the compliance team

Security and compliance teams do not just want controls. They want to see the controls operating. Audit logs and usage analytics give them the immutable who-did-what record and seat-level visibility they need for their own reporting.

A platform lead's real worry is not that AI writes code. It is that AI writes a lot of code, fast and their existing safety net was sized for human throughput.

Your advice flips that worry into a design principle: AI raises the volume of change, so review and testing rigor matters more, not less. The good news you deliver next is that the safety net already exists in their pipeline and does not need rebuilding.

Code review and CI are the safety net

AI-authored changes flow through the identical gates as human changes. The agent is an author. It opens a diff that a human reviews and that CI gates before merge. Nothing about AI involvement bypasses the existing controls.

Rules and standards as the upstream constraint

Catching every problem in review is expensive. The cheaper lever is constraining output before it is written. Cursor Rules (and .cursorrules / .cursor/rules) encode the org's conventions, banned patterns and security practices so generated code starts aligned with the house standard.

# Security & convention rules applied to AI-authored code
- Never log secrets, tokens or PII; use the redaction helper in lib/log.
- All DB access goes through the repository layer; no raw SQL in handlers.
- Validate and parameterize every external input; no string-built queries.
- New endpoints require an authz check and a test before they merge.

Rules do not replace review. They raise the floor, so the diff a reviewer sees already follows conventions and the review focuses on intent and edge cases instead of style nits.

Licensing & provenance - talk about it honestly

Senior engineers will ask about licensing and provenance of generated code. Do not wave it away. The honest framing: treat AI-suggested code with the same diligence as any code entering the repo and lean on the supply-chain controls already in CI.

• SCASoftware Composition Analysis. Scanning third-party dependencies for known vulnerabilities and license problems. flags known-CVE and license-incompatible dependencies an agent might pull in.
• SBOMSoftware Bill of Materials. A list of every component and dependency in a build, like an ingredients label for software. keeps the component inventory accurate regardless of who added a dependency.
• Human review remains the accountability boundary for what enters the codebase.
• Where the customer has a stricter policy, encode it as a Rule so it shapes output early.

Helping a platform team write an internal AI-coding policy

The deliverable a platform team actually wants from you is a short, enforceable policy they can publish. Help them write it around four decisions.

An architecture review is where you stop being a vendor presenting features and become the peer the customer's architects design with.

The JD asks you to lead these reviews for a reason: in a strategic account, the platform and security architects decide whether Cursor becomes standard tooling or stays a quarantined experiment. A good review produces a written recommendation those architects can circulate and defend internally.

The structure that earns trust

1. 1Current state. Map their SDLC, identity stack, network boundary and CI/CDContinuous Integration / Continuous Delivery. The automated pipeline that builds, tests and ships code so changes reach production safely and often. topology as it exists today - before proposing anything.
2. 2Requirements & constraints. Capture the non-negotiables: data residency, ZDRZero Data Retention. A contractual guarantee that the model provider won't store your code or train on it. requirements, approved IdP, network egress rules, in-scope regulated systems.
3. 3Integration points. Identify exactly where Cursor touches their world: IdP for SSOSingle Sign-On. One company login (usually via SAML or OIDC) instead of a separate password per tool./SCIMSystem for Cross-domain Identity Management. A standard for automatically creating and removing user accounts when people join or leave., git host and CI for the change pipeline, MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. for internal context sources.
4. 4Risks. Surface what could go wrong and how each is mitigated - before security raises it.
5. 5Recommended target architecture. Propose a concrete configuration, then explicitly contrast the ideal with what they can adopt now.

Mapping Cursor into their topology

The heart of the review is placing Cursor into four existing planes the customer already runs. Do it as a table they can paste into their own doc.

The written artifact

Reviews that live only in a meeting evaporate. Produce a short recommendation document stakeholders can forward to their CISOChief Information Security Officer. The executive who owns security; usually the hardest and most important person to win over. and CTO. It does not need to be long - it needs to be defensible.

In a locked-down enterprise, the question is not whether Cursor is good. It is whether Cursor can reach what it needs through a proxy, a firewall and an egress policy designed to say no.

You need a working mental model of how Cursor connects, integrates and routes, so you can answer infra questions in the room and know the line where you pull in Cursor's product or security experts instead of guessing.

Network, proxy & connectivity

Locked-down environments route egress through corporate proxies and allow only approved destinations. Cursor must be reachable through that path and sensitive customers want the path to stay off the public internet entirely.

Integrating into the existing toolchain

Cursor lives inside the developer's loop, so it touches the tools that loop already runs. Two categories matter: the change pipeline and the context sources.

Model routing & data locality

Model selection is a trade-off you must be able to explain. Managed inference keeps ZDRZero Data Retention. A contractual guarantee that the model provider won't store your code or train on it. terms intact and is the simplest posture. Bring-your-own keys gives the customer provider control but moves the data terms to that provider, which is a governance change, not just a config flag.

Standardizing config so expansion stays governable

The whole point of post-sale ownership is that team #12 should be as governed as team #1. Standardize the configuration so expansion is a repeatable change, not a fresh negotiation each time.

• Use Organizations as the admin plane, with Groups for per-business-unit policy.
• Ship a baseline config (Privacy ModeCursor's setting that routes requests under zero-data-retention terms so providers don't store or train on your code. on, model allowlist, MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. allowlist) every new team inherits.
• Mirror SCIMSystem for Cross-domain Identity Management. A standard for automatically creating and removing user accounts when people join or leave. groups to team topology so onboarding a team is a directory change.
• Keep Rules in the repo so standards travel with the codebase, not the individual.

The privacy foundation answers where code goes. The next question a platform team asks is sharper: now that an agent can run commands and reach tools on its own, what stops it from doing the wrong thing?

Privacy ModeCursor's setting that routes requests under zero-data-retention terms so providers don't store or train on your code. by default, ZDRZero Data Retention. A contractual guarantee that the model provider won't store your code or train on it. with every provider, SOC 2 Type II and SSOSingle Sign-On. One company login (usually via SAML or OIDC) instead of a separate password per tool./SCIMSystem for Cross-domain Identity Management. A standard for automatically creating and removing user accounts when people join or leave./MDM are the secure foundation you already sold. Agent governance is the layer on top. As an agent gets more agency - running terminal commands, editing files, calling tools - the security surface grows with it. Three controls put deterministic boundaries around that agency, and each is enforceable org-wide so an individual cannot quietly disable it.

Three layers on the secure foundation

Egress control: default-deny by design

Sandbox mode turns the network off by default. When an agent does need to reach out, egress is governed the same way model and tool access is - explicit allow, explicit block, deny everything else.

Why the controls have to scale with the code

More agency means more security surface, and that math does not stay small. At NVIDIA-scale - on the order of 40,000 engineers using agents daily - the governance question stops being "is this safe for one developer" and becomes "how do we govern responsibly at scale."

There is a second-order effect to name. If a team ships roughly 40% more code with agents, the controls that gate code - review capacity, policy, access controls - have to scale with that volume. Governance that was sized for human throughput becomes the bottleneck, or worse, the gap. The three layers exist so the boundaries scale as deterministic policy rather than as more manual review.