Copilot Indemnity and MPL 2.0 Code Pasted into Proprietary Files

Why indemnity gets mistaken for a control

Legal, compliance and engineering teams often reason that if the assistant vendor offers IP indemnification, licence risk from AI-assisted coding is handled. That reasoning merges two different things. An indemnity is a contractual remedy: it allocates cost and responsibility if a claim arises. It does not stop licensed code from entering a repository, and it does not tell anyone that it has.

NIST's draft Generative AI Profile frames it the same way. It says third-party contracts, service agreements and warranties may be updated to address generative AI risks, and that they may include GAI-specific indemnity clauses alongside dispute resolution mechanisms and other risk controls. Indemnity is one contractual risk control among several, and it sits next to technical controls rather than replacing them.

Where pasted code sits relative to indemnity conditions

Vendor indemnities for AI coding assistants are conditional. Eligibility commonly depends on how the output was produced and used, for example whether the code was an unmodified suggestion and whether the vendor's own filters were enabled. Compliance teams should read the current Microsoft and GitHub terms for the exact conditions and have counsel interpret them.

The structural issue is easier to see than the wording. A commitment about a vendor's output addresses what the vendor generated. Code a developer copies from another repository, a package, a forum answer or a document is supplied by the user. It was not generated by the assistant, so a commitment framed around suggestions is unlikely to extend to it unless the contract says so explicitly. The question to put to the vendor and to counsel is whether the text addresses user-supplied code at all.

The same logic applies to filters. A duplicate or public-code matching filter applied to suggestions evaluates what the assistant emits. Code that reaches a file by another route never passes through that check. A filter can be a useful condition of indemnity and still say nothing about a paste.

How MPL 2.0 file-level obligations are triggered

MPL 2.0 is generally described as file-level copyleft. The obligations attach to files that contain MPL-licensed code, not to the entire program. Where such a file is modified and the software is distributed, the licence generally requires the source of that file to remain available under the same terms. Separate files in the same product can usually stay under proprietary terms.

That is why a paste matters. If a developer places MPL-licensed code into an existing proprietary source file, that file now contains covered code. The file, rather than the product, becomes the unit where disclosure obligations may arise, and the proprietary logic already in the file is exposed with it. Placing the same code in its own file, with its notices intact, produces a different position. Strong copyleft licences such as the GPL typically reach further, towards the combined work, which is why file-level copyleft is often called weaker. Weaker still carries real obligations, and they are hard to manage if nobody knows the code is there.

Whether a particular file is affected, and what must be disclosed, is a legal determination. Engineering teams can supply the facts that counsel needs: which file, what was introduced, by whom, when, and whether the product was distributed.

Controls at the point of code entry

NIST's secure development profile for generative AI makes no distinction between human-written and AI-generated source code, because all source code should be evaluated before use. The practical consequence is that a control scoped only to assistant suggestions does not match the principle. Pasted code needs the same coverage, and so does code that arrives by any other route.

Provenance is the foundation. NIST's draft SSDF revision defines it as the chronology of the origin, development, ownership, location and changes to a component, and notes it may include the personnel and processes that interacted with it. For a snippet, that means a record of where it came from, who or what introduced it, and what licence and security context attaches to it. SSDF v1.1 also gives examples that support the audit trail: storing code in access-restricted repositories, commit signing, and code owner review and approval of changes made by others.

Review and analysis form the second layer. SSDF practice PW.7.2 calls for code review or code analysis against organizational standards, with all discovered issues recorded and triaged, and cites automated static analysis as an example. NIST frames this around vulnerabilities. Extending the same review gate to licence and origin risk is an organizational decision, not NIST's text, but the gate before merge is a natural place to hold a licence-risk finding for a human decision.

Where runtime enforcement fits

Trussed enforces policy in the execution path of coding assistants, at the level of individual interactions and tool calls. Its code provenance covers the origin, licence and security context of code. When an interaction involves code with a licence-risk signal, policy can allow it, redact it, block it, or escalate it for human approval. The decision is enforced at runtime, not reviewed after the fact, and the enforcement produces audit-ready evidence of what was detected and what was decided.

This has limits that matter for scoping. Enforcement in the assistant path covers what passes through that path. Code pasted directly into an editor, outside any assistant interaction, still needs the repository-stage controls described above, such as review gates and automated analysis before merge. The two layers complement each other, and neither substitutes for counsel's view on a specific file.