Switching from Cursor to GitHub Copilot: Indemnity Coverage and Code Provenance

What indemnity is attached to

AI coding assistant indemnification is a contractual commitment made by a vendor about its own product. It is usually conditioned on things such as the plan a customer is on, the contract terms in force, and safeguards the customer must keep enabled. Copilot copyright commitment conditions, and any equivalent terms Cursor publishes, should be read directly from each vendor's current documents and agreements, because they change and because the wording of each condition matters.

The practical consequence is that the repository itself carries no coverage status. A file in a Git history does not record which vendor's terms it was produced under. Coverage, if it exists, is a property of the generation event: the tool, the plan, the configuration and the account. Whether a vendor measures that at generation time, or looks at code while it remains in a customer's repository, is a specific question to put to the vendor and to counsel. It should not be assumed in either direction.

Why a mid-project switch creates uneven coverage

A repository that moves from Cursor to Copilot has, in effect, two or more regimes of terms layered into one history. Early commits were produced under one vendor's contract and settings. Later commits are produced under another's. Within each period there may also be variation: a developer on a different plan, a safeguard setting changed or overridden, or a team that adopted the new tool gradually rather than on a single day.

The risk is not only that coverage differs. It is that nobody can show which regime applies to which code. During due diligence, an audit or a dispute, legal, procurement and security reviewers will ask the same question: for this file, which tool generated it, under what configuration, and what policy applied? If the answer depends on memory or on logs that expired when the old subscription ended, the team cannot answer, whatever the underlying contract says.

This is why the topic is best treated as a provenance problem. NIST defines provenance as the chronology of the origin, development, ownership, location and changes to a system or system component and associated data. Applying that definition to AI-assisted commits is an interpretation, but a useful one: tool, period and policy state are the origin facts a coverage review needs.

Building a commit-level attribution record

Attribution works best when it is captured at the time of generation or commit. Reconstructing it later depends on records that may no longer exist. For each AI-assisted change, the useful fields are the originating tool and version, the account and plan, the assistant configuration in force, the applied policy version, and the origin and licence context of the code where it is known.

Several existing methods can contribute, with limits. Commit trailers are easy to add, but they depend on developer or tooling behaviour and can be lost when history is squashed or rebased. Editor telemetry records activity, but it does not by itself bind a generation event to a specific commit, especially after code is edited or pasted. Digital signing gives integrity and source authentication of who controlled the code when it was signed, but it does not identify which AI tool generated it. Treat each method as one input, and corroborate where you can.

Two design choices make the record durable. First, store assistant settings and policy files as configuration-as-code, versioned and access-controlled, so the configuration in force at any commit can be recovered from history. This follows the SSDF principle of storing all forms of code, including configuration-as-code, under least privilege. Second, keep attribution records separate from, but linked to, the repository history, in a machine-readable form, so they survive a tool change and can be ingested by reviewers. NIST advises structured, standard formats for SBOMs for the same reason, and the principle extends naturally to provenance records.

Where the origin of earlier code cannot be confirmed, label that segment unverified and subject it to additional review, rather than assuming it falls under any particular terms.

Where runtime policy enforcement fits

Records written after the fact depend on people remembering to write them. A stronger pattern is to have the record produced by the same mechanism that applies policy. Trussed enforces policy in the execution path of coding assistants, with actions such as allow, redact and block applied at runtime, not reviewed after the fact. It also provides code provenance covering the origin, licence and security context of code, and the enforcement itself generates audit-ready evidence of what policy applied.

That evidence can help a regulated enterprise answer which policy state governed a given interaction across a tool transition. Trussed does not provide, guarantee or substitute for vendor indemnity. Coverage remains a matter of each vendor's contract and counsel's reading of it.