Skip to content
Field Academy
DAY 3 22 min

Governance, compliance & Cursor's control plane

The day most candidates skip — and exactly where you differentiate.

0/6 sections

Why governance is the deal-closer, not the gate

This is the differentiator day. Anyone can demo Tab completion. The engineer who closes the enterprise deal is the one who can sit across from a VP of Engineering, a CISOChief Information Security Officer. The executive who owns security; usually the hardest and most important person to win over., and a Head of Internal Audit and speak their language without flinching. Governance isn't the obstacle to AI adoption — fluency in governance is the unlock.

The instinct most field people get wrong is treating compliance as bureaucracy to route around. The opposite is true. SOXSarbanes-Oxley Act. A US law that forces companies to keep auditable controls over any system that affects their financial reporting., ITGCIT General Controls. The baseline IT controls auditors check: who can change what, how changes get approved, and how systems are run., and change management exist because software changes production systems that move money, hold PIIPersonally Identifiable Information. Data that can identify a person (names, emails, SSNs); regulated and sensitive., and carry legal liability. The control framework is the company's risk management apparatus. When you show that Cursor strengthens that apparatus instead of weakening it, you stop being a productivity tool and become a risk-reducing platform.

The thesis

The block to enterprise AI adoption is never 'does it write good code.' It is 'can we prove who did what, who approved it, and that no single person can ship unreviewed change to production.'

Governance fluency converts you from a vendor explaining features into a peer solving the customer's actual problem: defensible, auditable velocity.

Reframe the whole conversation around one idea: AI raises the volume and velocity of change. Controls that were adequate when a senior engineer hand-wrote 200 lines a day are stress-tested when an agent proposes 2,000. The customer's real question is whether their existing control surface — separation of dutiesNo single person can author, approve, and deploy the same change. The core control AI autonomy has to respect., evidence, risk tiers — still holds. Your job is to show it holds, and that Cursor gives them better instrumentation than they had before.

Say it like this

"AI doesn't change what you need to prove. It changes how much you need to prove it about. We make the proof automatic."

Self-check

SOX, ITGC & change management as risk + evidence

You need to use these terms correctly, because the people you're selling to live in them. SOXSarbanes-Oxley Act. A US law that forces companies to keep auditable controls over any system that affects their financial reporting. (Sarbanes-Oxley) makes executives personally accountable for the accuracy of financial reporting. Because financial data lives in software, the controls over who can change that software fall under SOX scope. ITGCIT General Controls. The baseline IT controls auditors check: who can change what, how changes get approved, and how systems are run. — IT General Controls — is the bucket those controls live in: change management, access management, and operations.

The three ITGC families you'll hear aboutmemorize these

ITGC familyWhat it controlsWhere Cursor touches it
Change managementHow code moves from author to production; who approvesPR review, branch protection, risk-tiered CABChange Advisory Board. A group that reviews and signs off on higher-risk production changes before they ship. flow
Access managementWho can do what; provisioning/deprovisioningSSOSingle 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./RBACRole-Based Access Control. Granting permissions by role rather than configuring each person individually., model & repo allowlists
IT operationsBackups, jobs, incident handling, monitoringAudit logs, analytics, agent run records

Here's the mental model that wins the room: a control is a claim, and evidence is the proof of that claim. 'Every production change is reviewed by someone other than the author' is a control. The artifact that proves it — the PR showing author X, approver Y, timestamp, and the CI run that gated the merge — is the evidence. Auditors don't want your assurances; they want the artifacts.

The reframe that lands

PR approvals + pipeline logs ARE the audit trail. You are not adding a compliance burden — the developer's normal workflow already generates the evidence.

This is why 'shift-left' governance beats a quarterly screenshot scramble: the proof is continuous, immutable, and tied to the change itself.

Risk tiers: not every change needs a committee

Mature change management is risk-tiered. Treating a copy fix and a payments-schema migration identically is how you get either gridlock or recklessness. The standard three-tier model:

Standard / pre-approved

Low blast radiusHow much breaks if a change goes wrong; the scope of potential damage., well-understood pattern (docs, config flag, lint fix).

Pre-approved change class — merges on automated gates + peer review. No CABChange Advisory Board. A group that reviews and signs off on higher-risk production changes before they ship..

This is where AI velocity pays off most.

Normal / CAB

Material change to a system in scope (schema, auth, money paths).

Goes through a Change Advisory Board: reviewed, scheduled, documented.

AI accelerates the work; the gate is unchanged.

Emergency

Break-glass for production incidents.

Expedited approval, but retroactive documentation is mandatory.

Most-abused tier — auditors scrutinize it hardest.

Watch out

Never imply Cursor lets teams skip CABChange Advisory Board. A group that reviews and signs off on higher-risk production changes before they ship. or approval for high-risk change. The pitch is 'AI does more work inside each tier,' not 'AI removes the tiers.' Conflating those two is how you lose a security buyer's trust in one sentence.

Self-check

QA platform team wants AI agents to merge their own changes to a payments service with no human review, citing speed. Which change tier governs payments, and what do you tell them?

Separation of duties: THE governance concept for AI

If you remember one thing for the governance conversation, remember this: separation of dutiesNo single person can author, approve, and deploy the same change. The core control AI autonomy has to respect. (SoDSeparation of Duties. No single person can author, approve, and deploy the same change. The core control AI autonomy has to respect.) is the load-bearing wall of change management, and it is exactly the concept AI autonomy stress-tests. Author ≠ approver ≠ deployer. No single actor can move a change end-to-end alone.

SoDSeparation of Duties. No single person can author, approve, and deploy the same change. The core control AI autonomy has to respect. exists to defeat both malice and mistake. If the person who writes the change is also the only one who approves it and the only one who pushes it to production, you have a single point of failure for fraud and for error. Auditors treat a broken SoD boundary as a material weakness. This is non-negotiable in SOXSarbanes-Oxley Act. A US law that forces companies to keep auditable controls over any system that affects their financial reporting.-scoped systems.

Author ≠ approver ≠ deployer, with an agent in the loop
Authorwrites the changeApproverreviews & approvesDeployerpromotes to prodEvidence the auditor reconstructs:ticket → PR → named approvals → CAB record → signed artifact → deploy log
Author: If an agent both writes AND auto-commits, it collapses author ≠ approver. Guardrail: agents propose, humans approve.

The agent is a powerful author. It is never the approver. The human reviewing the scoped diff holds the approval gate; CI/CD holds the deploy gate. AI doesn't remove a role — it supercharges exactly one of them.

Where the agent fits

The clean way to explain AI autonomy to a governance audience: the agent is an author — possibly a prolific one — and authorship is the one role it can occupy. The approval gate stays human (or human-defined policy), and the deploy gate stays in the pipeline. An autonomous agent that opens a PR has not violated SoDSeparation of Duties. No single person can author, approve, and deploy the same change. The core control AI autonomy has to respect.; an agent with write access that merges its own PR to production has obliterated it.

The SoD test for any AI workflow
Who authored?
Human, or agent under a human's direction — fine either way
Who approved?
Must be a different identity than the author; the reviewer owns the merge
Who deployed?
Pipeline with its own controls — never the author bypassing CI
Red flag
Same identity (or unsupervised agent) spans author + approver + deploy
Say it like this

"The agent gets to be the author. It does not get to be the approver, and it does not get to be the deployer. We make it a faster author, not an unaccountable one."

Interview move

When asked 'how do you govern autonomous agents?', don't reach for a feature. Reach for SoDSeparation of Duties. No single person can author, approve, and deploy the same change. The core control AI autonomy has to respect.. Say: 'Autonomy is bounded by the same separation of dutiesNo single person can author, approve, and deploy the same change. The core control AI autonomy has to respect. as any engineer — author, not approver, not deployer.' Then layer the features (scoped diffs, allowlists, audit logs) as how you enforce it. Concept first, features second — that's what reads as senior.

Self-check

Security's seats in the SDLC + vetting Cursor itself

A CISOChief Information Security Officer. The executive who owns security; usually the hardest and most important person to win over. doesn't evaluate your tool in a vacuum. They have a security-in-the-SDLC program with specific gates, and they have a vendor risk process aimed at you. You need to speak to both: where Cursor fits among their existing security gates, and how Cursor itself survives a vendor security review.

The security gates already in the pipeline

Know this vocabulary cold — it signals you understand their world. These run in CI and are unchanged by who or what wrote the code:

GateWhat it checksWhy AI doesn't change the gate
SASTStatic Application Security Testing. Scanning source code for vulnerabilities without running it.Static analysis of source for vulns (injection, unsafe APIs)Runs on the diff regardless of author; AI code is scanned like any code
DASTDynamic Application Security Testing. Testing a running application for vulnerabilities from the outside.Dynamic testing of the running appBehavior-based; agnostic to authorship
SCASoftware Composition Analysis. Scanning third-party dependencies for known vulnerabilities and license problems.Software composition — known CVEs in dependenciesCatches risky deps an agent might pull in
Secrets scanningHardcoded keys/tokens in the diffCritical backstop; pairs with Cursor secret-redaction
SBOMSoftware Bill of Materials. A list of every component and dependency in a build, like an ingredients label for software.Software Bill of Materials — inventory of componentsSupply-chain transparency, required by many enterprises
SLSASupply-chain Levels for Software Artifacts. A framework for proving how a piece of software was built and that it wasn't tampered with. / provenanceTamper-evident proof of how the artifact was builtAttests the build pipeline, not the editor
The point to make

Every one of these gates operates on the change, not the author. AI-assisted code passes through the identical SASTStatic Application Security Testing. Scanning source code for vulnerabilities without running it./DASTDynamic Application Security Testing. Testing a running application for vulnerabilities from the outside./SCASoftware Composition Analysis. Scanning third-party dependencies for known vulnerabilities and license problems./secrets/SBOMSoftware Bill of Materials. A list of every component and dependency in a build, like an ingredients label for software./SLSASupply-chain Levels for Software Artifacts. A framework for proving how a piece of software was built and that it wasn't tampered with. gauntlet. You're reinforcing that adopting Cursor requires zero weakening of their security pipeline — it slots in upstream of all of it.

The vendor security review of Cursor itself

Separately, their TPRM (third-party risk management) team will run Cursor through a security questionnaire. Have the facts ready and accurate. The current control surface (verify perishable specifics before quoting in a deal):

SOC 2 Type IIAES-256 at restTLS 1.2+ in transitAnnual third-party pen testingPrivacy ModeCursor's setting that routes requests under zero-data-retention terms so providers don't store or train on your code.Zero-data-retention termsAWS PrivateLinkAn AWS feature that keeps traffic to a service on your private network instead of the public internet.Cloudflare TunnelSSOSingle Sign-On. One company login (usually via SAML or OIDC) instead of a separate password per tool. (SAMLAn enterprise standard that powers single sign-on./OIDCOpenID Connect. A modern standard that powers single sign-on, built on OAuth.)SCIMSystem for Cross-domain Identity Management. A standard for automatically creating and removing user accounts when people join or leave.RBACRole-Based Access Control. Granting permissions by role rather than configuring each person individually.Audit logs
Verified (June 2026)

SOC 2 Type II; AES-256 at rest; TLS 1.2+ in transit; annual third-party penetration testing; 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; private connectivity via AWS PrivateLinkAn AWS feature that keeps traffic to a service on your private network instead of the public internet. + Cloudflare Tunnel.

Proof point you can cite: the enterprise page states Cursor is trusted by 64% of the Fortune 500.

Perishable specifics (certs, dates, exact terms) change — confirm against current security docs before putting them in writing for a customer.

Self-check

Cursor's control surface: five families + Organizations

Enterprise asks cluster into five families. Memorize the families, then map each customer concern to the specific Cursor control that answers it. This is the core of a security-led deal.

1 · Identity

The ask: 'Who can use it, and how do we provision/deprovision at scale?'

Controls: SSOSingle Sign-On. One company login (usually via SAML or OIDC) instead of a separate password per tool. (SAMLAn enterprise standard that powers single sign-on./OIDCOpenID Connect. A modern standard that powers single sign-on, built on OAuth.), SCIMSystem for Cross-domain Identity Management. A standard for automatically creating and removing user accounts when people join or leave. for lifecycle, RBACRole-Based Access Control. Granting permissions by role rather than configuring each person individually. for least privilege.

2 · Data

The ask: 'Where does our code go, and is it used to train?'

Controls: Privacy ModeCursor's setting that routes requests under zero-data-retention terms so providers don't store or train on your code., zero-data-retention terms, AES-256 at rest, TLS 1.2+ in transit.

3 · Policy

The ask: 'How do we constrain what the tool and agents can do?'

Controls: model / MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. / repo allowlists, hooks, terminal sandboxing.

4 · Network

The ask: 'Can traffic stay off the public internet / inside our boundary?'

Controls: AWS PrivateLinkAn AWS feature that keeps traffic to a service on your private network instead of the public internet., Cloudflare Tunnel, IP allowlisting.

5 · Visibility

The ask: 'How do we see and prove what happened?'

Controls: audit logs, usage analytics, AI-code tracking.

Organizations — the admin plane over the familiesGA to Enterprise ~June 2026

All five families need to be governed at scale across a large company that isn't one monolithic team. That's what Organizations provides: one admin plane over many teams, where each team carries its own security posture, governance, and budget. Groups model cohorts for model access, spend, and agent permissions — so you can give the platform team broad agent autonomy while keeping a regulated finance team on a tighter allowlist, all under one roof.

Customer concernFamilyCursor control
'Offboarded engineer still had access'IdentitySCIMSystem for Cross-domain Identity Management. A standard for automatically creating and removing user accounts when people join or leave. auto-deprovision + SSOSingle Sign-On. One company login (usually via SAML or OIDC) instead of a separate password per tool.
'Our code can't train a model'DataPrivacy ModeCursor's setting that routes requests under zero-data-retention terms so providers don't store or train on your code. + zero-data-retention terms
'Agents must not call arbitrary tools'PolicyMCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. allowlist + hooks
'No traffic over the public internet'NetworkPrivateLinkAn AWS feature that keeps traffic to a service on your private network instead of the public internet. / Cloudflare Tunnel
'Prove what the AI changed'VisibilityAI-code tracking + audit logs
'Different rules per business unit'Org-wideOrganizations + Groups
Verified (June 2026)

Organizations is GA to Enterprise around June 2026: one admin plane over many teams, each with its own security/governance/budget; Groups handle cohort-level model access, spend, and agent permissions.

Note on ZDRZero Data Retention. A contractual guarantee that the model provider won't store your code or train on it. scope (load-bearing): zero-data-retention terms do NOT apply when a customer brings their own API keys — see the hard-questions section.

Self-check

QWhich Cursor control most directly answers 'prove to our auditor which production code was AI-assisted'?

The trust equation: blocker → ally

Every security objection to AI coding reduces to three fears. Name the fear, then show the control that converts the blocker into an ally. This is the single most reusable frame in the whole governance day.

The fear (blocker)The control (ally)What you say
Unreviewable — 'AI dumps huge opaque changes'Scoped, reviewable diffs through normal PR review'Every change is a scoped diff a human reviews — same gate as any engineer.'
Undisclosed — 'we won't know what's AI'Disclosure + AI-code tracking'AI involvement is tracked and attributable, not hidden.'
Unaccountable — 'no audit trail, agents run wild'Audit logs + early security involvement + SoDSeparation of Duties. No single person can author, approve, and deploy the same change. The core control AI autonomy has to respect.'Bring security in early; every action is logged, and the agent is never the approver.'
Why this works

Each fear is a specific, answerable claim — not a vibe. By converting 'unreviewable / undisclosed / unaccountable' into 'scoped / disclosed / audited,' you turn the security team from a gatekeeper into a co-designer of the rollout.

The deepest version: invite security in early. The blocker isn't the tool; it's being surprised by the tool. Early involvement is itself a control.

Hard security questions where honesty wins

The fastest way to lose a CISOChief Information Security Officer. The executive who owns security; usually the hardest and most important person to win over. is to improvise a compliance answer. The fastest way to win one is to answer a hard question with precise honesty, including the limits. The canonical example you must get right:

The ZDR / own-keys trap

Zero-data-retention terms do NOT apply when the customer uses their own API keys. With BYO keys, data handling is governed by the upstream model provider's terms, not Cursor's ZDRZero Data Retention. A contractual guarantee that the model provider won't store your code or train on it..

If you imply ZDRZero Data Retention. A contractual guarantee that the model provider won't store your code or train on it. still covers them in that configuration, you've made a false compliance claim. State the boundary plainly: 'ZDR applies under our managed inference; with your own keys, your provider's retention terms govern that traffic.'

Say it like this

"I'd rather tell you exactly where the boundary is than discover it together in your audit. With your own API keys, our zero-data-retention terms don't apply — your model provider's terms do."

The general rule: never invent a compliance or roadmap specific. If you don't know whether Cursor holds a given certification or supports a given control today, say you'll confirm and follow up with the security docs — and then do it. A 'let me verify that' costs you nothing; a fabricated 'yes' costs you the deal and your credibility the moment their auditor checks.

Interview move

If an interviewer asks a question designed to bait you into overclaiming ('So Cursor guarantees our code is never retained, right?'), the senior answer states the caveat unprompted. Volunteering the BYO-keys ZDRZero Data Retention. A contractual guarantee that the model provider won't store your code or train on it. exception is a signal that you sell on trust, not on hope. That self-correction reads as more credible than a clean 'yes.'

Self-check