GitHub Copilot now sits in editors for millions of developers, and the security research on what it actually suggests is no longer theoretical. A study published as arXiv 2311.11177 prompted Copilot with 900 code snippets pulled from GitHub and collected 8,127 suggestions in response; 2,702 of them — 33.2% — contained a hardcoded secret in valid format, and GitGuardian's follow-on analysis found at least 200 of those (7.4%) matched real, live credentials discoverable elsewhere on public GitHub. That means Copilot is doing two dangerous things at once: regurgitating secrets it memorized during training, and fabricating new, plausible-looking ones that pass a quick visual review. Separately, the licensing question is still working its way through federal court — Doe v. GitHub has been narrowed but not resolved, with an interlocutory appeal pending before the Ninth Circuit as of this writing. Neither problem is solved by banning AI assistants, which most engineering orgs have already decided isn't realistic. This post lays out concrete practices for licensing risk, secret leakage, and code review policy that let a team keep using Copilot-style tools without absorbing their worst failure modes.
Does using Copilot make your repository more likely to leak a secret?
The correlational data says yes. GitGuardian sampled roughly 20,000 repositories with Copilot enabled and found 6.4% contained at least one leaked secret, versus a 4.6% baseline rate across public GitHub generally — a roughly 40% relative increase. GitGuardian is careful to frame this as correlation, not proof that Copilot causes the leaks directly; a more likely mechanism is that Copilot-assisted teams ship code faster and generate more of it per developer-hour, and more code shipped faster means more chances for a stray API key or connection string to slip through review. The practical takeaway is the same either way: if your velocity is increasing because of an AI assistant, your secret-detection coverage needs to scale with it, not stay fixed at whatever sampling rate worked before adoption. Treat Copilot rollout as a trigger to re-audit secret scanning coverage, not just a productivity change.
Why does Copilot suggest secrets that look completely real?
Copilot suggests secrets that look real because large code-generation models are trained on public repositories that already contain both real, accidentally-committed credentials and syntactically correct placeholder patterns, and the model has no mechanism to distinguish "credential I should reproduce" from "credential I should refuse to reproduce." The arXiv 2311.11177 authors demonstrated this is not a rare edge case — over a third of the suggestions in their sample contained something matching a secret pattern (AWS-style keys, private key blocks, database connection strings), and the 7.4% verified-live rate shows the model isn't just generating well-formatted noise; it is capable of reproducing training-data secrets that are still valid. This matters for review policy: a human reviewer scanning a diff for logic errors has no strong visual cue that a hardcoded string is a genuine leaked key versus an obviously-fake placeholder, because Copilot's fabricated secrets are specifically well-formed enough to pass a glance. Detection has to happen mechanically, before merge, rather than relying on a reviewer's eye.
What is the actual status of the GitHub Copilot licensing lawsuit?
The lawsuit is real, narrowed, and unresolved — not dismissed and not a green light. In Doe v. GitHub (N.D. Cal.), Judge Jon Tigar dismissed most of the plaintiffs' claims in January 2024, including the DMCA §1202(b) claims, ruling that Copilot's output wasn't shown to be "identical enough" to the plaintiffs' source to establish the removal of copyright management information. What survived was narrower: breach-of-contract claims tied to open-source license violations and to selling licensed materials. The case was later stayed pending an interlocutory appeal to the Ninth Circuit (case No. 24-6136, accepted December 2024), which held oral argument in February 2026 with no final ruling issued as of this writing. Teams should not treat the January 2024 dismissal as proof Copilot output is legally clean — it's a partial narrowing of one plaintiff group's claims, not a determination that AI-suggested code carries no licensing risk. Until the appeal resolves, the safest posture is to treat AI-suggested code as licensing-risk-unknown by default and check it, the same way you'd check a copy-pasted Stack Overflow snippet.
What concrete steps reduce Copilot's licensing risk?
Turn on GitHub's built-in duplication filter — the "suggestions matching public code" setting blocks completions that closely match a public repository, which directly targets the scenario at the center of the litigation (Copilot reproducing licensed source verbatim). That filter is opt-in in some Copilot plans, so verify it's actually enabled in your organization's settings rather than assuming a default. Beyond the built-in filter, run license classification and policy enforcement on every merge the same way you would for a third-party dependency: Safeguard's license-compliance engine detects and classifies licenses (permissive, weak copyleft, strong copyleft) against a policy-as-code allow/block list, gating the build the moment a denied license expression appears in code or dependencies, which catches the case where an AI suggestion pulls in a GPL- or AGPL-licensed snippet or package your policy doesn't allow. Document your AI-assistant usage in engineering policy so a future audit or diligence review has a clear answer, rather than a discovery-time surprise.
What should a code review policy for AI-suggested code actually require?
A code review policy for AI-suggested code should require the same scrutiny you'd apply to an unreviewed external contribution, because that's functionally what it is — code from a source with no accountability for correctness, licensing, or security. Concretely: require the author (not just the reviewer) to flag which lines were AI-generated versus hand-written, since reviewers spend measurably less time scrutinizing code they believe a human already vetted; block merges automatically on any verified secret finding rather than relying on a reviewer to spot one; and treat AI-suggested dependency additions as new, unvetted supply-chain input requiring the same SCA and license check as a manually-added package. None of this requires slowing developers down if the checks are automated and run pre-merge — the goal is removing "trust the AI output" as an implicit default, replacing it with "verify the AI output" as a mechanical gate.
How Safeguard Helps
Safeguard's secrets-scanning pipeline is built for exactly the failure mode the arXiv 2311.11177 study documented: it scans source, git history, and build logs against 200+ issuer-specific patterns and then verifies each hit with a live, low-privilege API call to the issuer (AWS sts:GetCallerIdentity, GitHub /user, Stripe /v1/balance), so a Copilot-fabricated key that happens to be well-formatted but dead gets marked unverified while a genuinely live credential gets flagged Critical and routed through an automated revoke-rotate-purge playbook. A pre-push git hook (safeguard install-hook --hook pre-push) catches AI-suggested secrets before they ever leave a developer's machine. On the licensing side, Safeguard's license-compliance engine classifies every dependency and inline license declaration against a policy-as-code ruleset and blocks a PR the moment an AI suggestion introduces a denied license — whether that's a new package or a reproduced code block — giving teams a mechanical answer to a legal question that's still being litigated in court.