AI Coding Tool Indemnity, Copyleft Code and Contractors: Where Coverage Ends

What an indemnity does and does not do

A vendor IP indemnity is a promise to defend or compensate the customer against certain third-party claims about the tool's output, subject to stated terms. It transfers some financial and legal exposure. It does not stop copyleft-licensed code from entering a codebase, and it does not tell you where that code now sits.

Terms differ by vendor, product tier and agreement, so the useful exercise is to read each indemnity against four questions. Who is the covered customer or user? Which products and tiers qualify? Which kinds of claim are in scope? Which conditions and exclusions apply?

The third question matters for copyleft. Many IP concerns about generated code are framed as copyright claims. Copyleft risk is often about licence obligations that attach when code is combined, distributed or deployed in particular ways. NIST's generative AI profile frames IP risk largely in copyright terms, such as use of copyrighted works that is not fair use and outputs that memorise training data. Compliance teams should confirm in writing whether a licence-compliance dispute over GPL, AGPL or LGPL material falls within the defined scope of covered claims, rather than infer it.

Contractor scenarios mapped to indemnity questions

The contractor problem is mostly a mismatch between who holds the contract and who does the work. Each common arrangement raises a different question.

• Contractor uses a personal or firm-owned account: The enterprise may not be the contracting customer. Check whether the indemnity reaches output generated under a subscription the enterprise does not hold.
• Contractor uses an enterprise-provisioned seat: Check whether non-employees may be users under the agreement, and whether the tier and required settings are enforced for them.
• Third-party delivery team on its own tooling: Coverage depends on the outsourcer's agreement and configuration. The enterprise usually cannot see either unless the contract requires disclosure.
• Mixed human and AI-authored code: Modification, combination or pasted code from other sources may fall under exclusions. Without records, the origin of each segment is hard to establish.

Conditions that must be enforced and evidenced

Indemnity conditions generally fall into a few groups. Some are configuration requirements, such as enabling a duplicate-detection or public-code filter. Some limit the output covered, for example by excluding output the user has modified or combined with other material. Some concern conduct: complying with usage policies, giving prompt notice of a claim and cooperating in the defence.

Each group has an evidence problem. A required setting only helps if it was on for the person and session in question. An unmodified-output condition is hard to demonstrate if no one recorded what the assistant produced and what was committed. Notice and cooperation obligations assume you can reconstruct events quickly. For employees, central administration can address some of this. For contractors working on their own accounts, tiers or configurations, the enterprise often has neither control nor records.

The practical conclusion is that the enterprise holds the burden of showing conditions were met, and relying on contractor self-attestation leaves that burden unsupported.

Policy and provenance guidance that supports the control side

NIST guidance does not address vendor indemnities, but it supports the controls around them. The NIST AI 600-1 draft recommends updating generative AI acceptable use policies to cover contractors, consultants and other third-party personnel, and to address both proprietary and open-source technologies. It also lists assessing vendor risk controls for IP infringement and screening outputs against copyrights and other IP. NIST also notes that provenance practices, including documenting the origin of generated data with copyrights and licences, support transparency and accountability.

NIST SP 800-218A, a guidance profile and not a legal requirement, does not distinguish between human-written and AI-generated source code. All code should be evaluated before use through code review, code analysis or both, and issues should be recorded and triaged. It also points to least-privilege toolchain configuration, automated enforcement of requirements in the toolchain, and provenance tracking. Applied here, contractor contributions get the same scrutiny as employee code, and checks sit in the toolchain rather than depending on a contractor's account of what they did.

How enforced policy and code provenance close the evidence gap

Two capabilities matter for indemnity conditions. The first is policy enforcement in the path of the coding assistant, so that rules apply when the interaction happens and are not reviewed after the fact. Depending on policy, an interaction can be allowed, redacted, blocked, rate limited or escalated for human approval. Because the decision is made in the path, each decision can be recorded with the policy that applied. That is stronger evidence than a contractor's statement that settings were followed.

The second is code provenance: the origin, licence and security context of code. When a contribution arrives, a provenance record shows where code came from and under what licence, so a team can identify copyleft-licensed material before it is merged and show later what was known at the time. This also helps with exclusions for modified or combined code, since a record of the original and the committed version shows what changed.

Trussed enforces policy in the execution path of coding assistants, alongside models, agents, tools and MCP servers, and produces code provenance and audit-ready evidence from that enforcement. This does not replace the indemnity or a legal reading of it. It supplies the records that let legal and compliance teams show conditions were handled, and it shows where residual licence risk remains with the enterprise.

There are tradeoffs. Enforcement for contractors requires routing their assistant activity through enterprise-controlled paths, which must be written into contracts and onboarding. Contractors who refuse or work offline remain a gap, and some may need a separate rule that their AI-assisted code is not accepted without disclosure and scanning.