Copilot Indemnity When Claude Code Edits the Same Code

Why the question arises

Many engineering teams now run more than one AI coding assistant against the same repositories. A single file can contain lines suggested by Copilot that Claude Code later rewrote, or the reverse. Each vendor's IP indemnity commitment is tied to conditions, and those conditions were written with a single tool in mind.

The practical difficulty is evidential. Legal, security and engineering teams are asked whether a mixed-origin change is still covered, what licence exposure it carries and what to tell an auditor. Commit history shows who committed a change and when. It does not show which tool produced or altered which lines. Without that, nobody can even frame the coverage question precisely, let alone answer it.

Which Copilot indemnity conditions are relevant

Treat this as a conditions problem. Vendor indemnity commitments depend on factors such as the product and plan in use, whether required filters are enabled, and whether the output was used unmodified. Each is a fact about how code was generated, so each can be checked against a record, provided one exists.

For a Copilot commitment, the relevant questions are these. Was the code generated through a covered Copilot product and plan, by a licensed user? Were the required filters enabled at the time of generation? Does the contract wording address output that has since been modified or combined with other content? The first two are settings and entitlement facts that can be evidenced. The third is a matter of contract wording.

NIST's generative AI profile, in its draft form, advises organisations to update third-party contracts, service agreements and warranties to address generative AI risks, and notes that these may include GAI-specific indemnity clauses. Reading the current published Copilot terms against your actual usage is therefore a contract-governance task, not a tooling task.

Where a second assistant creates ambiguity

When Claude Code edits Copilot output, several questions open up that engineering cannot settle alone. Does a modification by another tool count as modification for the purposes of the unmodified-output condition? Does the answer change with the size of the edit, or with whether the original suggestion is still recognisable? Does a second vendor's own terms apply to the edited lines, and how do the two sets of terms interact?

These are interpretation questions for legal counsel working from the vendors' contract text. This guide does not answer them, and no log or scanner will. The useful engineering contribution is to make the questions answerable by showing exactly what happened to each change: the sequence of tools, the settings in force at each step, and the state of the code before and after each edit.

What common data sources can and cannot show

Teams often try to answer the question from data they already have. Each source helps, but none covers the full evidentiary need on its own.

• Git history: Records commit author, time and diff. It does not record which tool produced a line, and squashes or rebases can collapse intermediate edits.
• IDE telemetry: May show assistant activity in a session, depending on configuration. It is tied to the developer's environment and is not a durable record of what reached the repository.
• Assistant-side logs: Each vendor holds its own records in its own format. Correlating two vendors' records against one file is manual work, and retention is set by the vendor.
• Provenance recorded at generation: One event per generation or modification, with tool, user, time, settings and context. This is the only source designed for the question being asked.

Provenance has to be recorded, not reconstructed

NIST's generative AI profile includes an action to use digital content transparency solutions that document each instance where content is generated, modified or shared, with the stated aims of a tamper-proof history, transparency and traceability. Applied to coding assistants, a multi-assistant file should carry a chain of events rather than a single attribution. Copilot generated this block, Claude Code modified it at a later time, and a developer then edited it.

A useful event record for a coding assistant interaction includes the tool and plan, the user identity, a timestamp, the policy settings in force, the policy decision taken, and references to the resulting licence and security scan results. The record should be tamper-evident and retained for the audit period, because an indemnity or licence review may come long after the change shipped.

Reconstruction after the fact depends on inference from commit patterns and on vendor logs that may no longer exist. Evidence captured at the moment of generation does not have that weakness.

Defining a policy for multi-assistant environments

A workable policy sets out what is permitted before any code is generated, and it is enforced rather than only documented.

• Maintain an approved-tool list: Name each permitted assistant, plan and configuration, and block use of anything else on managed repositories.
• Map contract terms to usage: For each approved assistant, have legal record the indemnity conditions and how your actual configuration relates to them.
• Require generation-time records: Every generation or modification by any assistant produces an event, so mixed-origin edits form a traceable chain.
• Link licence and security context: Tie each event to licence and security scan results so reviewers see origin, licence and security context together.
• Define escalation triggers in advance: Decide which events need human approval, such as a second assistant modifying code from an indemnity-relevant tool, and keep the decision with the record.
• Set retention to the audit period: Make records tamper-evident and retain them for as long as an audit or legal review may need them.

Enforcing policy in the execution path

A policy document does not stop a developer from enabling a second assistant or from sending sensitive context to a tool. Enforcement has to sit in the interaction path of the assistant. NIST's agentic AI security material lists input hardening, through intent firewalls and prompt sanitisation, among its key mitigations, which places controls in the path of the AI system rather than after its output lands.

Trussed enforces policy in the execution path of coding assistants, at the level of individual interactions and tool calls. Each interaction can be allowed, redacted, blocked or escalated for human approval, and enforcement happens at runtime, not in a review after the fact. Trussed also records code provenance, covering the origin, licence and security context of code, and the enforcement itself produces audit-ready evidence for regulated enterprises. It can be self-managed in the customer's cloud, with configurable retention and data residency.

Trussed does not preserve, extend or confirm any vendor indemnity. Its role is narrower: to supply the evidence that legal reviewers and auditors need when they assess coverage, licence exposure and audit responses.