Cross-Tool AI Coding Indemnity Evidence Checklist for Software Vendors Facing a Copyleft Claim

Why indemnity needs evidence, and why it differs by tool

Most vendors that use AI coding assistants use more than one: an IDE assistant, a chat-based tool, and increasingly an agentic tool that edits repositories directly. Each is governed by its own agreement. Each may attach different conditions to any indemnity it offers, and each exposes different records. Treating indemnity as a blanket safeguard across all of them is the most common planning error.

A more useful working assumption is that indemnity is conditional and tool-specific. To invoke it, a vendor generally has to show that it used the tool in the way the agreement contemplates, and that the code at issue came from that tool. Both showings are evidentiary. If the vendor cannot say which tool produced which code, or what settings applied at the time, it weakens both its defence against the claim and its position against the tool provider.

NIST's Generative AI Profile points in the same direction. It lists actions to document the origin and licences of generated content, and to update third-party contracts, service agreements and warranties for generative AI risk, noting that these may include GAI-specific indemnity clauses. The checklist below turns that into working categories. Confirm every condition against the agreement currently in force for each tool, not against a summary or a past version.

What can be gathered later and what cannot

The practical value of the checklist lies in sorting each item by when it can be obtained. Some evidence persists in ordinary systems and can be reconstructed after a claim: the tool inventory, current agreements, repository history, commit metadata, and the licence of a given component. These gaps can be closed retroactively, though reconstruction costs time and is easier to challenge.

Other evidence exists only if it was captured when the code was produced. This includes the exact settings and filter state at that moment, the origin or licence signals presented to the developer, and session-level records that a tool may not keep. The tool-specific retention behaviour is something to verify per tool, but the general principle holds: a setting that has since changed cannot be proven to have been on last quarter by looking at it today.

NIST's guidance on runtime evidence and its inventory concept for agentic systems supports treating evidence generated at execution time as a separate class from evidence reconstructed afterwards. When assessing your own position, mark each checklist item as recoverable, partly recoverable or recoverable only if captured at runtime. The third group is where pre-claim work matters most.

Chain-of-custody, integrity and early preservation

Evidence that cannot be shown to be unaltered is less useful in a dispute. NIST's content provenance guidance refers to techniques such as cryptographic signatures and digital fingerprints, and to access controls and integrity verification, as support for provenance. For a licence dispute, the practical reading is that records should be stored so that their integrity can be verified, not merely stored.

Once a claim is suspected, start preserving immediately. NIST's incident handling guidance, written for security incidents and applied here only by analogy, advises beginning documentation and evidence gathering as soon as an incident is believed to have occurred, acquiring and preserving evidence, and capturing volatile data. It also advises documenting every action, every piece of evidence and every conversation. In this setting, treat in-tool settings and session records that may not persist as candidates for early capture, and keep a contemporaneous log of who collected what, when and from where.

Avoid routine changes during collection. Upgrading a tool, altering a policy or deleting old workspaces can destroy the state you are trying to document. Agree with counsel which actions are paused and for how long.

Closing gaps before a claim arises

The gaps that cannot be closed afterwards are closed by changing what is captured in the normal course of development. Five measures are the most direct.

• Maintain a living tool inventory: Include unsanctioned and trial tools, and review it on a fixed cadence.
• Baseline and version settings: Record approved configurations and keep a dated history of every change.
• Capture origin and licence context at generation: Store the signals that were present when code was produced, not only when it is later scanned.
• Set retention to match claim horizons: Agree retention periods with counsel, and confirm that tool-side retention is not your only copy.
• Rehearse the handoff: Assemble a sample evidence package for one repository and note what is missing.

Where policy enforcement and provenance fit

Trussed addresses the runtime part of this problem. It enforces policy in the execution path across coding assistants, with actions such as allow, redact and block applied to individual interactions and tool calls, and it provides code provenance covering the origin, licence and security context of code. Because the evidence is generated by enforcement rather than assembled afterwards, it is audit-ready as a by-product of normal operation. Deployment is self-managed in the customer's cloud, with configurable retention and data residency, so retention can be set to match the periods agreed with counsel.

This does not replace reviewing each tool's agreement or the advice of counsel, and it does not establish that any indemnity applies. It supports one category on the checklist: evidence that exists only if captured when the code was produced.