AI Coding Tool Indemnity and Open Source License Claims: What Insurers Should Verify

Copyright infringement and license breach are different claims

A copyright infringement claim generally alleges that protected work was copied or used without permission. An open source license claim starts from a different place. The code was released under a license that grants permission subject to conditions, such as preserving attribution, keeping notices intact, or making source available under copyleft terms.

When a condition is not met, a claimant may frame the dispute in more than one way: as breach of the license, as breach of contract, or as infringement because the use went beyond what the license allowed. The framing matters because an indemnity worded around "infringement" may or may not be read to reach a claim that is not pleaded as infringement. How a given claim would be treated is a question for counsel, and this guide is not legal advice.

Risk frameworks reflect the distinction. NIST's Generative AI Profile draft lists copyrighted or trademarked content, trade secrets and other licensed material as infringement exposure. Separately, it lists terms and conditions as one of the checks when verifying that content provenance complies with relevant laws and regulations. The two concepts are related but are treated as separate items.

How indemnity language tends to treat each claim type

The first thing to read is the definition of a covered claim. A clause that covers third-party claims alleging that generated output infringes copyright gives clear footing for infringement. It gives less certainty for a claim that alleges a missed attribution or an unmet copyleft obligation, particularly when that claim is expressed as breach of license terms. A clause that names open source licenses, attribution, notice or copyleft obligations is more explicit, and explicit wording is what a risk team should look for.

Two other elements shape how the definition works in practice: what counts as a claim (a filed suit, a demand letter, or both), and what the vendor pays for (defense, damages, settlements). A broad definition of covered claims can still be hollowed out by narrow remedies or by control-of-defense terms the customer cannot accept.

NIST's draft guidance suggests updating third-party contracts, service agreements and warranties to address generative AI risk, and notes these may include generative AI-specific indemnity clauses. It lists indemnity alongside screening, provenance documentation and review. That is the right reading for an insurer: the indemnity is one risk transfer mechanism, not the whole control set.

Conditions and exclusions decide practical coverage

An indemnity can be sound on paper and still be unavailable for the code that triggers a claim. Conditions tied to configuration are the usual cause. If coverage requires a public code matching filter or a particular product tier, the insured must be able to show that the setting was on, for that user, at the time that code was generated. In an organization with many developers, several tools and mixed licensing tiers, that is a records problem as much as a contract problem.

Modification is the second common limit. Developers routinely edit assistant output, and an exclusion for modified output can remove coverage for code that began as a suggestion but was changed before merge. Reviewers should ask how the clause defines modification and who bears the burden of showing what the original suggestion looked like.

The third is the gap between what the contract says and what teams assume. Procurement may record "IP indemnity in place" while the clause covers one claim type, for specific tiers, under specific settings. Documenting the actual scope, and the configuration needed to stay inside it, closes that gap.

Evidence and controls that sit beside the contract

A contract can allocate loss after a claim. It does not produce a record of what code was generated, where it came from or under what license. NIST's draft guidance suggests documenting the origin of generated data, including copyrights and licenses, and scanning outputs for licensed or plagiarized material. NIST SP 800-218A adds that its practices do not distinguish between human-written and AI-generated source code, so assistant output should pass the same evaluation as any other code before use.

For insurers there is a governance dimension. NAIC states that state insurance regulators oversee insurers' use of AI and may require companies to explain how AI tools are used in underwriting, pricing, marketing or claims decisions. Whether and how that applies to internal coding assistants, and how the NAIC AI Model Bulletin and NYDFS Circular Letter 7 apply, should be confirmed with counsel as of November 2026. In either case, evidence that exists independently of vendor attestations is easier to defend than an indemnity alone.

Trussed enforces policy in the execution path of coding assistants, with allow, redact and block decisions applied to individual interactions and tool calls. It records code provenance, meaning the origin, licence and security context of code, and produces audit-ready evidence mapped to NAIC, NYDFS and NIST. Policy is enforced at runtime, not reviewed after the fact, so the record of what the assistant was allowed to do and what it did exists if a claim or examination arises. It supports the indemnity and does not replace it.