Governance, compliance & Cursor's control plane
The day most candidates skip - and exactly where you differentiate.
Why governance is the deal-closer, not the gate
After this you can reframe an auditor's 'AI is a compliance risk' into 'AI under our control framework is better-instrumented than what you trust today.'
This is the differentiator day.
Anyone can demo Tab completion. The engineer who closes the enterprise deal sits 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 speaks their language without flinching. Governance isn't the obstacle to AI adoption. Fluency in governance is the key.
Most field people treat compliance as bureaucracy to route around. That instinct loses the room. 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. Show that Cursor strengthens that apparatus instead of weakening it and you stop being a productivity tool. You become a risk-reducing platform.
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 moves you from a vendor explaining features to a peer solving the customer's actual problem: defensible, auditable velocity.
One idea reframes the whole conversation: AI raises the volume and velocity of change. Controls that were adequate when a senior engineer hand-wrote 200 lines a day get stress-tested when an agent proposes 2,000.
The customer's real question is whether their existing control surface still holds:
- separation of dutiesNo single person can author, approve and deploy the same change. The core control AI autonomy has to respect.
- evidence
- risk tiers
Your job is to show it holds and that Cursor gives them better instrumentation than they had before.
"AI doesn't change what you need to prove. It changes how much you need to prove it about. We make the proof automatic."
Takeaway. Governance fluency is the key: show that Cursor strengthens the control framework and you stop being a productivity tool and become a risk-reducing platform.
Self-check
SOX, ITGC & change management as risk + evidence
After this you can explain the control-vs-evidence model and place any change into the right risk tier.
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. Financial data lives in software, so 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, operations.
The three ITGC families you'll hear aboutmemorize these
- ITGC family
- Change management
- What it controls
- How code moves from author to production; who approves
- Where Cursor touches it
- PR review, branch protection, risk-tiered CABChange Advisory Board. A group that reviews and signs off on higher-risk production changes before they ship. flow
- ITGC family
- Access management
- What it controls
- Who can do what; provisioning/deprovisioning
- Where Cursor touches it
- 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./RBACRole-Based Access Control. Granting permissions by role rather than configuring each person individually., model & repo allowlists
- ITGC family
- IT operations
- What it controls
- Backups, jobs, incident handling, monitoring
- Where Cursor touches it
- Audit logs, analytics, agent run records
| ITGC family | What it controls | Where Cursor touches it |
|---|---|---|
| Change management | How code moves from author to production; who approves | PR 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 management | Who can do what; provisioning/deprovisioning | 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./RBACRole-Based Access Control. Granting permissions by role rather than configuring each person individually., model & repo allowlists |
| IT operations | Backups, jobs, incident handling, monitoring | Audit logs, analytics, agent run records |
One mental model 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 is the evidence: the PR showing author X, approver Y, timestamp and the CI run that gated the merge. Auditors don't want your assurances. They want the artifacts.
PR approvals + pipeline logs ARE the audit trail. You're 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. Treat a copy fix and a payments-schema migration identically and you get gridlock, recklessness or both. The standard three-tier model:
Interactive diagram. Tab through its regions; each focused region shows its detail in the panel below.
Standard/pre-approved is a light gate where AI velocity pays off; Normal/CAB keeps the full Change Advisory Board gate unchanged; Emergency/break-glass is post-hoc review auditors scrutinize hardest. AI does more work inside each tier - it never removes the tiers.
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.
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.
Break-glass for production incidents.
Expedited approval, but retroactive documentation is mandatory.
Most-abused tier: auditors scrutinize it hardest.
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.
Quality gates move left, not awaythe layered pre-PR pipeline
The auditor's unspoken worry is volume: if an agent proposes 10x-100x more code, do your quality controls still hold? The answer Cursor's own engineering uses is to stack quality earlier in the pipeline, not to lean on the single PR gate. The order matters:
- 1At generation time, run a
de-slopcommand (published on Cursor's public marketplace) that scans the model's output and strips the AI-slop patterns: generic names, verbose comments, over-engineering, unnecessary abstraction, off-house-style boilerplate. - 2Before a PR exists, layer BugBot plus automations and cloud-agent reviews to verify quality before the code even reaches Git. Add scoped self-review prompts run with a strong model (e.g. 'Is this regressing anything outside the feature flag?').
- 3At the PR, the human review + CI gauntlet runs as always. Nothing here removes that gate; the earlier layers just mean less slop arrives at it.
BugBot is Cursor's AI code reviewer, integrated into GitHub PRs at the org/repo level. It is high signal-to-noise: Cursor reports consistently resolving north of 70-80% of issues flagged.
Config knobs (admin dashboard): which repos it runs on, scrutiny level, per-PR vs manual trigger, and surface-only vs auto-fix. Trust progression: start by approving each fix, then graduate to auto-fix once comfortable.
Frame it as evidence, not magic: BugBot's findings support human review, they do not replace it. Resolution percentages are perishable - confirm before quoting in a deal.
Takeaway. A control is a claim; evidence is the proof of that claim and the developer's normal PR workflow already generates it. Stack quality left (de-slop → BugBot → CI) so the PR gate sees less slop, never fewer gates.
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
After this you can run any AI workflow through the SoD test and locate the exact role an agent may occupy.
Remember one thing for the governance conversation: 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 malice and mistake at once. 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. In SOXSarbanes-Oxley Act. A US law that forces companies to keep auditable controls over any system that affects their financial reporting.-scoped systems it is non-negotiable.
Interactive diagram. Tab through its regions; each focused region shows its detail in the panel below.
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 amplifies exactly one of them.
Where the agent fits
Explain AI autonomy to a governance audience this way: 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). 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.
- 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
"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."
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 sequencing is what reads as senior.
Takeaway. The agent gets to be the author and only the author: not the approver, not the deployer. AI amplifies one role, it never removes one.
Self-check
Security's seats in the SDLC + vetting Cursor itself
After this you can name the CI security gates AI code still passes and answer a vendor security review of Cursor with accurate facts.
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 run a security-in-the-SDLC program with specific gates and a vendor risk process aimed at you. Speak to both:
- Where Cursor fits among their existing security gates.
- 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 gates run in CI, unchanged by who or what wrote the code:
- Gate
- SASTStatic Application Security Testing. Scanning source code for vulnerabilities without running it.
- What it checks
- Static analysis of source for vulns (injection, unsafe APIs)
- Why AI doesn't change the gate
- Runs on the diff regardless of author; AI code is scanned like any code
- Gate
- DASTDynamic Application Security Testing. Testing a running application for vulnerabilities from the outside.
- What it checks
- Dynamic testing of the running app
- Why AI doesn't change the gate
- Behavior-based; agnostic to authorship
- Gate
- SCASoftware Composition Analysis. Scanning third-party dependencies for known vulnerabilities and license problems.
- What it checks
- Software composition - known CVEs in dependencies
- Why AI doesn't change the gate
- Catches risky deps an agent might pull in
- Gate
- Secrets scanning
- What it checks
- Hardcoded keys/tokens in the diff
- Why AI doesn't change the gate
- Critical backstop; pairs with Cursor secret-redaction
- Gate
- SBOMSoftware Bill of Materials. A list of every component and dependency in a build, like an ingredients label for software.
- What it checks
- Software Bill of Materials - inventory of components
- Why AI doesn't change the gate
- Supply-chain transparency, required by many enterprises
- Gate
- SLSASupply-chain Levels for Software Artifacts. A framework for proving how a piece of software was built and that it wasn't tampered with. / provenance
- What it checks
- Tamper-evident proof of how the artifact was built
- Why AI doesn't change the gate
- Attests the build pipeline, not the editor
| Gate | What it checks | Why 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 app | Behavior-based; agnostic to authorship |
| SCASoftware Composition Analysis. Scanning third-party dependencies for known vulnerabilities and license problems. | Software composition - known CVEs in dependencies | Catches risky deps an agent might pull in |
| Secrets scanning | Hardcoded keys/tokens in the diff | Critical 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 components | Supply-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. / provenance | Tamper-evident proof of how the artifact was built | Attests the build pipeline, not the editor |
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. 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, with perishable specifics verified before you quote them in a deal:
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 them against current security docs before putting them in writing for a customer.
Takeaway. Every CI gate operates on the change, not the author, so AI-assisted code runs 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, with zero weakening of the pipeline.
Self-check
Cursor's control surface: five families + Organizations
After this you can map any enterprise security concern to one of the five control families and the specific Cursor control that answers it.
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.
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.
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. (on by default, can't be disabled), zero-data-retention terms with all major model providers, AES-256 at rest, TLS 1.2+ in transit.
The precise storage answer: on first open Cursor chunks the codebase and stores hashed vector embeddings; the raw code is held ephemerally and then deleted, so the only long-term store is the vector DB. 'We don't want your codebase any more than you want us to have it.'
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, plus .cursorignore - a file that lists paths Cursor must never index or view (distinct from .gitignore), keeping secrets and PIIPersonally Identifiable Information. Data that can identify a person (names, emails, SSNs); regulated and sensitive.-laden trees out of the index and out of agent reach.
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.
For the strictest cases: self-hosted / private workersCloud-agent machines that run inside your own network so they can reach internal systems; the model inference still calls external providers. (beta) run the cloud-agent container in your network so it can reach on-prem source control, internal registries and internal MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. servers. Per-run cloud-agent governance: domain allowlists, run-time caps, env-var isolation, branch/model/MCP selection - and an environment you save and share rather than rebuild.
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
A large company is never one monolithic team, so all five families need governing at scale. That's what Organizations provides: the top-level admin plane for identity, membership, spend and usage across teams. Teams keep department-level security, governance, budget and feature settings. Groups cut across or within teams for model access, spend limits and agent permissions, with the most permissive setting winning when memberships overlap.
What the admin plane actually exposesconcrete console levers
Don't leave 'admin plane' abstract in front of an auditor. Name the levers. The admin console gives you the cost, access and data-exposure controls plus the measurement surface that turns AI adoption into a number leadership can read:
- Audit logs
- Track authentication, user changes and settings changes - the immutable who/what/when record
- Spend controls
- Spend alerts + group limits at individual / group / team level, so no runaway spend surprises you
- Restrict-analytics toggle
- On = analytics for admins only; off = democratized to all users
- `.cursorignore`
- Files Cursor must never index or view - the data-exposure lever
- Central push + invocation analytics
- Push skills, hooks and MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. integrations to the whole team from one place, then see how many of each are being invoked across the org
The analytics suite goes deeper than 'how much is it used.' It breaks down usage by surface (IDE / cloud agents / CLI) and by model (relating spend to token efficiency), classifies work (new feature vs bug fix vs maintenance), shows the agent-mode split (plan vs ask vs writing code), plan-mode adoption and even a prompt-specificity score. Lots of low-specificity prompts or expensive models on trivial tasks tells you exactly where to invest in training. (No analytics MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. server yet; this is reached via the analytics/admin APIs.)
- Customer concern
- 'Offboarded engineer still had access'
- Family
- Identity
- Cursor control
- SCIMSystem 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.
- Customer concern
- 'Our code can't train a model'
- Family
- Data
- Cursor control
- 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
- Customer concern
- 'Agents must not call arbitrary tools'
- Family
- Policy
- Cursor control
- MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. allowlist + hooks
- Customer concern
- 'No traffic over the public internet'
- Family
- Network
- Cursor control
- PrivateLinkAn AWS feature that keeps traffic to a service on your private network instead of the public internet. / Cloudflare Tunnel
- Customer concern
- 'Prove what the AI changed'
- Family
- Visibility
- Cursor control
- AI-code tracking + audit logs
- Customer concern
- 'Different rules per business unit'
- Family
- Org-wide
- Cursor control
- Organizations + Groups
| Customer concern | Family | Cursor control |
|---|---|---|
| 'Offboarded engineer still had access' | Identity | SCIMSystem 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' | Data | 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 |
| 'Agents must not call arbitrary tools' | Policy | MCPModel 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' | Network | PrivateLinkAn AWS feature that keeps traffic to a service on your private network instead of the public internet. / Cloudflare Tunnel |
| 'Prove what the AI changed' | Visibility | AI-code tracking + audit logs |
| 'Different rules per business unit' | Org-wide | Organizations + Groups |
Organizations became generally available to Enterprise on June 3, 2026: one org-level plane over teams, with Groups for cohort-level model access, spend limits and agent permissions. When memberships overlap, the most permissive setting wins.
The security one-pager to memorize: Privacy ModeCursor's setting that routes requests under zero-data-retention terms so providers don't store or train on your code. is on by default and cannot be turned off; zero-data-retention agreements with all major model providers; SOC 2 Type II attestations; SSOSingle Sign-On. One company login (usually via SAML or OIDC) instead of a separate password per tool. + MDM enforcement; code never leaves the US. Point customers to trust.cursor.com and the dedicated cloud-agent security page (covers repo cloning, snapshots, secrets/env-var handling).
Self-hosted clarification (top misconception): 'self-hosted' / private workersCloud-agent machines that run inside your own network so they can reach internal systems; the model inference still calls external providers. run the agent container in your network - the model inference is still external (e.g. Opus still calls Anthropic's API). It is for assets that can't touch the internet, not on-prem AI.
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.
Takeaway. Five families (identity, data, policy, network, visibility) answer the asks; Organizations + Groups scope them per business unit under one admin plane.
Self-check
QWhich Cursor control most directly answers 'prove to our auditor which production code was AI-assisted'?
The trust equation: blocker → ally
After this you can name the fear behind any AI-security objection and hand back the control that converts the blocker into an 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)
- Unreviewable - 'AI dumps huge opaque changes'
- The control (ally)
- Scoped, reviewable diffs through normal PR review
- What you say
- 'Every change is a scoped diff a human reviews - same gate as any engineer.'
- The fear (blocker)
- Undisclosed - 'we won't know what's AI'
- The control (ally)
- Disclosure + AI-code tracking
- What you say
- 'AI involvement is tracked and attributable, not hidden.'
- The fear (blocker)
- Unaccountable - 'no audit trail, agents run wild'
- The control (ally)
- 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.
- What you say
- 'Bring security in early; every action is logged and the agent is never the approver.'
| 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.' |
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.
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
Improvise a compliance answer and you lose the CISOChief Information Security Officer. The executive who owns security; usually the hardest and most important person to win over.. Answer a hard question with precise honesty, limits included and you win one. The canonical example you must get right:
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.'
Two related corrections you should volunteer. (1) *BYOK is supported (incl. AWS Bedrock) but it's a worse experience - Cursor-direct is faster and better because of the harness, so don't sell own-keys as the premium path. (2) 'Self-hosted' is not self-hosted inference*: private workersCloud-agent machines that run inside your own network so they can reach internal systems; the model inference still calls external providers. run the agent container in the customer's network, but the model call still goes out to the provider (Opus still hits Anthropic's API). It's for assets that can't touch the internet, not on-prem AI.
"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, 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.
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.'
Takeaway. Convert unreviewable / undisclosed / unaccountable into scoped / disclosed / audited and state the ZDRZero Data Retention. A contractual guarantee that the model provider won't store your code or train on it. own-keys boundary unprompted; honesty about the limit is what wins the CISOChief Information Security Officer. The executive who owns security; usually the hardest and most important person to win over..