AI-Generated Code Provenance for Indemnity Claims: Proving Which Tool Generated a GPL-Matching Snippet

What an indemnity claim has to establish

Treat attribution as an evidence-engineering problem. The legal terms belong to counsel, and this guide is not legal advice. But whatever the wording of a specific vendor programme, a claim for a GPL-matching snippet generally rests on a chain of five links.

The first is the similarity match: a demonstrable overlap between the snippet and GPL-licensed source. The second is tool identification: showing that one particular assistant produced the output, not a human author, an open-source import or a different assistant. The third is interaction context, meaning the prompt, surrounding code, model version and user. The fourth is the set of conditions the vendor attaches to its indemnity, which may include whether filters were enabled and whether the output was used unmodified. The fifth is chain of custody: evidence that the records linking these elements are complete and unaltered.

The first link is a comparison exercise. The second through fifth are record-keeping problems. A similarity match says nothing about who or what wrote the code, and that gap is where most claims weaken.

Where attribution breaks down in common setups

Most regulated enterprises do not run one assistant. Developers use several AI coding tools alongside human authorship and imported open-source code. A commit records who committed a change, not which tool produced each line. IDE telemetry is usually partial and fragmented across tools. Vendor-side logs sit outside the enterprise's control, so their completeness, retention and format are not something the claimant can guarantee.

Copy-paste and editing make this worse. Once a developer pastes output from one assistant into a file, edits it, and merges it with other code, the origin of any given fragment is hard to recover. If an indemnity condition depends on unmodified output, the enterprise also needs a record of what was generated versus what was changed.

Detection after the fact does not close the gap. NIST's synthetic content work notes that patterns in text depend heavily on the prompt that produced it, and that mixing AI-generated and non-AI-generated text is relatively easy. One submission to NIST from the Computing Community Consortium goes further, giving the authors' opinion that consistent, accurate detection of AI-generated content is impossible. That is commentary, not a NIST finding, but the direction is consistent: inferring origin from the content alone is not a sound basis for a claim.

Why runtime evidence is stronger than reconstruction

NIST describes provenance data as a strong signal that affirmatively describes the history of content, and notes that provenance techniques can be added proactively during generation. Provenance detection only works if the data was recorded when the content was created. That is the core argument for capturing evidence in the path where code is produced, rather than assembling it from commits and vendor logs later.

Two further properties matter. First, tamper evidence: NIST points to tamper-proof histories and content authentication methods such as cryptographic signatures and digital fingerprints, and recommends measuring their reliability, including false positive and false negative rates. A claim built on records that could have been edited invites challenge. Second, absence can be informative. If every generation event is expected to produce a record, a snippet with no record is itself a finding to investigate.

There is also a baseline to keep in view. NIST's secure development profile for generative AI does not distinguish between human-written and AI-generated source code, because all code needs evaluation before use. That control is worth keeping, but it does not establish where a given snippet came from.

Trussed enforces policy in the execution path across coding assistants, with actions such as allow, redact and block, and provides code provenance covering the origin, licence and security context of code. The audit-ready evidence it produces is generated by enforcement at runtime, not reviewed after the fact. Whichever tooling you use, the design test is the same: the evidence should be a by-product of the control, not a separate reconstruction exercise.