Code Custody on Cursor Origin: Security and Governance

Custody means who holds the canonical copy of your code and the history around it. For a team on GitHub, that is GitHub. The question comes up with Origin because moving your hosting to an AI vendor is a bigger decision than swapping one tool for another. The repo is the source of truth for everything you ship.

The direction is public. Graphite's post on joining Cursor describes its vision as "one integrated platform where humans and agents create, review, and merge code changes collaboratively," and promises integrations that connect local development, background agents and pull requests. The post doesn't mention Origin, which brings hosting under the same roof. That integration is the selling point. It is also the thing to think hard about, because it concentrates so much with one vendor.

The repository holds the only ordered record of how your software came to be the way it is. You reach for it during an incident, and an auditor asks for it afterward. Whoever holds the branch everyone pushes to holds the source of truth. If your paperwork names a different repository, check which one your deploy pipeline reads from before you rely on the paperwork.

The word "move" hides how custody changes hands. It doesn't transfer in a single action. It accumulates, one repository and one review thread at a time, and what a mirror cannot carry back makes the trip toward Origin easier than the trip back. The decision to make deliberately is which repositories you let build up history on the new host.

A split setup has an editor from one vendor, hosting from another and CI from a third. If the agent goes wrong, your repo and history still sit somewhere else. Origin's pitch brings those layers together. That is useful, and it also removes the separation.

The table understates the outage row. A split setup gives you a bad day that still has a workaround in it. The editor is down and the repo still merges, or the host is down and you keep working against the clone on your laptop. Concentration narrows that, because the layer you would fall back to belongs to whoever is having the incident.

Correlated failure usually gets discussed as a data center problem. The account-level version deserves as much attention: a suspended account or a lapsed payment can take out every product behind it at the same moment. Add two questions to your custody list. Do the hosting and the editor sit behind one login? Does at least one person on the team hold repository access by a path that doesn't?

Treat this like any custody decision. Assume nothing, and get the answers in writing from the vendor's own terms rather than from coverage. For Cursor, start with cursor.com/security and the data terms it links to.

• Data use: is your code or its metadata used to train models, and can you turn that off across the whole platform?
• Residency: where is the repo stored, and can you pin a region if you're under data-residency rules?
• Export: if you leave, what comes with you? Git history is portable; pull requests, reviews and issues often are not.
• Access: who at the vendor can read your repo, and is that logged?
• Compliance: which certifications (SOC 2 and similar) cover the hosting specifically, not just the editor?
• Continuity: what's the uptime commitment, and what happens to your code if the product is discontinued?

Ask about export first, out of order, because it is the only answer on that list that still protects you when the others change. Data-use policies get revised and access lists turn over, which is normal for any company over a few years. An export path somebody has run once survives all of it.

The data-use question has a wording trap: ask about code, and a vendor will answer about code. Metadata covers the writing around the code, such as commit messages, review comments and the prompt that produced the change. Name metadata in the question, and ask separately what retention applies to it.

You don't have to choose between all-in and not-at-all. Because git is portable, there is a middle path that keeps your custody options open.

1. 1Keep a mirror of every repo on a second host, so Cursor is never the only copy of your source of truth.
2. 2Trial Origin on non-critical repositories first, and judge it on real review and merge work.
3. 3Read the Origin-specific data and security terms before any regulated or proprietary code goes near it.
4. 4Keep an export path you've tested, not one you assume works.

The order of those four steps is deliberate. The mirror comes first because it is the only step you can take without anyone's permission or budget, and it keeps every later decision reversible. In the early beta, the sync does it for you: GitHub stays the source of truth for a synced repo until you detach it. Reading the terms comes third for a practical reason. Origin-specific terms beyond 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. line don't exist yet, so a team that waits for them before setting up the sync could spend months doing nothing.

Small teams and large ones fail this differently, so one policy for both tends to be wrong. Two people with one repository are barely exposed to lock-in. Their exposure is having one copy, so the mirror is the whole program and the rest is overhead. A large organization's exposure runs the other way: the trial repo quietly becomes load-bearing, other teams notice it, and review history nobody arranged to export becomes the record of how a shipped product was built. In that case, name the boundary before the trial starts and write down what would end it.