When GitHub launched Copilot for individual developers in 2021, it was trained on public GitHub repositories. The model saw billions of lines of code and learned patterns from all of it. That created an immediate question that developers and their employers started asking out loud: if Copilot trained on public code, could it reproduce that code in suggestions? Could it leak a company's private code if that code was in the training set?
The private code concern turned out to be largely a misunderstanding — Copilot's training data was public repos, not private ones. But a related concern was real: Copilot could sometimes reproduce verbatim snippets from its training data, including code under restrictive open source licenses. A developer at a company might unknowingly accept a suggestion that was a near-exact copy of GPL-licensed code, creating a licensing liability for their employer.
By 2022–2023, GitHub's enterprise sales pipeline was stalling on three questions: training data, data isolation, and auditability. The company had to build actual answers to all three before Fortune 500 security teams would approve the tool.
"We need to know that our code isn't training a competitor's AI." — The sentence GitHub's enterprise sales team heard on almost every deal in 2022.
It became the core product requirement for Copilot for Business.
GitHub ended up with a three-tier product structure, each with different security properties. If you're evaluating Copilot for your organization or building security policies around it, the differences between these tiers matter a lot — they're not just feature tiers.
The gap between Individual and Business is bigger than the $4/month price difference suggests. The training data commitment and data isolation are the core enterprise requirements.
GitHub's answer to the "can Copilot reproduce licensed code?" concern was the duplication detection filter — a real-time check that compares suggestions against a database of known public code before surfacing them to the developer.
When Copilot generates a suggestion, it's compared against a corpus of public code from GitHub. If the suggestion is a verbatim or near-verbatim match to any public repository — meaning it could be reproducing code under an unknown or restrictive license — the suggestion is blocked. A different suggestion is generated instead.
In practice the filter fires infrequently — common patterns like standard library usage are generic enough that no copyright applies. But for longer, more distinctive code blocks — particularly utility functions, algorithm implementations, or configuration patterns that are common in specific domains — the filter provides meaningful protection.
IP Indemnification
GitHub went further with Copilot Enterprise: they offer IP indemnification for content generated by Copilot in business and enterprise contexts. If a customer faces a copyright claim over Copilot-generated code, GitHub will defend them. This is the signal that GitHub is confident enough in the duplication filter to put commercial liability behind it.
One of the most practically valuable controls GitHub built was a secrets detection layer integrated directly into Copilot's suggestion pipeline. It works separately from — and in addition to — GitHub's existing secret scanning feature.
GitHub Secret Scanning
Scans code already committed to a repository. Finds secrets that made it into git history. Sends alerts. This is reactive — it catches things after they happen.
Copilot Secrets Prevention
Operates on Copilot suggestions before the developer ever sees or accepts them. If Copilot generates code containing a pattern matching a known secret type — AWS access keys, GitHub personal access tokens, OpenAI API keys, Stripe live keys, and hundreds of others — the suggestion is blocked. Proactive, not reactive.
The secrets prevention layer matters because Copilot's training data includes code where developers wrote secrets as placeholders — patterns like const API_KEY = "sk-..." are common enough that Copilot had a tendency to reproduce similar patterns in suggestions. The prevention layer specifically addresses this failure mode.
Here's where the story gets more honest. GitHub has built real, meaningful controls around licensing, secrets, and data isolation. There's a different problem they haven't solved: Copilot still suggests insecure code.
A study by Stanford and New York University published in 2022 showed that developers using GitHub Copilot were significantly more likely to introduce security vulnerabilities than developers not using it — in some task categories, Copilot-assisted developers wrote insecure code 40% of the time. A follow-up study in 2023 tested Copilot on 89 scenarios aligned to the OWASP Top 10 and found it suggested vulnerable code in the majority of cases.
Why This Happens
Copilot is a coding assistant, not a security scanner. It generates code that looks syntactically and semantically correct. "Correct" and "secure" are different properties. A SQL query that concatenates user input compiles fine. An authentication bypass using a truthy JWT evaluation runs without errors. Copilot has no threat model — it has a code completion model. Filtering secrets prevents one specific class of mistake. It doesn't prevent SQL injection, broken access control, or insecure output handling.
This is the gap that tools like Custodia exist to fill. You can deploy Copilot with all of GitHub's enterprise controls enabled — data isolation, secrets prevention, audit logging, duplication filtering — and still ship vulnerable code because the security checks that matter for application security happen at the scan layer, not the suggestion layer.
If you're responsible for securing an organization that's deploying GitHub Copilot, here's the practical checklist:
GitHub's enterprise security architecture for Copilot is genuinely thoughtful. The data isolation model is real. The secrets prevention layer addresses a specific high-frequency failure mode. The audit logging gives security teams visibility they didn't have before. The IP indemnification shows actual commercial confidence in the filtering.
What it can't do — what no code generation tool can do by design — is understand your application's threat model. It doesn't know that this particular endpoint requires authentication. It doesn't know that this particular input is attacker-controlled and needs to be sanitized. It doesn't know that your application stores PII and this logging call could expose it.
That's not a criticism of Copilot — it's a description of what code completion is not. The security controls that matter for that layer — the application security layer — have to exist in your process, not in the tool that generates the code.
OWASP Top 10 · OWASP LLM Top 10 · Broken access control · SQL injection · Insecure output handling. One scan after every Copilot-assisted build.