Evidence Needed to Make a GitHub Copilot Indemnity Claim

What the indemnity depends on

Vendor IP indemnification is a contractual commitment, not a general property of the product. It is usually conditional. Conditions can include required product settings and mitigations being enabled, and the customer being able to show that the code in question was generated by the product under those conditions.

That second element is where many organisations are exposed. A third-party allegation points at a file or a function in a repository. To rely on an indemnity, the customer has to connect that code to a generation event, and connect the event to the settings in force at that moment. Most organisations do not retain interaction-level records of prompts, suggestions, accepted code, active configuration, and code origin or licence context, so the connection has to be reconstructed from memory and commit history.

The practical starting point is the contract. Identify the version of the terms in force when the code was generated, keep a dated copy, and list each condition in it. Each condition then implies a record you either hold or do not.

The four categories of evidence

Configuration state. If your terms require a mitigation such as a duplicate detection filter, or a related setting such as content exclusion, a current screenshot is not enough. You need a dated record showing the setting was enabled when the code was produced. A setting that was on today and off last quarter is a different fact from one that was on throughout.

Generation records. These tie a code segment to an event: the user, the time, the assistant and its version, the prompt context, the suggestion returned, and whether it was accepted or edited. Without them, you cannot show that a segment came from the assistant rather than from a developer, a paste from another source, or a different tool.

Code origin and licence context. If an allegation concerns copied or licensed material, the team needs to know what the generated code resembled, where it likely came from, and under which licence. This is the context a reviewer would use to assess the allegation.

Retention. Each of the above has to exist when the claim is made, which may be long after generation. Retention periods should be set by legal and compliance teams against the limitation periods and contract notice terms that apply to you, not defaulted from a tool's settings.

Define what to capture at the point of generation

Records created after a dispute begins are weak evidence. Records created at generation are stronger, because they are produced without knowing a dispute will happen. Define the capture requirements before choosing tooling.

Start with a minimum record per interaction: identity, timestamp, assistant and version, active policy and configuration, the suggestion, the accepted output, and a reference that links the output to a repository, commit or file. Then add provenance fields for origin, licence and security context. Decide which of these your teams can capture from vendor-provided data, and which must be captured in your own environment so that you do not depend on another party's retention.

Two tradeoffs need an explicit decision. First, capturing prompts and suggestions creates a store that may itself contain sensitive source code and personal data, so access control and data residency apply to the evidence. Second, longer retention improves your ability to respond and also extends your exposure to disclosure requests. Legal and compliance staff should make that call, with security input.

Preserve the evidence so it can be relied on

NIST SP 800-61r2 notes that evidence gathered for one purpose may later be needed in legal proceedings, and that when it might be, it is important to document clearly how it has been preserved. It also advises collecting evidence according to procedures developed with legal staff, and accounting for it at all times, with chain of custody records detailing each transfer between persons.

That guidance was written for incident handling, not for AI code provenance, but the principle carries over. If generation and configuration records are exported from one system to another, the export path should keep a record of who handled them and when. Agree the preservation procedure with legal staff in advance, including who can place a hold on records and how a hold overrides normal deletion.

Also keep dated copies of the contract terms and product documentation in force at each point. If the conditions change over time, you will need to show which version applied to the code in dispute.

Where runtime enforcement and code provenance help, and where they do not

Enforcement in the execution path of a coding assistant produces records as a by-product of applying policy. Trussed enforces policy on coding assistants at runtime, not as a review after the fact, with actions that include allow, redact and block for individual interactions. Each decision generates audit-ready evidence at the time it is made. Trussed code provenance adds the origin, licence and security context of code. Self-managed deployment in your cloud, with configurable retention and data residency, means you control how long that evidence lasts and where it sits.

The limits matter for a claim. Evidence exists only for interactions that pass through the enforcement point, so assistants or usage outside that path are not covered, and nothing is reconstructed for activity before deployment. Enforcement evidence also does not replace the contract analysis: it cannot tell you which conditions apply, and it does not determine whether a claim would succeed. What it does is ensure that the configuration, decision and provenance records you need to attempt the reconstruction exist, are retained for the period you set, and are held by you.

A team that never uses Trussed can still apply the same test: for each condition in the terms, identify the record, where it is stored, who controls its retention, and how it links to the code.