Is GitHub Copilot Safe for Private Repositories?

Is GitHub Copilot Safe for Private Repositories?Security, Code Review & Enterprise5Intermediate/github-copilot/security-enterprise/private-repositories/

This question arrives in every security review, and it is usually answered badly in both directions. “Yes, it’s fine, GitHub owns your code anyway” is not an analysis. “No, never, it trains on everything” has not been true for the plans most organisations use.

The useful answer is a description of the system, so that you can decide what your organisation is willing to accept.

Key takeaways

• Requests leave GitHub’s infrastructure for several model families. The protection is contractual, not a network boundary.
• GitHub states it does not train on Business or Enterprise customer data, and documents zero-retention arrangements with providers for GA features.
• The plan matters more than any setting. Individual plans carry different commitments from Business and Enterprise.
• Content exclusion is real and narrower than it sounds — it does not cover Edit and Agent modes.
• Agents and MCP widen the boundary past anything content exclusion governs.

What actually happens to a request

1. 1Your repositoryPrivate, on your machine or on GitHub.
2. 2The client selects contextOpen files, related files, and what you asked.
3. 3Copilot serviceGitHub's infrastructure.
4. 4Model providerProcessing happens on the provider's infrastructure.
5. 5ResponseReturned to your client.

Two things in that sequence do the work in a security review.

The client decides what context to send. Not the whole repository — the relevant part, which varies by surface and by what you have open. This is why “does Copilot upload my repository” is the wrong question: it sends context per request.

Processing happens on provider infrastructure. For several model families the request is handled outside GitHub’s own systems entirely.

Where models run

This is the fact most internal security documents get wrong, usually by omission. Requests do not stay within GitHub for every model. What protects them is a set of documented commitments — GitHub states zero-retention arrangements with providers for generally available features, with limited exceptions noted for beta and preview features, and states that it does not use Copilot Business or Copilot Enterprise customer data to train AI models.

What gets sent, and what does not

“Does Copilot see my whole repository” is the question underneath most of the anxiety, and the answer is more specific than yes or no.

Context is assembled per request. What goes into it depends on the surface and on what you are doing — the file you are editing, files the client judges related, the conversation so far, and whatever you explicitly attached. It is not an upload of the repository, and it is not only the current line.

Three consequences for a risk assessment.

Opening a file matters. A file you never open is far less likely to reach a request than one you have on screen. This is why content exclusion works at all, and why “I only work in this directory” is a partially meaningful statement.

Related-file inclusion is not something you fully control. Clients pull in context they judge relevant. Excluding a file removes it, but a file that references it may still carry the shape of what it declares.

Agents assemble their own context. An agent decides what to read based on the task. The set is larger and less predictable than a completion request, which is the substantive reason agents deserve separate treatment.

Three different questions

Security reviews usually collapse these into one, which is why they produce unsatisfying answers. They have different answers.

Confidentiality. Could our source code reach someone who should not have it? This is about processing, retention and the provider agreements — the material above.

Provenance. Could code from elsewhere end up in our codebase carrying obligations we did not accept? This is public-code matching and code referencing, and it is a licensing question rather than a data question. Security best practices covers it.

Integrity. Could Copilot introduce something harmful into our code? This is the review question — plausible-but-wrong output, hallucinated dependencies, outdated patterns — and it is answered by your validation pipeline rather than by any privacy control.

Answering the first and presenting it as an answer to all three is the most common failure in these documents. An organisation can be entirely satisfied about confidentiality and still have no answer for integrity, which is the one that produces incidents.

The plan is the biggest variable

Far more consequential than any toggle.

The training commitment above is specific to Copilot Business and Copilot Enterprise. Individual plans carry different terms, and a developer using a personal subscription on a work machine is operating under an agreement their employer never reviewed.

This is the strongest practical argument for organisation-managed seats, and it is a governance argument rather than a feature argument: with managed seats there is one agreement, one policy surface and one audit trail. Business covers the operational version.

Content exclusion, precisely

• Content exclusion

  Scope

  Repository, organization and enterprise rules over file paths

  Requires

  Copilot Business or Copilot Enterprise

  Applies to

  Inline suggestions and Chat in supported IDEs; excluded files are not reviewed in Copilot code review

  What it does not cover

  Does not apply to Edit and Agent modes in Copilot Chat, symlinks, or repositories on remote filesystems. Copilot may still use semantic information an IDE supplies indirectly, such as type information, hover definitions and build configuration.

• No training on Business and Enterprise data

  Scope

  Contractual and platform commitment

  Requires

  Copilot Business and Copilot Enterprise

  Applies to

  Copilot requests made under those plans

  What it does not cover

  Prompts are still processed by model providers on their infrastructure. GitHub documents zero-retention arrangements with providers for generally available features, with limited exceptions noted for beta and preview features.

Every control here has a documented edge. The limitation line is the part worth designing around.

Content exclusion is genuinely useful and routinely over-described. What GitHub documents it as doing:

• Inline suggestions are unavailable in affected files.
• Affected files do not inform suggestions in other files.
• Affected content does not inform Chat responses.
• Affected files are not reviewed in Copilot code review.

The honest way to describe it internally: content exclusion prevents specific files informing inline suggestions, Chat and code review on supported surfaces. It is a targeting control, not a data boundary.

Agents and MCP move the boundary

Everything above describes the completion and Chat path. Agents change the shape.

An agent reads files, runs commands and calls tools. An MCP server connects it to systems outside the repository entirely. Neither is governed by content exclusion in the way the completion path is, and both can move information in directions the diagram at the top of this page does not show.

Answering the question in a security review

The version that survives scrutiny, and that you can support with documentation:

On processing. Requests are sent to GitHub and processed by named model providers on their infrastructure. GitHub publishes which providers host which models.

On training. GitHub states it does not use Copilot Business or Copilot Enterprise customer data to train AI models.

On retention. GitHub documents zero-retention arrangements with providers for generally available features, noting limited exceptions for beta and preview features.

On exclusion. Content exclusion prevents specified files informing inline suggestions, Chat and code review on supported surfaces. It does not cover Edit and Agent modes.

On scope. Agents and MCP extend what Copilot can reach beyond the repository boundary, and both are governed separately from the controls described here.

On residual risk. The organisation is accepting contractual and platform commitments rather than a technical boundary it controls. That acceptance is a decision somebody should make explicitly, with a name against it, rather than one that arrives by default because the tool was already in use.

Deciding what to exclude

Content exclusion is most useful when it is narrow. A rule covering half the repository is a rule that removes Copilot’s usefulness across half the repository, and teams respond to that by not using it — or by working somewhere else.

Paths that usually justify it:

Directories holding credential material that should not be there but sometimes is — local development configuration, seeded fixtures, certificate bundles.

Vendored third-party code you did not write and do not want informing suggestions elsewhere.

Anything under a contractual restriction. Customer-supplied code, escrowed material, work under a specific agreement about processing.

Generated output that adds noise without adding meaning — large fixtures, compiled artefacts, snapshot files.

Paths that usually do not:

“Sensitive” business logic. Almost every organisation believes its core algorithms are the crown jewels. Excluding them removes assistance from exactly the code that most benefits, and the confidentiality gain is limited by the surfaces exclusion does not cover.

Whole services or repositories, unless the contractual case is real. This is usually anxiety expressed as configuration.

Documenting the limitation where it will be read

The Edit and Agent mode gap deserves a specific practice, because it is the single most likely thing to be misunderstood about this control.

Wherever you record that content exclusion is configured — the security review, the onboarding document, the wiki page an auditor will read — record the limitation in the same paragraph. Not in a footnote, not on a linked page.

The sentence that works: “Content exclusion prevents these paths informing inline suggestions, Chat and code review on supported surfaces. GitHub documents that it does not apply to Edit and Agent modes, so developers should not open excluded files in an agent session.”

That does two things a bare “content exclusion is enabled” does not. It tells a reader what protection actually exists, and it gives a developer an instruction they can follow — which is the only part of this that changes behaviour at the keyboard.

Claims to avoid

Phrases that appear in internal documents and are not supportable:

“Copilot cannot leak private code.” Nothing in the documentation supports an absolute of that shape, and a claim this strong invites exactly the scrutiny it cannot survive.

“Private repositories are completely safe.” Safe against what, under which plan, on which surface, and using which agents? The sentence has no content until those four are answered.

“Content exclusion prevents Copilot accessing those files.” Not in Edit and Agent modes.

“Our code never leaves GitHub.” For several model families the request is processed on the provider’s own infrastructure, which the hosting documentation states plainly.

“Blocking public code matches ensures we have no licensing exposure.” It filters suggestions against an index that refreshes periodically. That is an input to a licensing process, not a determination.

Each of these is a claim someone will eventually test.

The realistic risk ranking

Security reviews spend their attention in roughly the inverse of where the risk is. A rough ordering, for an organisation on Business or Enterprise:

Most likely to cause an actual incident: a developer pasting a credential into a prompt. It happens, no control catches it, and the consequence is immediate. Secrets is the next lesson for this reason.

Next: unreviewed generated code reaching production — a hallucinated dependency, a subtly wrong authorisation check. Ordinary software risk, arriving faster.

Next: an agent or MCP server with more reach than anyone assessed, connected by someone acting reasonably.

Next: shadow usage on personal plans, outside every control the organisation believes it has.

Least likely, and where most review time goes: GitHub or a model provider breaching a documented commitment about training or retention.

The last one is not zero, and it is worth the paragraph in the assessment that records which commitments you are relying on. It is not worth more attention than the first four combined, which is what it routinely receives — largely because it is the risk that feels external and therefore alarming, while the others feel like ordinary engineering.

Explaining this to non-engineers

The question usually arrives from somebody who is not going to read a hosting table, and a short accurate answer is more useful than a long hedged one.

“Does our code leave the company?” Yes — it is sent to GitHub and to model providers for processing, in the same way it would be for any hosted service. What differs from an ordinary hosted service is that GitHub commits contractually not to train on Business and Enterprise customer data, and documents zero-retention arrangements with the providers.

“Could a competitor see it?” Nothing in the documentation suggests a mechanism for that. What it does not offer is a technical guarantee — the protection is contractual, which is the same basis on which the organisation already trusts every other vendor holding its data.

“Can we turn it off for the sensitive parts?” Partially, and it is worth being precise: content exclusion covers inline suggestions, Chat and code review on supported surfaces, and not Edit or Agent modes.

“What is the actual risk?” Realistically, not a provider breaching a commitment. It is a developer pasting a credential into a prompt, or generated code reaching production without proper review. Both are addressed by practice rather than by configuration.

Common questions

Does GitHub train on our private code? GitHub states it does not use Copilot Business or Copilot Enterprise customer data to train AI models. Individual plans carry different terms.

Can we keep specific directories out entirely? Content exclusion covers supported surfaces and not Edit and Agent modes, so “entirely” overstates it.

Can we run it entirely inside our own infrastructure? Copilot is a hosted service, so no. Where a regulatory requirement genuinely forbids external processing, that is a procurement conversation rather than a configuration one.

What about GitHub Enterprise Server? Availability and behaviour differ from Enterprise Cloud; check the documentation for your deployment rather than assuming parity.

Does using a specific model change the answer? It changes which provider processes the request, which is why the hosting table is worth reading rather than summarising. The training and retention commitments GitHub documents apply across the generally available catalogue.

Do we need to tell developers any of this? Yes — the Edit and Agent mode limitation especially. A control nobody knows the shape of is a control people will unknowingly work around.

Who should own this assessment? Security, with the current contractual terms and privacy documentation as the sources. This lesson describes the mechanics; it is not a legal determination and cannot substitute for one.

Revisiting the assessment

Everything on this page has a shelf life, and an assessment written once and filed becomes wrong quietly.

Three things change underneath it.

The model catalogue. Models are added and retired, and hosting arrangements change with them. An assessment naming specific providers should carry a date and a review interval.

The controls. Content exclusion’s supported-surface list is exactly the kind of thing that expands — and an assessment that recorded a limitation which has since been closed is under-claiming, which is a smaller problem than over-claiming but still worth fixing.

Your own usage. The largest source of drift. An organisation that assessed Copilot for completions and Chat, and has since adopted agents and connected three MCP servers, is operating under an assessment that describes a system it no longer runs.

Next

Secrets narrows from repository contents to the single category of data that causes the most damage when it moves — and where the controls people rely on have a specific, documented blind spot.