Anthropic Commercial Indemnity and GPL Code Written by Claude Code

What a vendor indemnity does and does not do

An indemnity is a contractual promise to defend or compensate a customer for defined third-party claims, subject to conditions. Three terms usually set its boundary: how the agreement defines covered output, whether the customer's use was authorized under the agreement, and which exclusions apply. Anthropic's commercial terms should be read against all three for Claude Code used under commercial plans or API access, and counsel should work from the current published text rather than summaries.

Conditions in indemnities of this kind can include use of the service as permitted, limits on modified or combined output, and duties to give notice and cooperate in a defence. Each condition is a point where coverage can narrow, and each creates a record-keeping question for the customer.

An indemnity is also reactive. It operates after a claim is made. It does not prevent copyleft-licensed code from landing in a repository, it does not tell engineers that a suggestion resembles licensed source, and it does not create a record of how a decision was made. NIST's generative AI profile lists intellectual property replication as a risk and notes that contracts may include GAI-specific indemnity clauses. The same guidance treats contract updates, acceptable use policies and output review as separate actions, which is a useful way to frame the problem: contractual risk transfer and operational control are different layers.

How copyleft obligations attach to generated code

The GPL grants rights to copy, modify and distribute code, conditioned on obligations. When a covered work is distributed, those commonly include making corresponding source available under the same licence terms and preserving copyright and licence notices. Other copyleft licences differ on what triggers the obligations, including whether network use counts as distribution.

If generated output reproduces or is derived from licensed code, and your organization incorporates it into software it distributes, obligations can follow from your own act of distribution. It does not matter that a tool, not a developer, produced the text. Whether a particular snippet is a reproduction substantial enough to carry obligations is a legal judgement for counsel and depends on the facts.

This is why two different things need to be kept apart. A third-party IP claim is an allegation by a rights holder that someone infringed. A licence-compliance obligation is a duty the distributing organization has to meet, such as attribution, source disclosure or licence compatibility across a codebase. An indemnity may address the first. Whether it reaches the second depends entirely on its wording, and compliance leaders should not assume that it does. Distribution model matters too. Internal tooling, shipped products and hosted services can each carry different exposure.

Why controls need to sit before the repository

Review after the fact still has value, but it has limits. By the time a pull request is scanned, the generated code is already in a branch, and the context of the generation is gone. Reviewers see a diff, not the interaction that produced it.

NIST SP 800-218A does not distinguish between human-written and AI-generated source code, on the assumption that all code should be evaluated before use. That supports applying existing secure-development review to AI-generated code. It is framed around vulnerabilities and other issues, and NIST's secure development profile addresses cybersecurity risk. Licence compliance is therefore not clearly covered by it and needs explicit internal policy. NIST also recommends defining acceptable use policies for generative AI systems and reviewing generated code, which gives that internal policy a reasonable starting point.

A control at the point of generation can do something a later scan cannot: it can attach origin, licence and security context to the code as it is produced, and apply a policy decision at that moment. Provenance here means a record of where code came from, under what licence, and with what security characteristics. NIST pairs provenance with governance as core considerations, and treating provenance records as an input to governance decisions follows from that pairing.

Audit-ready evidence and where a control layer fits

Auditors and legal teams need to see that a licence-risk decision was enforced, not just that a policy existed. Useful evidence typically records what was generated, what origin and licence context was identified, which policy version applied, what decision resulted, who approved any escalation, and when. It also needs a retention period and data residency that match your obligations. The same record can help show that indemnity conditions, such as authorized use, were met.

Trussed AI is one example of a control layer for this. It enforces policy in the execution path across coding assistants, models, agents, tools and MCP servers, applying allow, redact, block, rate limit or escalate-for-approval decisions to individual interactions and tool calls. Its code provenance capability supplies the origin, licence and security context of code. Enforcement produces continuous audit-ready evidence mapped to frameworks including NIST, and it can be deployed self-managed in the customer cloud with configurable retention and data residency. It has run continuously in production at a regulated enterprise for more than 18 months. It does not replace an indemnity or legal review. It addresses the operational layer the contract leaves with you.

Practical next steps: have counsel read the current indemnity terms against the criteria above, write an acceptable use policy for coding assistants, define licence categories and the outcome for each, and decide which cases require human approval.