Enforcing GitHub Copilot's public code filter across every developer seat

What the native setting does and does not do

GitHub Copilot's public code filter, also referred to as the duplication detection setting, is a policy control intended to stop Copilot from offering suggestions that match public code. It is a platform-side setting. You configure it, and the platform applies it. You do not observe it operating.

Two consequences follow. First, the setting tells you the intended state, not what happened in a particular developer session. Second, any filter that depends on matching has finite coverage. OWASP guidance on LLM filtering notes that keyword and fuzzy-matching filters can be bypassed or produce errors, and recommends treating model output as untrusted. That guidance is written for prompt injection rather than for Copilot, but the principle carries over: a filter is one control among several, not a guarantee.

For security engineers, this means two separate questions. Is the setting configured correctly on every seat? And can you show, if asked, what the control did? The first is a configuration task. The second is an evidence task, and the native setting alone does not complete it.

Where the setting is managed and why precedence matters

The public code matching setting is managed through enterprise, organization and individual-level policy. Each level is a place where the value could differ from what you intended. A setting that looks correct in one organization says nothing about the others.

The harder case is a developer who holds Copilot seats through more than one organization. If those organizations have configured the setting differently, the value that applies to that developer depends on how policy resolves across them. Do not infer it from any single organization's configuration. Determine the effective value per seat, record it, and treat any seat where the effective value differs from your standard as an exception to resolve.

Where your plan lets you set the policy at enterprise level, doing so reduces the number of places a different value can be introduced. It does not remove the need to verify, because seat assignments and organization membership change over time.

A stepwise approach to configuring, verifying and sustaining enforcement

The sequence below separates configuration from verification, because a setting that has been applied is not the same as a setting that has been confirmed.

• 1. Inventory seats and organizations: List every Copilot seat, the organization or organizations that assign it, and the owner. Seats assigned through multiple organizations are flagged for closer review.
• 2. Define the target value: Record the required state of the public code setting as a written standard, with the approver and date.
• 3. Configure at the highest available level: Apply the setting at enterprise level where possible, then at each organization, so that fewer individual exceptions exist.
• 4. Confirm the effective value per seat: Check what applies to each seat, not what is set on each organization. Capture the result with a timestamp.
• 5. Test the behaviour: Run a defined test in a representative environment and keep the method and outcome with your records.
• 6. Monitor and re-verify: Review policy changes, new seats and organization membership changes on a schedule, and repeat steps 4 and 5 after material changes.

The gap between configuration and evidence

Even when every seat is correctly configured, an auditor may ask for more than a screenshot of a settings page. Platform configuration shows the state of a policy. It does not by itself show what individual developers received, how a policy change was applied over time, or what licence and origin context applies to code that a developer accepted.

This gap is easy to miss because the configuration task feels complete. The distinction is between a control being set and a control being demonstrably enforced on each interaction. Records of configuration changes help you show when the policy was altered and by whom. They do not show the outcome of any single suggestion.

Residual risk also remains for accepted code. A matching filter reduces one category of exposure, but code that reaches a repository still carries questions of origin, licence and security that need their own checks. Secure development guidance such as NIST's SSDF points the same way: tie changes to accountable individual accounts, require review of changes, and test before release. Treat AI-generated code as input that needs those downstream checks, whatever the filter reported.

Adding enforcement and provenance in the execution path

Native settings and runtime enforcement answer different questions. The native setting configures what the platform should do. Enforcement in the execution path applies policy to individual interactions as they happen and records what occurred. OWASP guidance supports this layering: enforce controls at trust boundaries and treat model output as untrusted, rather than relying on a single filter.

Trussed provides policy enforcement in the execution path for coding assistants, among other AI systems. Policy is enforced at runtime, not reviewed after the fact, and the available actions are allow, redact and block, with rate limiting and escalation for human approval also available. The scope is individual interactions and tool calls.

Trussed also provides code provenance, covering the origin, licence and security context of code. This addresses the question the native setting leaves open for accepted code. Because the audit-ready evidence is generated by enforcement itself, it reflects what the policy did on each interaction. It is not assembled afterwards from configuration records. Trussed deploys self-managed in the customer cloud, with configurable retention and data residency, which matters for regulated enterprise teams with data location requirements.

This complements the native setting rather than replacing it. Keep the public code filter configured and verified, and use runtime enforcement and provenance to produce the evidence that configuration cannot.