AI Coding Assistant Indemnity and AGPL-3.0: Source Disclosure Demands Versus Damages

What an indemnity is built to do

An indemnity is a contractual allocation of loss. The vendor agrees that, if a third party brings a defined type of claim arising from the customer's permitted use of the product, the vendor will take on specified costs. Those costs are typically described in terms of defence, settlements and damages or awards. The agreement then narrows that promise through definitions of the covered claim, exclusions, and conditions the customer must meet.

This structure suits a copyright infringement claim, where the dispute ends in a payment. It is a weaker fit for a copyleft licence, where the contested outcome may be a duty to act, not a sum to pay. Compliance leaders should therefore start by asking what outcome the indemnity is written to produce, rather than whether an indemnity exists.

Why a disclosure demand differs from a damages claim

AGPL-3.0 is a copyleft licence. Its conditions travel with the code, and the concern in the brief is that a network-use source disclosure demand can require an organisation to release source code. That is an obligation attached to a licence, and it can arise whether or not anyone has suffered a quantifiable monetary loss.

The mismatch follows from this. A vendor that agrees to pay damages, settlements and defence costs has not necessarily agreed to prevent, fund the avoidance of, or remedy a requirement to disclose source. Some indemnities may address non-monetary remedies expressly. Others may be silent, and silence leaves the question to interpretation. Legal counsel should read the operative clauses and the licence text together, and compliance teams should record the answer rather than rely on a general expectation that the vendor has the issue covered.

There is also a practical point. Even where a disclosure demand is arguably within scope, the cost of the underlying outcome, such as exposing proprietary code, may not be something a payment can reverse. That is the main reason to treat indemnity as one layer of protection rather than the whole answer.

Damages remedies and source disclosure compared

The table below sets out the contrast a compliance team should have in mind when reading indemnity language. It describes the general shape of each remedy, not the terms of any specific vendor.

• Nature of the remedy: Damages are monetary. Source disclosure is a non-monetary obligation to make code available.
• Typical indemnity response: Indemnities commonly address defence costs, settlements and awards. Disclosure is only covered if the wording reaches it.
• Who bears the outcome: A payment can be transferred to the vendor. A disclosure duty remains with the party subject to the licence.
• Reversibility: Money paid can be recovered in part through the indemnity. Released source cannot be recalled.
• Where risk is reduced: Damages risk is reduced by contract. Disclosure risk is reduced mainly by preventing the code from entering the codebase.

Controls at the point of generation

NIST AI 600-1 describes drafting and maintaining well-defined contracts and service levels for generative AI that specify content ownership, usage rights, quality standards, security requirements and content provenance expectations. That gives a sound heading for contract review. It also points to a limit: a contract states expectations, but it does not on its own change what enters a repository.

The following is an editorial position rather than sourced guidance. Exposure to a copyleft obligation is lowest when code with a problematic licence never reaches a merged branch. That requires three things at generation time. First, provenance for suggested code, meaning its origin, its licence and its security context. Second, a policy that decides what happens when the licence context matches a rule the enterprise has set: allow the output, redact part of it, block it, or escalate it for human approval. Third, a retained record of what was suggested, what policy applied and what decision followed.

That record matters for two reasons. It lets a team show that conditions attached to an indemnity were met, such as filters being active. It also gives counsel a factual basis if a demand arrives. Retention periods and data residency should be set deliberately, since the same records may include code and prompts. The FTC has said that AI providers that fail to honour privacy and confidentiality commitments about customer data may face liability, which is a reason to check how a vendor's commitments on prompts and code are written into the contract.

Where Trussed fits

Trussed is built for regulated enterprises that must show a regulator or auditor what their AI was allowed to do and what it did. It does not replace contractual review, and it is not a legal safeguard or a guarantee that an indemnity will respond.

Within that scope, Trussed enforces policy in the execution path across coding assistants, models, agents, tools and MCP servers. Enforcement applies to individual interactions and tool calls, with the ability to allow, redact, block, rate limit or escalate for human approval. Code provenance gives origin, licence and security context for code, so a regulated enterprise can write policy against that context, for example sending output with a copyleft licence for human approval. Enforcement is at runtime, not reviewed after the fact.

Each enforcement decision produces audit-ready evidence, mapped to frameworks including HIPAA, NAIC, NYDFS, the EU AI Act and NIST. Trussed can be deployed self-managed in the customer cloud, with configurable retention and data residency. Used alongside careful reading of indemnity terms, this gives legal, compliance and engineering teams a shared record of what was generated, what policy applied and what was decided.