GitHub Copilot Indemnity and Cursor-Generated Code: What Is and Is Not Covered

An indemnity is a conditional contract term

An IP indemnity is a promise by a vendor to defend or compensate a customer for certain claims, subject to conditions. It lives in an agreement between two parties. It is not metadata on a file, and it does not travel with code once that code is committed.

Conditional drafting is normal for indemnities. Federal procurement offers a familiar example: a contractor indemnifies the Government against liability for actual or alleged patent, trademark or copyright infringement arising from contract performance, but only where stated conditions are met. AI coding vendors follow the same pattern. Coverage is typically defined by which product is used, under which plan, with which settings enabled, and what the customer must do when a claim arises.

For a CISO, the practical reading is that the question is never simply whether the organisation has indemnity. The question is which indemnity applies to a given change, and whether the conditions were met when that change was generated.

Why Copilot coverage does not reach Cursor output

Microsoft's Copilot terms bind Microsoft and the customer in respect of Microsoft's product. Cursor is a different product from a different vendor. When a developer accepts a Cursor suggestion and commits it, the code was generated under Cursor's terms, and possibly under the terms of the model provider behind the feature in use.

Committing that code to a repository that Copilot users also contribute to does not change which agreement governed its generation. Repository ownership, organisation-level licences and shared pull request workflows are not contractual links between Microsoft and a different vendor's output. Treating them as such is the assumption that leaves exposure unexamined.

The outcome for Cursor-generated code depends on Cursor's published terms and any enterprise agreement in place. Those terms may allocate ownership, liability and indemnification differently, with different exclusions and customer obligations, or may offer limited protection. The same reasoning applies to every other assistant in the estate. Each needs to be read on its own terms.

Mixed repositories and the evidence gap

Most enterprises do not run a single assistant. Different teams adopt different tools, and individual developers may use more than one. The result is repositories in which human-written code, Copilot output, Cursor output and other generated code sit side by side with no visible distinction in the commit history.

That creates two problems. First, even if one vendor's indemnity is valid, the organisation may be unable to show which lines fall under it. Second, code from tools without comparable terms is indistinguishable from covered code, so residual licence and IP exposure cannot be estimated.

The risk itself is recognised. NIST's generative AI profile notes that intellectual property risks may arise where the use of copyrighted works is not a fair use. The FTC has likewise identified potential plagiarism in AI output as a concern in its own AI use policy. Neither source creates an indemnity or says how one applies to coding assistants. They show why the exposure belongs in a risk register, and why contract terms must be matched to actual code origin.

Provenance and review: capture origin alongside normal controls

NIST's secure software development profile for generative AI makes no distinction between human-written and AI-generated source code, because all source code is assumed to need evaluation for vulnerabilities and other issues before use. Security review therefore does not depend on which assistant produced a change, and an indemnity is no substitute for it.

Origin data is a separate need. Code provenance covers three things: where the code came from (which assistant, plan and settings), what licence considerations attach to it, and what security context surrounds it. Captured at the time of generation, this data lets legal and procurement map each change to the terms that applied. Reconstructing it later from developer recollection or commit messages is unreliable.

A workable approach is to inventory every assistant with its plan and configuration, record origin per change, and keep the record alongside the standard review evidence. Where vendors make commitments about customer data and model training, document those too. The FTC has said that AI companies failing to honour such commitments may face liability under laws it enforces, so they are relevant to vendor assessment.

Enforcing policy on coding assistants and producing evidence with Trussed

Trussed does not provide, replace or interpret any vendor's indemnity, and it does not give legal advice. Its role is on the organisational side of the question: showing what coding assistants were allowed to do and what code they produced.

Trussed enforces policy in the execution path across coding assistants, as well as models, agents, tools and MCP servers. Policy is enforced at runtime, not reviewed after the fact, and each interaction or tool call can be allowed, redacted, blocked, rate limited or escalated for human approval. Code provenance records the origin, licence and security context of code.

The enforcement itself generates continuous, audit-ready evidence, mapped to frameworks including NIST and others relevant to a regulated enterprise. Security, legal and procurement teams can use that evidence to show auditors and counsel which assistant produced which code, and to match it against the vendor terms they have reviewed. Deployment is self-managed in the customer cloud, with configurable retention and data residency.