Cursor Origin for Enterprises: 10 Questions to Ask First

Origin is Cursor's git hosting platform, announced at Compile on June 16, 2026 and in early beta on paid plans since August 17. The docs cover repos, GitHub sync, pull requests, apps and a CLI, and they say two things an enterprise reader should notice first: admins can disable Origin for the team from the dashboard, and the Permissions and Rules and Protections controls are being redesigned during the beta. For a platform team that is not a problem to complain about, it is a due-diligence gap to plan around: most enterprise controls you rely on from GitHub or GitLab today are, for Origin, still an open question.

The table below is the checklist. Each question gets its own treatment further down, with why it matters and what, if anything, is published today. Spoiler on the third column: it is still mostly "nothing Origin-specific," with the beta docs filling in CI, pricing and the exit path, and knowing that precisely is the point.

Identity and evidence are the first two questions because they gate everything else. A code host your identity provider can't manage is shadow IT on day one, and a host that can't show you who did what is unusable for change-management evidence.

1. Does Origin support SAML SSO and SCIM provisioning?

Why it matters: offboarding. When someone leaves, SCIMSystem for Cross-domain Identity Management. A standard for automatically creating and removing user accounts when people join or leave. Press Enter for the full definition. is what revokes their access to the repo the same hour their account is disabled, without a manual sweep. What's known: the docs say Origin access follows your Cursor team and codebase permissions, so whatever provisions the Cursor team provisions Origin, but nothing names SAMLSecurity Assertion Markup Language. The XML-era enterprise standard that powers single sign-on: your identity provider vouches for you to each app. Older than OIDC but still what many enterprise tools speak. Press Enter for the full definition. or SCIM for Origin itself. Cursor does publish both for the editor product, which is the closest precedent you have.

2. What lands in the audit log, and can we export it?

Why it matters: a hosting audit log is a different animal from an editor audit log. You need pushes, force-pushes, permission changes, protection-rule edits and merges, exportable to your SIEM, because that trail is what an auditor accepts as evidence that your change process is real. What's known: nothing for Origin. One wrinkle worth raising with the vendor: when an agent opens and merges a change, the log should record which human directed it, or the trail stops meaning anything.

The editor's published plans are your baseline for what Cursor considers enterprise-grade. Treat them as precedent, not as a promise about Origin.

These two questions are about parity: controls your compliance story already leans on, which a new host either matches or breaks.

3. Is there branch-protection parity with GitHub rulesets?

Why it matters: required reviews, status checks and force-push blocks on protected branches are often written into your change-management policy by name. What's known: every Origin repo has a Rules and Protections tab for branch rules and merge protections, and the docs say available controls may expand and the UI may change during early beta, which is not yet a list you can map a policy onto. The stacked-diff model Origin's team built makes this more than a checkbox. Graphite's own docs tell teams to turn off GitHub's "dismiss stale approvals" setting because it fights stacks. If Origin's review flow relaxes a control you currently enforce, you need to know what compensates for it.

4. Where does the repo live, and can we pin a region?

Why it matters: if you operate under GDPR-driven or sector residency rules, the physical location of your source and its metadata is a contract term, not a preference. The bar is set by incumbents: GitHub Enterprise Cloud now offers data residency on ghe.com in the EU, US, Australia and Japan. What's known for Origin: nothing. Cursor's security page states it runs no infrastructure in China and uses no China-headquartered subprocessors, but publishes no region-pinning option for any product.

This is the custody core, and the pair of questions where a wrong assumption costs most. The mistake to avoid: reading cursor.com/security, which is about the editor and its AI features, and assuming it covers a hosting product that did not exist when those terms were written.

5. Which security terms cover the hosting, specifically?

Why it matters: SOC 2 attestations have a scope, and scope is exactly what changes when a vendor adds a product that holds your canonical source. Cursor holds a SOC 2 Type II attestation and commits to at-least-annual penetration testing, both verifiable at trust.cursor.com. Cursor's AIUC-1 certification, announced August 13, 2026, is the same shape of question in a newer document: its stated scope is the IDE and cloud agents under a representative enterprise configuration, and Origin is not named in it. The Origin docs add one line: Origin follows the 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. of the namespace owner, and teams on legacy privacy mode cannot enable it. Whether Origin is inside either attestation's scope is a question to ask in writing. The custody deep-dive walks the full framework: data use, training opt-outs, vendor access, continuity.

6. What egress and network controls exist?

Why it matters: a forge built for agents is, by design, a system other software talks to constantly. You will want IP allowlisting, some story for private connectivity, and clarity on what the platform itself reaches out to, because agents and automated review imply model calls somewhere. What's known: nothing for Origin. The editor's Enterprise plan lists auto-run, browser and network controls, which at least shows Cursor builds this class of control when the product calls for it.

Day-two operations decide whether a migration was a project or a mistake. Two questions cover it.

7. What runs CI, and what happens to our pipelines?

Why it matters: CI pipelines are host-specific and do not move with the repo, and that re-wiring is usually the largest line item in a host migration. What's known, from the beta docs: Origin has no CI of its own. Origin-hosted repos connect Depot or Buildkite from the repo's Apps tab, and both run your existing GitHub Actions workflows (Buildkite also runs its native pipelines); repos synced from GitHub keep CI on GitHub, and Depot and Buildkite do not work on them. Actions secrets do not sync. Coverage of the Compile demo described Origin fixing failed CI runs on its own, but that is still reported, not documented.

8. What SLA and support tier come with it?

Why it matters: when the host holding your source of truth goes down, agents, review and merges stop together, a blast radiusHow much breaks if a change goes wrong; the scope of potential damage. Press Enter for the full definition. the split GitHub-plus-tools setup doesn't have. You want a written uptime commitment and a named escalation path. What's known: nothing. The docs route beta feedback to hi@cursor.com, and the editor's Enterprise plan lists priority support and account management, so the sales motion exists; the hosting SLA does not, yet.

The last two questions are the ones procurement will ask you, so get ahead of them.

9. What is the pricing model?

Why it matters: the unit of pricing shapes behaviour. Per-seat pricing suits human teams; a forge whose whole pitch is agent throughput raises the question of whether you pay per human, per agent, or per unit of compute, and those produce very different bills for an agent-heavy org. What's known: during the early beta Origin is included with Pro, Teams and Enterprise at no separate price, and Cursor has published nothing about post-beta terms or a unit. The editor's Enterprise plan offers pooled usage and invoice/PO billing, which hints at how Cursor prices for large orgs without saying anything about Origin.

10. What is the exit path?

Why it matters: git history is portable and moves with a mirror push, but pull requests, review threads, permissions and CI live in host data and need an exporter or they are gone. Signing up without a tested export path is how lock-in actually happens. What's known: the beta's design is the exit path for synced repos, since GitHub stays the source of truth and pull requests sync back to it until you detach. For repos created on Origin, and for anything after a detach, no exporter is described. The migration guide covers what moves cleanly between hosts and what never does.

One more line for the file: ownership changed. A Form 8-K filed with the SEC on June 16, 2026 disclosed SpaceX's $60 billion all-stock agreement to acquire Anysphere, Cursor's parent, and on August 14, 2026 Cursor announced that the acquisition had completed, three days before the Origin beta opened. So the vendor holding your code on Origin was a SpaceX subsidiary from the beta's first day. Ask who your data-processing agreement is actually with at signing, and what change-of-control terms applied to existing contracts. The status tracker carries the dated record.