AI Coding Tool Indemnity Combination Exclusion: Mixed-Tool Code and Provenance Records

How these exclusions are typically worded

AI coding tool indemnities generally promise to defend or cover the customer against certain third-party IP claims arising from the vendor's output. That promise is then narrowed by exclusions. Three families matter for mixed-tool work, and the wording of each varies between contracts.

Combination exclusions remove coverage where the output is combined with code, data, or tools that the vendor did not provide. The interpretive question is scope. Some clauses apply to any combination. Others apply only where the combination is what gives rise to the claim. Whether another AI assistant counts as a tool or code the vendor did not provide is a drafting question, and the plain text may or may not settle it.

Modification exclusions remove coverage where the output has been altered. A developer who accepts a suggestion and then edits it, or who merges two suggestions into one function, may be modifying output in the contract's sense. Contracts differ on whether any edit qualifies or only edits that cause the alleged infringement.

Conditions-of-coverage clauses make protection depend on the customer meeting stated requirements, such as enabling particular filters or settings. These are evidential in nature: the enterprise may need to show the setting was active when the snippet was generated, not merely that it is active today.

The records needed to substantiate an indemnity position

NIST's generative AI guidance calls for transparency policies and processes that document the origin of generated data, including copyrights, licences and data privacy, to advance content provenance. It also includes an action to keep a document retention policy covering history for testing, evaluation, validation and verification, and for digital content transparency methods. This guidance is voluntary and does not establish indemnity coverage, but it is a sound reference for internal audit evidence requirements.

For coding assistants, provenance implies per-snippet records rather than file-level or repository-level attribution. A file that contains suggestions from two tools cannot be described accurately by a single label. The records should also be made at generation time. Reconstructing configuration and tool identity after a claim arrives is unreliable, and it is exactly the situation a conditions-of-coverage clause tests.

An enterprise-defined minimum record would hold the tool, model or version, configuration and filter state, timestamp, licence-match result, and security context of each suggestion. It should also note whether the suggestion was accepted and whether it was later changed. This schema is a design choice, not a published standard, so confirm with each vendor which fields their tools expose.

• Tool identity and model or version
• Configuration and filter state at generation
• Timestamp and the terms version in force
• Licence-match result
• Security context of the code
• Acceptance and later modification status

Implementation decisions for a regulated enterprise

Start with an inventory. Establish which assistants are in use, in which repositories, and under which settings, before assessing indemnity exposure. Then decide how much mixing to allow while contract positions are unresolved. Restricting mixed-tool use on specific repositories or file types is one option. The trade-off is developer friction against the clarity of keeping each tool's output separable.

Set a retention period for generation records, and version-control the vendor terms in force at the time of generation. Record the decision to accept or limit multi-tool use, along with residual risk and deployment context, as NIST's risk management framework encourages. If the NIST secure software development profile for generative AI is in scope for your programme, map its tool configuration practices to assistant configuration management.

• Inventory assistants, repositories and settings
• Define the minimum per-snippet record
• Set a retention period for generation records
• Version-control vendor terms by date
• Decide where mixed-tool use is restricted
• Record the risk acceptance decision

Where runtime enforcement and code provenance fit

Records that depend on developers noting their own tool use will be incomplete. A control point in the execution path of each coding assistant can capture identity, configuration and policy decision when a suggestion is made. That is a design option, and it does not substitute for contract review or legal advice.

Trussed enforces policy in the execution path across coding assistants, with actions to allow, redact or block at the level of individual interactions and tool calls. Enforcement is applied at runtime, not reviewed after the fact, so an enterprise can restrict which assistants may touch regulated repositories. Trussed also provides code provenance covering the origin, licence and security context of code, and generates audit-ready evidence from enforcement, mapped to frameworks including NIST. It can be self-managed in the customer's cloud, with configurable retention and data residency.

This supports the evidence side of the question: what was generated, by which tool, under which policy. It makes no claim about how any indemnity applies or whether any vendor's coverage holds.