GitHub Copilot IP Indemnity and AGPL Code in a Network-Facing SaaS Application

What the indemnity is, and what it is not

An indemnity is a contractual promise about who bears the cost of a defined category of claim. It is not a technical mechanism, and it does not change what the code is or what licence terms attach to it. The Copilot indemnity addresses third-party infringement claims and is conditional on specific product settings and contract terms.

That framing sets the boundary for architects. A remedy for a claim brought by a third party does not by itself settle questions that arise inside your own organisation: whether a licence obligation has been triggered, what it would cost to remove or rewrite code, or whether you must disclose source. Those are compliance and engineering matters. Whether any of them falls inside the indemnity is a question for the exact contract text that governs your plan, reviewed by counsel.

NIST guidance points the same way. AI RMF GOVERN 6.1 says policies and procedures should address AI risks associated with third-party entities, including infringement of a third party's intellectual property. NIST's generative AI guidance also notes that third-party contracts may include GAI-specific indemnity clauses. In that framing, indemnity is one risk control among several and does not replace internal policy.

How AGPL Section 13 changes the SaaS exposure

Conventional copyleft obligations are usually discussed in terms of distribution: you hand a binary or a package to someone else, and obligations follow. A SaaS application often never distributes anything. Users interact with it over a network, and the code stays on infrastructure you control.

AGPL Section 13 addresses exactly that pattern. It extends source-disclosure obligations to users who interact with modified software remotely over a network. For a network-facing SaaS product, the deployment model that normally limits distribution-based exposure does not limit exposure in the same way. Whether a particular AI-suggested snippet, once merged into a larger codebase, creates an obligation depends on facts such as what the snippet resembles, how substantial it is, and how it is combined with other code. Those are legal determinations, and this guide draws no conclusion on them.

The architectural point is narrower. If AGPL-licensed code did enter a SaaS codebase, the consequence could be a disclosure duty owed to users, not only a claim from a rights holder. A duty of that kind is a compliance question, which is a different category from the third-party claims an indemnity is written to address.

Separating indemnity questions from compliance questions

Use the table to assign each concern to the right owner before anyone cites indemnity as a mitigation. The right-hand column states what must be established, not a conclusion.

• A rights holder asserts a claim against you: Indemnity question. Check the covered claim types, conditions and exclusions in the governing contract.
• AGPL Section 13 may apply to your deployed service: Licence-compliance question. Legal review decides applicability; engineering supplies the facts about the code.
• Code must be removed or rewritten: Remediation question. Confirm whether the contract addresses remediation cost at all; plan engineering capacity regardless.
• Source disclosure to network users is in question: Compliance duty owned by the enterprise unless the contract text states otherwise.
• A product setting was off for some period: Evidence question. Records must show the required configuration was enforced over time.
• An auditor asks how AGPL exposure was assessed: Control question. Requires scan results, origin records and approvals that exist independent of the vendor.

Contract and configuration conditions that affect coverage

Because coverage is conditional, the conditions become engineering requirements. A product setting, such as a filter for suggestions that match public code, may be named as a condition. If so, the question is not whether the setting exists but whether it was enforced across every user, organisation and period in which code was generated.

Two practical consequences follow. First, settings drift. Individual developers, new teams and new plans can introduce configurations that differ from the approved baseline. A one-time check at procurement says little about the state of the estate eighteen months later. Second, the contract is not static. Terms and documentation change, so the version in force when code was generated is part of the record.

A matching or duplicate-detection feature should also be understood for what it is. A feature that suppresses or flags suggestions resembling public code is a different thing from a licence determination for the code in your repository. Do not assume one substitutes for the other. Your own licence assessment and origin records are what let you answer an auditor, and they should not depend on a single vendor feature.

Where runtime code provenance fits

Most of the controls above depend on capturing facts at the moment code is generated and moves toward a repository, not reconstructing them later. NIST's generative AI guidance suggests ongoing audits, assessments and reporting for third-party GAI risk rather than a one-time review, which is a similar principle.

Trussed provides code provenance covering the origin, licence and security context of code. It enforces policy in the execution path of coding assistants, with actions that include allow, redact, block and escalate for human approval, applied to individual interactions and tool calls. Enforcement generates audit-ready evidence as it happens. It is enforced at runtime, not reviewed after the fact. Trussed can be self-managed in the customer cloud, with configurable retention and data residency.

This addresses the evidence and control side of the problem. It does not alter contract terms, and it makes no claim about how any indemnity would respond. Whether you use Trussed or build equivalent controls, the aim is the same: a record that shows what was allowed, what was generated and how licence exposure was assessed.