GitHub Copilot Duplicate Detection Filter and Indemnity Coverage

What the duplicate detection filter is, and what it is not

The duplicate detection filter, also described as the public code matching filter, is a Copilot setting aimed at suggestions that match public code. Its purpose is to reduce the chance that generated code reproduces existing public code without the developer knowing.

It helps to be precise about its scope. It is an output control applied by the vendor to suggestions. Output filtering is an accepted mitigation category in generative AI security guidance, including OWASP's LLM guidance, but that guidance is generic. It says nothing about how Copilot's filter matches code or what it guarantees. Treat the filter as one control that reduces a specific risk, not as a determination that code is free of licence, provenance or security concerns.

That distinction matters for indemnity. A filter reduces exposure. An indemnity allocates the consequences if exposure materialises. They are separate mechanisms, and the second may depend on the first being configured in a particular way.

How the filter relates to indemnity conditions

Vendor indemnity commitments for AI-generated output are generally conditional. When a condition names a configuration such as the duplicate detection filter, the practical question is not whether the vendor offers an indemnity but whether your deployment meets every stated condition at the time code was accepted.

Security engineers should separate three layers when reading the terms. The first is what the text states: which products and plans are covered, which settings must be enabled, and what notice or claim steps apply. The second is interpretation: what a condition means for a mixed fleet of plans, for developers using personal accounts, or for a setting changed temporarily. The third is evidence: what you can later produce to show the condition was met.

The first layer is read from the current published terms and recorded with the version and date reviewed. The second layer belongs to counsel. This guide makes no legal claims and does not interpret any specific clause. Its purpose is to make the third layer something you can build.

Configuration levels and the questions each one raises

Copilot settings can be managed at more than one level. For each level, the decision is who controls the value and whether a lower level can override a higher one. Settle these questions in writing before relying on the filter as an indemnity control.

• Individual: Can a developer change the filter on their own account? If so, any developer using an unmanaged account sits outside your control.
• Organization: Can an organization owner set the value for all members, and can members still change it?
• Enterprise: Can an enterprise owner set a policy that organizations cannot override, and does it apply to every plan in use?
• Plan scope: Does the indemnity apply to every Copilot plan you have deployed, or only to specific ones?

Why a setting is not evidence

A console toggle tells you the current state. An indemnity dispute, an audit or a legal hold asks about a past state: was the filter enabled when this code was suggested and accepted, and who could have changed it in between?

Answering that requires a history of the setting with timestamps and the actor who changed it, retained for a period that matches your exposure. Any audit log data the vendor provides should be tested against this requirement rather than assumed to meet it. Check whether it records changes to this specific setting, how far back it goes, and whether you can export it.

Even a complete configuration history leaves a second gap. It shows policy intent at the platform level, not the individual interaction. It does not show which suggestion was accepted, whether it was reviewed, what its origin and licence context were, or what happened to it downstream. Teams that need that record must generate it outside the vendor console, at a layer they control.

This is also where assumption turns into risk. A team that enables the filter, never records it, and cannot show who could change it may believe it has coverage it cannot substantiate.

Where runtime enforcement fits alongside the vendor control

The filter is one control among several. Code provenance, licence and security context of generated code, and policy enforcement on the coding assistant itself address risks the filter does not. Frameworks such as NIST SP 800-218 and the generative AI community profile SP 800-218A are useful reference points for mapping these practices to secure development.

Trussed addresses the runtime layer. It enforces policy in the execution path for coding assistants, with allow, redact and block outcomes applied to individual interactions and tool calls, and it produces audit-ready evidence from that enforcement, including code provenance covering the origin, licence and security context of code. That evidence is generated at runtime, not reconstructed after the fact. It complements the vendor's setting and does not replace it, and it does not change what the indemnity terms require.

Whether you use Trussed or another approach, the design principle is the same. Rely on the vendor for the vendor-side control, and keep your own durable record of what was allowed and what happened. Confirm with counsel and the vendor which records they would accept in support of a claim.