Code Custody on Cursor Origin: Security and Governance

Custody is just who physically holds the canonical copy of your code and the history around it. For most teams that is GitHub today. The phrase came up around 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.

Cursor is open about the strategy. Graphite's announcement describes the goal as "one integrated platform where humans and agents create, review, and merge code changes collaboratively," connecting local development, background agents and pull requests. That integration is the selling point. It is also the exact thing to think hard about, because it concentrates a lot under one roof.

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

Where I would push back on the framing is the word move. Custody does not transfer in a single action, it accumulates, one repository and one review thread at a time, and what a mirror cannot carry back is why that direction is easier to travel than the return trip. So the decision to make deliberately is not whether to migrate. It is which repositories you let build up history on the new host.

Today the parts are usually split: an editor from one vendor, hosting from another, CI from a third. If the agent goes wrong, your repo and history still sit somewhere else. Origin's pitch collapses those layers together, which is genuinely useful and also removes that separation.

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

Correlated failure gets discussed as a datacentre problem. The account-level version is probably the likelier one, and a suspended account or a lapsed payment can take out every product behind it at the same moment. So a question worth adding to any custody list is whether the hosting and the editor sit behind one login, and whether at least one person on the team holds repository access by a path that does not.

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, the place to start is 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?

Export is the one I would ask about 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, and none of that has to be sinister; it is what happens to a company across a few years. An export path somebody has actually run once survives all of it.

The data-use question has a wording trap in it. Ask about code and a vendor will answer you about code.

Metadata here covers the writing around the code: commit messages, review comments, the prompt that produced the change. Name metadata in the question explicitly, and ask what retention applies to it separately.

You don't have to choose between all-in and not-at-all. The portability of git gives you 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 actually tested, not one you assume works.

The order of those four steps is deliberate. The mirror comes first because it is the only one you can do without anyone's permission or budget, and it makes every later decision reversible. Reading the terms sits third for an unromantic reason. While Origin is pre-launch there are no Origin-specific terms to read, so a team that waits for them before setting up the mirror spends months doing nothing.

Small teams and large ones fail this differently, which is why a single 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 entire programme and the rest is overhead. A large organisation's exposure runs the other way. The trial repo quietly becomes load-bearing, other teams notice it, and the review history nobody arranged to export turns out to be the record of how a shipped product was built. In that case, put a name on the boundary before the trial starts and write down what would end it.