AI Coding Tool Indemnification Liability Caps: Comparing GitHub Copilot, Claude Code and Amazon Q Developer

What an indemnity does and does not do

An IP indemnity is a contractual allocation of risk between the vendor and the customer. It does not change the underlying law. The Congressional Research Service states that if a generative AI output infringes the copyright in an existing work, both the AI user and the AI company could potentially be liable under current law. It also notes that a user might be directly liable for prompting a system to produce infringing output, and that this can be hard to assess because the user may not know of the work allegedly infringed.

For procurement, this means the indemnity is the mechanism that decides who bears the cost if a claim arrives, and only to the extent its terms are met. NIST's generative AI profile warns that vendor services and non-standard terms can amplify or defer liability in unexpected ways, and suggests clear assignment of liability and responsibility. Three questions follow for every tool: what is covered, how much is the vendor's exposure limited, and what must the customer do to keep the coverage.

What to extract for each tool

Build one record per tool and per plan tier, using the contract documents that actually bind your organisation. The same fields apply to GitHub Copilot, Claude Code and Amazon Q Developer. Fill them from the current text of each vendor's terms, not from marketing pages or sales summaries.

• Scope of coverage: Which output and which claims are covered, which products and tiers are in scope, and whether the indemnity applies to the specific product you deploy.
• Cap or carve-out: Whether indemnity obligations sit inside the general limitation of liability, carry a separate cap, or are excluded from the cap.
• Exclusions: Carve-outs for modified output, combined code, customer-supplied inputs, or use outside the documented product.
• Technical conditions: Settings, filters or configuration the customer must enable and keep enabled for the indemnity to apply.
• Process duties: Notice deadlines, cooperation obligations and control of defence and settlement.
• Document hierarchy: Which document prevails in a conflict: order form, product-specific terms, general agreement or policy pages incorporated by reference.

How caps and conditions interact in a mixed-tool environment

Each indemnity is a separate promise from a separate vendor. There is no shared pool of coverage across tools. If one vendor's indemnity is subject to the general liability cap and another's is carved out, the practical exposure differs for code that comes from each. Capped amounts are not additive in any useful sense unless the contracts say so, and the contracts are unlikely to address overlap.

The harder problem is attribution. In a codebase where developers use several assistants, a single file can contain output from more than one tool, edited by a person, then merged. If an indemnity excludes modified code or code combined with material not supplied by the vendor, then code from other tools or from the developer may be exactly what the exclusion describes. Whether a given merged function is covered by any indemnity is a contract-interpretation question for legal counsel, but counsel can only answer it if the enterprise can show which tool produced what, under which settings, on which plan.

Plan tiers add another variable. The same vendor may offer different terms to different plans, and an individual developer using a personal account on a work repository sits outside the enterprise agreement. Procurement should confirm that every developer seat in use maps to the contract you negotiated.

Contractual duties versus conditions you can enforce and evidence

Split the conditions into two groups. Contractual duties, such as giving timely notice or cooperating in a defence, are met by people following a process. Technical conditions, such as a required setting or filter, depend on configuration that can drift. A setting enabled at rollout can be changed by an administrator, a developer or a policy update, and the indemnity may not care when it changed, only that the condition was not met when the code was generated.

That makes dated evidence the practical test. An enterprise relying on an indemnity should be able to show, for a given piece of code, which tool generated it, what configuration was active at that time, and what the code's origin and licence status were. The need for this evidence follows from how conditions are framed rather than from a requirement stated by any one vendor, so treat it as a control design choice. NIST's AI RMF supports folding AI risk into broader enterprise risk management, and conditions-compliance fits there alongside cybersecurity and privacy controls.

A reasonable operating model: engineering owns configuration baselines and change control, legal owns the contract map and exclusions analysis, and procurement owns the record of plans and seats. Review all three whenever a vendor updates its terms or a new tool is added.

Where runtime enforcement and code provenance fit

Trussed enforces policy in the execution path of coding assistants, so conditions that depend on technical behaviour can be enforced at runtime, not reviewed after the fact. Policy can allow, redact or block individual interactions and tool calls. Code provenance records the origin, licence and security context of code, and enforcement produces audit-ready evidence that a regulated enterprise can show to an auditor or regulator.

This helps a regulated enterprise meet and demonstrate conditions that depend on configuration and code handling. It does not change any vendor's liability, the scope of any indemnity or legal coverage, which remain matters of the contracts and of legal advice.