GitHub Copilot Security Risks: What Each Plan Does and Does Not Cover

GitHub Copilot can be used safely as a coding assistant when its access and output are reviewed like any other code change. Its plan controls reduce specific privacy, policy, and intellectual-property risks. They do not establish that the generated application is secure.

Short answer:

• Copilot is safe to use when its output is reviewed like any other code change.
• Individual plans (Free, Pro, Pro+, and Max) may use your interactions for model training unless you opt out, a policy in force since 24 April 2026.
• Business and Enterprise exclude customer data from model training and add content exclusion and IP indemnity.
• Content exclusion does not work in Agent mode, Copilot CLI, or the cloud agent.
• No plan setting can tell you whether the app you shipped is secure.

The plan distinction matters. GitHub may use interactions from Copilot Free, Pro, Pro+, and Max accounts to train and improve AI models unless the account holder opts out. GitHub says Business and Enterprise customer data is excluded from model training. Organization plans also add policy management, content exclusion, and IP indemnity, although each control has boundaries that are easy to miss.

The six GitHub Copilot security risks that matter

Six risks come up repeatedly. Only some of them have a plan setting attached.

1. Insecure suggestions. Copilot writes code that compiles and reads as ordinary while missing an authorization check, a signature check, or input validation. Five independent studies find the same thing from different angles, collected in does GitHub Copilot generate secure code below.
2. Secrets leaking into repositories. Copilot-enabled repositories carry hardcoded keys at a higher rate than the public baseline, and once a key reaches Git history, deleting the line does not remove it. See what GitHub Copilot security settings cannot see in a shipped app.
3. Prompt injection through repository content. An agent that reads issues, README files, or dependency manifests is reading text an outsider can write, and that text can carry instructions. No plan setting covers it. See prompt injection.
4. Hallucinated or typosquatted packages. An assistant can name an import for a package that does not exist, and a squatter can register that name and wait for install commands. See hallucinated and typosquatted packages.
5. Public-code matches and license exposure. A suggestion that reproduces public code can reproduce code under a copyleft license, which is a legal problem rather than a technical one. The filter, its threshold, and what code references show are covered under what GitHub Copilot security settings cannot see.
6. Agent surfaces that reach past content exclusion. The exclusion list an administrator configures does not apply in Agent mode, Copilot CLI, or the cloud agent. See what content exclusion protects, and what it misses.

Risks 1 through 4 are not settings problems. No checkbox on any Copilot plan removes them.

What each Copilot plan covers: Free, Pro, Pro+, Max, Business, Enterprise

The split is one line. The four individual plans give you a training opt-out and the public-code filter. The two organization plans add content exclusion, policy management, and IP indemnity. Neither side inspects the application you ship.

The training row carries a date. GitHub’s policy documentation says that starting on 24 April 2026, a Copilot Free, Pro, Pro+, or Max plan may have its interactions used to train and improve AI models, and that the opt-out is a dropdown in personal Copilot settings. The same page says GitHub does not use Copilot Business or Copilot Enterprise customer data to train AI models.

The public-code filter with code referencing is listed on every plan, individual ones included, so the license check does not require an organization seat. Content exclusion does: GitHub documents it for the Business and Enterprise plans only. Policy management is the same story, and it is the surface where an administrator controls access, preview features, models, and, as of August 2026, whether MCP servers can be used at all.

Read the table for what is missing from it. Four of the six risks above have no row here. Insecure suggestions, secrets already sitting in the repository, prompt injection through content an agent reads, and hallucinated package names are identical on Free and on Enterprise, because no plan has a setting for any of them.

Does GitHub Copilot train on private code?

For individual Copilot plans, GitHub’s current policy covers interaction data including inputs, outputs, code snippets, and associated context. Since 24 April 2026, GitHub may use that data for model training unless you disable the training setting. The control is under personal Copilot settings and applies to Free, Pro, Pro+, and Max accounts. GitHub documents the setting and opt-out procedure.

GitHub says it does not use Copilot Business or Enterprise customer data to train its models. Those plans are covered by the organization’s agreement instead of a personal training preference.

Retention depends on the feature and plan. GitHub’s Business and Enterprise retention FAQ says IDE prompts and suggestions for chat and code completion are not retained, while engagement data is kept for two years. For other access on those organization plans, including GitHub.com, mobile, and CLI, prompts and suggestions are retained for 28 days by default. Newer features can create their own stored artifacts: Copilot Memory, for example, can retain repository facts and user preferences until they go unused for 28 days.

GitHub’s current plan FAQ is also the source for the indemnity row above: it lists the protection for Business and Enterprise customers using qualifying unmodified suggestions when public-code filtering is enabled. The applicable agreement controls any actual claim.

Using a personal Copilot license for work or client code

If work code is being sent through a personal Copilot subscription, the employer’s organization controls do not follow that account. Check which entity supplies the active license before assuming a company policy applies.

The gap is widest on the free tier. A Free, Pro, Pro+, or Max license carries the personal training preference and the public-code filter, and nothing organizational: no content exclusion, no organization policy control, and no IP indemnity. Company code opened in that editor is governed by your own account settings, not by whatever your employer signed. Client work has the same shape. A client’s agreement with GitHub covers the licenses that client pays for. It does not reach a personal subscription you happen to have open while working on their repository.

For a private repository, make the decision from three facts rather than the repository’s visibility label alone:

1. Billing entity: is the active license personal or organization-managed?
2. Surface: are you using IDE completion, GitHub.com chat, CLI, or an agent? Retention and exclusion behavior can differ.
3. Reach: can that surface only suggest text, or can it read files, run commands, and change a repository?

A private repository can still send context to Copilot, and an organization license can still expose excluded content to an unsupported agent surface. Plan and mode need to be checked together.

What content exclusion protects, and what it misses

Content exclusion lets administrators identify files and paths that Copilot should ignore. In supported inline-completion and chat surfaces, an excluded file stops supplying suggestion context and does not receive inline suggestions.

The limitation changes the security decision. GitHub’s current content-exclusion documentation says exclusions are not supported in Edit and Agent modes in IDEs. GitHub’s configuration guide also says GitHub Copilot CLI and Agent mode in Copilot Chat in IDEs do not support content exclusion. As of August 2026, no GitHub content-exclusion page documents support for the cloud agent either.

A repository-level exclusion is just a list of path patterns. In the repository’s Copilot settings it takes this shape:

# Repository-level content exclusion.
# One path pattern per line, quoted, each line starting with a dash.
- '/.env'
- '/config/secrets.yaml'
- '/scripts/**'
- '*.pem'
# Reminder: these entries have no effect in Agent mode,
# Copilot CLI, or the cloud agent.

Patterns use fnmatch matching and are case insensitive, and a leading slash anchors the pattern to the repository root. The configuration guide linked above documents the format and names the surfaces that ignore it.

Even supported exclusions are not a perfect information boundary. GitHub warns that the IDE may indirectly provide semantic information such as symbol types, hover definitions, or build configuration. Exclusions also do not currently apply to symbolic links or repositories on remote filesystems.

Use content exclusion to reduce ordinary context exposure on organization plans. Keep credentials out of version-controlled files and limit the permissions available to agentic modes, because the exclusion policy does not cover every surface that can act on the codebase.

MCP servers and the Copilot CLI: the surfaces content exclusion does not reach

Content exclusion is a completion and chat control, and MCP widens the gap rather than closing it. GitHub’s MCP documentation says MCP works across all major Copilot surfaces: IDEs, GitHub Copilot CLI, the GitHub Copilot app, and agents on GitHub.com. As of August 2026, neither content-exclusion page documents any interaction between an exclusion list and a connected MCP server. An exclusion list is not a boundary you can assume a server respects.

Three facts decide how much that matters on a given setup.

• Whether MCP is available at all. GitHub documents an organization and enterprise policy named MCP servers in Copilot, disabled by default, for Copilot Business and Copilot Enterprise subscriptions. Individual plans have no equivalent administrator switch.
• Whether that policy reaches the surface you use. GitHub’s CLI documentation says GitHub Copilot CLI cannot currently support the MCP servers in Copilot organization policy, which is the control that decides whether MCP servers can be used at all. An organization can turn MCP off and still have it working in a terminal.
• What a connected server may do. For the cloud agent, GitHub says it does not have access to write MCP server tools by default, and that the cloud agent and Copilot code review support MCP tools only, not resources or prompts. Repository administrators configure which servers a repository uses.

GitHub’s own guidance is direct about where the responsibility lands. Its agent documentation says developers must ensure connected MCP servers are trustworthy, because malicious or misconfigured servers can introduce harmful behavior or expose sensitive data, and to review the tools and data each server exposes before connecting it. That is a supply-chain decision about who gets into the session, not a Copilot setting.

The CLI carries the same shape locally. GitHub documents that the first time Copilot needs a tool that could modify or execute a file, such as touch, chmod, node, or sed, it asks whether to allow it, and that --allow-all-tools removes the prompt. With that option on, GitHub’s documentation says Copilot has the same access you do to files on your computer and can run any shell command you can run without prior approval. The same page says to launch GitHub Copilot CLI only from directories you trust.

So the control on these surfaces is not a checkbox. Decide which servers connect, which directory the session starts in, and which token that session holds, then leave the approval prompt on instead of trading it for speed.

Prompt injection: the risk no plan setting covers

Prompt injection is simple to describe. An agent that reads issues, pull request comments, README files, dependency manifests, or fetched web pages is reading text that someone outside your team can write. A model does not reliably separate content it was asked to look at from instructions it was given, so text placed in that content can steer the agent.

This compounds with the exclusion gap above. Content exclusion is unsupported in Agent mode and Copilot CLI, which are precisely the surfaces that read files and run commands. The setting that would narrow what an agent sees is switched off in the place an injected instruction would use it. An attacker does not need to break the model. They need one file the agent reads and a session where the agent holds a useful token.

Two controls actually help.

• Narrow the credential. Give an agent session the smallest token that completes the task, scoped to one repository, with no production database or cloud access. If an injected instruction lands, this decides how far it travels.
• Keep a human gate. An agent-written pull request should require review and pass the same checks as a human one. Read the diff, not the agent’s summary of the diff.

Neither control is a Copilot setting. Both are repository and credential decisions that sit outside the plan entirely.

Does GitHub Copilot generate secure code?

Copilot can generate secure code, insecure code, or a mixture of both. GitHub ships real tooling against the second case: Copilot Autofix generates fix suggestions for CodeQL code scanning alerts on pull requests and on the default branch. Autofix and code scanning find known vulnerable patterns in code that already exists, which is a different job from proving that an endpoint enforces ownership, a webhook verifies its signature, or a payment decision happens on the server. GitHub’s own documentation adds that an Autofix suggestion can vary between attempts, can be syntactically correct while changing what the program means, and can fail to remediate the vulnerability or introduce a new one.

Five independent measurements, from controlled studies to surveys to live-repository scans, show why generated output still needs verification:

The first study is often repeated as “40% of Copilot code is vulnerable.” Its age and design do not support that claim for current Copilot. It shows that the 2021 system repeatedly produced vulnerable patterns in deliberately security-relevant tasks. The 2026 study supplies a newer, narrower result: assistance improved whether the code worked, while secure use of the tested APIs did not improve significantly. Read the whole table top to bottom and one pattern holds across five years of independent teams: the measured problem has not gone away, and developer confidence has not moved down to meet it.

Hallucinated and typosquatted packages

An assistant can name a package that does not exist. An analysis of 576,000 generated code samples across 16 models found package hallucination rates of at least 5.2% for commercial models and 21.7% for open-source models, and catalogued 205,474 unique invented package names (Spracklen et al., “We Have a Package for You!”). The paper calls this a package confusion attack, because a name a model invents is a name somebody else can register.

That is the whole hazard. The assistant prints an install command, you run it, and whatever sits on the registry under that invented name is now running in your build. The check takes about thirty seconds: confirm the package exists, has real download history and a repository behind it, and is the one the official documentation names. Do it before running the install, not after.

What GitHub Copilot security settings cannot see in a shipped app

The GitGuardian result is often quoted as “repositories using Copilot leak 40% more secrets.” The arithmetic holds and the framing does not. 6.4% against 4.6% is a relative lift on a small base, so the absolute difference is under two percentage points. The plainer number is the useful one: roughly one repository in sixteen carries a live secret, whether or not Copilot was involved.

That one-in-sixteen rate is a leak rate, not a story, and the fixed June and July 2026 AxonBuild research cohort shows what it looks like inside an actual codebase. 6 of 21 third-party AI-built apps shipped a real secret. Three secrets remained permanently in git history, and one was delivered to every visitor’s browser. I found that last one in about ten seconds, no digging through git history required: I opened the config file the app loaded with a plain <script> tag and read Authorization: Bearer followed by the owner’s own API key, sitting in plain text, deployed. Nobody stole it. It just shipped that way, because a client-only app calling a paid API has nowhere else to put the key once there’s no server to hide it behind. Those are historical cohort findings with their denominator and method documented.

A leaked key is the cost of a feature that has to work without a server to hide behind. Nothing in the build step ever asks where that boundary should sit, on any tool, on any plan.

The cohort did not record which assistant produced each line, so it cannot assign those six failures to Copilot. It does show the boundary a plan page cannot assess. A model-training opt-out does not stop a browser bundle from containing a live key, and IP indemnity does not decide whether one signed-in customer can request another customer’s row.

GitHub’s public-code filter addresses a separate risk. Copilot compares suggestions with public code, using a duplication-detection threshold of about 65 lexemes, roughly 150 characters of matching code, and can block a match or attach code references, depending on policy. This is also the license question. A suggestion that matches public code can match code published under a copyleft license, and code references show the matched repository and its license, so the call can be made before the suggestion is accepted. GitHub notes that altered suggestions are not checked for public-code matches, which also explains why indemnity is tied to qualifying unmodified suggestions with filtering enabled.

The broader pattern is covered in why AI coding tools ship security holes. Generated code is useful input to a development process. Security comes from the controls that review, test, and constrain what reaches production.

GitHub Copilot security best practices: how to mitigate the risks

A scanner finding can identify a known vulnerable pattern. Silent authorization and business-logic failures need behavior tests, which is why a request that returns 200 can still be wrong.

Common questions about GitHub Copilot security

Is GitHub Copilot secure?

Copilot’s own controls are documented and configurable; the code it helps you write is covered by none of them. GitHub publishes a training opt-out on individual plans, model-training exclusion, content exclusion, policy management, and IP indemnity on Business and Enterprise, and a public-code filter on every plan. Those settings decide how GitHub handles your data. Whether the app you shipped checks that a request belongs to the account making it, verifies a webhook signature, or keeps its API key off the browser is decided by the code and the review process behind it.

Is GitHub Copilot safe?

Yes, under two conditions: review its output like any other code change, and match the plan to whose code you are opening. The risk it adds is not that it takes your code. It is that it writes plausible code quickly and that its agent surfaces can edit files and run commands. Read the diff rather than the summary of the diff, keep credentials out of tracked files, and check whether the active license is yours or your employer’s before opening work code. This answer covers GitHub Copilot, the coding assistant. Microsoft 365 Copilot is a different product with its own terms.

Is GitHub Copilot a security risk?

It adds risk in four places, and no plan setting removes any of them. Insecure suggestions, secrets reaching a repository, prompt injection through content an agent reads, and invented package names behave the same on Free and on Enterprise. What a plan changes is data handling, license exposure, and access policy. Route generated changes through the same review, tests, and scanning as everything else and the added risk stays inside controls you already run.

Does GitHub Copilot Business protect my data privacy?

For model training, yes: GitHub states it does not use Copilot Business or Copilot Enterprise customer data to train AI models, and Business adds content exclusion and organization policy management on top. Retention is a separate question from training. GitHub’s plan documentation says IDE chat and code-completion prompts and suggestions are not retained, while prompts and suggestions from other access, including GitHub.com, mobile, and the CLI, are retained for 28 days by default, with engagement data kept for two years. Content exclusion is also not a complete boundary, since GitHub documents that it does not apply in Agent mode or GitHub Copilot CLI.

Is Copilot safe for confidential information?

GitHub Copilot is usable on confidential code under an organization plan with exclusions configured and tested, and it is never the right place for secrets. Business and Enterprise keep customer data out of model training and let administrators exclude files and paths, which is the closest control Copilot has to confidentiality. GitHub documents three limits on it: exclusion does not apply in Agent mode or GitHub Copilot CLI, the IDE can still supply semantic information such as type and hover definitions from an excluded file, and exclusions do not apply to symbolic links or repositories on remote filesystems. Credentials belong outside version-controlled files on every plan.

Is Copilot more secure than ChatGPT?

The comparison does not settle in general, because the exposure comes from placement rather than from the model. GitHub Copilot sits inside the repository, and in Agent mode and GitHub Copilot CLI it can edit files and run commands; a chat assistant carries that same exposure only once you connect it to your code the same way. What both come down to is the subscription and the agreement behind it, so the answerable version is which plan, on which surface, for whose code. On the GitHub side, individual plans may use interactions for model training unless you opt out, and Business and Enterprise are excluded from it.

Has GitHub Copilot had a security incident?

Yes, one significant disclosed vulnerability, since fixed. Researchers at Legit Security disclosed a Copilot Chat flaw they called CamoLeak, which they rated 9.6 critical, combining a hidden instruction placed in a pull request description with GitHub’s own Camo image proxy to pull content out of private repositories to an attacker-controlled destination, with no malicious code run by the victim. They report GitHub fixed it on 14 August 2025 by disabling image rendering in Copilot Chat. The shape is the part worth keeping: the payload was ordinary repository text, and the exit route was a trusted first-party domain.

Does GitHub Copilot store my private code?

Copilot sends code context to provide its features, and storage varies by feature and plan. For Business and Enterprise, GitHub says IDE prompts and suggestions for chat and completions are not retained; prompts and suggestions from other access, including GitHub.com, mobile, and CLI, are retained for 28 days by default. Optional features such as Copilot Memory have their own retention behavior. GitHub’s published organization-plan defaults should not be assumed to describe an individual plan.

Can I stop GitHub Copilot from training on my code?

Individual Free, Pro, Pro+, and Max users can disable the model-training setting in personal Copilot settings. GitHub says Business and Enterprise customer data is not used for model training, so organization users do not receive the personal opt-out control for that license.

Is the free version of GitHub Copilot safe for company code?

Treat it as a personal tool, not a company one. Copilot Free carries the individual training policy, so GitHub may use your interactions for model training unless you turn that setting off, and the plan has no organization content exclusion, no organization policy control, and no IP indemnity. If your employer holds a Copilot agreement, work under the license that agreement covers rather than your own account.

What percentage of Copilot’s suggested code has vulnerabilities?

About 40% in the most direct measurement on record, with survey data pointing the same way. NYU’s benchmark found about 40% of 1,689 generated programs contained an exploitable weakness, though it stress-tested the 2021 system on deliberately risky scenarios, so treat it as a ceiling marker rather than a current rate. Snyk’s late-2023 survey found just over half of developers saying AI suggestions introduce security issues at least sometimes, and the Stanford study found the confidence gap moving the wrong way: people trusted the code more, not less, once an assistant wrote it. No newer public benchmark has replaced the 40% figure with a current one.

Can GitHub Copilot leak secrets that are already in my repository?

Yes, in two ways. A secret sitting in a tracked file is ordinary context, so it can be read and reproduced in a suggestion unless that file is covered by content exclusion, which does not apply in Agent mode, Copilot CLI, or the cloud agent. Separately, an agent with write access can commit a secret it was handed during the session. Keep credentials out of version-controlled files and give agent sessions the narrowest token that still works.

Can GitHub Copilot suggest a package that does not exist?

Yes. Research across 576,000 generated code samples found package hallucination rates of at least 5.2% for commercial models and 21.7% for open-source models, with 205,474 unique invented package names. A name a model invents can be registered by someone else, so confirm that a package exists, has real download history, and is the one the official documentation names before installing it.

Does Copilot IP indemnity cover an individual plan?

No. GitHub lists IP indemnity on Business and Enterprise plans, not Free, Pro, Pro+, or Max. The published protection applies to qualifying unmodified suggestions when Copilot’s public-code filtering is enabled. Read the applicable agreement before treating that description as legal advice for a particular dispute.

Is GitHub Copilot safe enough for production code?

It can be part of a production development workflow. Require branch protection, automated checks, review, and behavior tests before generated changes reach users. The Copilot plan controls how GitHub processes data and manages access; production readiness depends on the application that was actually shipped.