Which indemnity applies when one repository uses three coding assistants

How vendor indemnity terms are typically structured

An IP indemnity for an AI coding assistant is a contractual promise from the vendor to respond to certain third-party claims about generated output. It is not a property of the code. It attaches to code only when the surrounding conditions in the agreement are met.

Those conditions tend to fall into a few groups. The first is scope: which products and plan tiers are covered, so a tool used under one tier may sit outside the indemnity that applies to another. The second is configuration: the vendor may require that specific filters or settings, such as duplicate-detection or public-code matching controls, were enabled when the output was generated. The third is exclusions: output that a developer modified, or that was combined with other material, may fall outside coverage.

None of these conditions can be assessed from the code alone. Each one is a question about the tool, its settings and the moment of generation. That is why the technical record matters as much as the clause.

The NIST Generative AI Profile points the same way. It recommends updating third-party contracts, service agreements and warranties to address generative AI risks, and notes that such documents may include GAI-specific indemnity clauses, dispute resolution mechanisms and other risk controls. Indemnity is one part of third-party risk management, which is why procurement and legal belong in the process.

Why three assistants in one repository blur the answer

With one assistant, the question is relatively contained: were the vendor's conditions met when the code was generated? With three, the same question has to be answered three times, against three sets of terms that were written independently and do not align.

Conditions can conflict. One vendor may require a filter that another does not offer. One may exclude modified output while another is silent on it. A setting that is enforced centrally for one tool may be a per-developer toggle in another.

Gaps appear at the seams. A function may start as a suggestion from one assistant, be edited by a developer, and then be refactored with help from a second assistant. Each step may change which vendor, if any, could be said to have produced the code, and whether the output is now treated as modified or combined. Version control records the commit and the author. It does not record which assistant contributed which lines or what its settings were.

Terms also change over time. The agreement in force today may differ from the one in force when a snippet was generated, so the generation date has to be reconciled with the contract version. Without attribution, the enterprise cannot say which indemnity to look at, and cannot show that any vendor's conditions were satisfied.

The technical records that support a claim

NIST action GV-6.1-014 recommends maintaining detailed records of content provenance, including sources, timestamps, metadata and any changes made by third parties. Applied to coding assistants, that maps to the evidence an indemnity discussion needs. The mapping is an interpretation, not NIST text, and it does not prescribe an architecture.

Five record types cover most of the ground. Capture them at generation time, because reconstructing them later is unreliable.

• Origin: The assistant, product, tier and version that produced a segment, tied to the interaction that generated it.
• Configuration: The filters and settings in effect for that assistant, recorded with the interaction.
• Timestamp: The time of generation, so settings and contract versions can be shown for a specific date.
• Change history: Later edits by developers or other assistants, kept so they survive merges and refactors.
• Licence and security context: What is known about the licence and security posture of the code at the time it entered the repository.

What belongs with legal counsel, not engineering

Engineering can establish facts: which tool, which settings, which time, which later changes. It cannot decide what those facts mean under a contract. Keep the following questions with legal counsel and treat engineering output as input to them.

Which indemnity, if any, applies to a snippet that was generated by one assistant, edited by a developer and combined with output from another? Does editing or combining remove coverage under each vendor's terms? Were the conditions met, and is the retained evidence sufficient to show it? How should changes in contract terms over time be handled? How do vendor data-use and privacy commitments factor into the same review? The FTC has said that AI model companies that fail to abide by their privacy commitments to customers may be liable under laws it enforces, which makes those commitments a reasonable item to review alongside IP indemnity.

The liability questions are also not settled in general terms. An FTC comment to the Copyright Office frames, as open questions, how liability should be apportioned among users, AI tool developers and training-dataset developers. A contract is therefore the enterprise's main concrete instrument, which raises the importance of reading it precisely.

Enforcing policy and capturing provenance in the execution path

Settings that depend on each developer's configuration are hard to prove after the fact. One design option is to enforce policy in the execution path across all coding assistants, so the same rules apply regardless of which tool a developer opens, and the enforcement itself produces the record.

Trussed does this for coding assistants alongside models, agents, tools and MCP servers. It enforces policy at runtime, not reviewed after the fact, with allow, redact and block decisions applied to individual interactions. Its code provenance capability records the origin, licence and security context of code. Because evidence is generated by enforcement, a regulated enterprise can show which policy was in effect for an interaction and what happened, as audit-ready evidence rather than reconstructed history. Trussed can be self-managed in the customer cloud, with configurable retention and data residency.

This supports the evidence side of the checklist. It does not replace contract review, does not determine whether any vendor's conditions were met, and does not guarantee indemnity coverage. Those determinations remain with legal counsel and the vendors' terms.