GitHub Copilot for Enterprise: Security Risks Teams Overlook (2026 Guide)

GitHub Copilot is now much more than code completion. It has chat, agent mode in the IDE, a CLI, code review, and a cloud agent that can open pull requests by itself. This guide is for engineering leaders who want to use Copilot in a company without adding hidden risk. Every claim is based on GitHub's documentation or published research, listed at the end.

Is GitHub Copilot safe for enterprise use?

Yes, if you set it up with care. The main risks do not come from Copilot "leaking" your code to other customers. They come from how your team uses the output: insecure code, secrets in context, fake or old packages, public code matches, and agents that read untrusted text.

GitHub itself says that Copilot "may sometimes output insecure code" and that you should take the same precautions you take with code written by your engineers [1]. So treat every Copilot suggestion like code from a new team member you do not know yet.

Which Copilot plan should a company use?

Use Copilot Business ($19 USD per seat per month) or Copilot Enterprise ($39 USD per seat per month, for GitHub Enterprise Cloud). Both give admins central management and policy control [11].

Why this matters for security: content exclusion is only available in these two plans [2]. The terms are also different. For Business and Enterprise customers, GitHub says it does not use their Copilot data to train AI models [1][12]. For individual plans (Free, Pro, Pro+, Max), GitHub may use interaction data for training unless the user opts out [1].

What data does GitHub Copilot keep?

It depends on where your developers use Copilot. The GitHub Copilot Trust Center lists these default rules for Business and Enterprise customers [1]:

Two points are easy to miss:

1. GitHub may keep input and output data for a limited time to investigate confirmed abuse or to protect the security of its services [1].
2. Model choice can change retention. The Trust Center notes that when the Claude Fable 5 model is used, Anthropic retains prompts and outputs to run safety classifiers [1]. Enterprise admins can choose which models are enabled in the Copilot policies [1][9].

What to do: Decide which Copilot surfaces and models you allow, and write it into your internal AI policy.

Risk 1: Copilot can suggest insecure code

Copilot can suggest code with security bugs. This is the best-known risk.

The most cited study is "Asleep at the Keyboard?" by Pearce and others (IEEE Symposium on Security and Privacy 2022). The researchers generated 1,689 programs with Copilot across 89 security-relevant scenarios. About 40% were vulnerable [17]. This was an early version of Copilot, so the number does not measure today's product. But the lesson still holds: the model learns from public code, and public code has bugs.

GitHub now runs an AI-based vulnerability prevention system that blocks common insecure patterns, such as hardcoded credentials, SQL injection and path injection [1]. This helps, but it does not replace real scanning.

How to reduce this risk:

• Turn on code scanning with CodeQL. Default setup is the fastest way to start. It works for public repositories, and for private repositories when GitHub Code Security is enabled [14].
• Use a ruleset with "Require code scanning results" so pull requests cannot merge while serious alerts are open [16].
• Keep human review. Use the "Require a pull request before merging" rule, with required approvals and Code Owner review for sensitive paths [16].

Risk 2: Secrets and sensitive files in Copilot's context

Copilot builds its prompt from the file you are editing and related files in the project [1]. So a nearby .env file, private key or config file with passwords can become part of the context.

How to reduce this risk:

• Use content exclusion to stop Copilot from reading sensitive files. It is available in Copilot Business and Enterprise. Repository admins and organisation owners can set it up [2].
• Turn on secret scanning push protection. It blocks pushes that contain secrets such as tokens and keys before they reach the repository. It is free for public repositories and needs GitHub Secret Protection for private repositories [13].

Here is a real repository-level content exclusion example, from GitHub's docs. You add it under Settings > Copilot > Content exclusion [3]:

# Ignore files called `secrets.json` anywhere in this repository.
- "secrets.json"

# Ignore all files whose names begin with `secret` anywhere in this repository.
- "secret*"

# Ignore files whose names end with `.cfg` anywhere in this repository.
- "*.cfg"

At the organisation level, you can apply a rule to all repositories. This example from GitHub's docs excludes every .env file [3]:

"*":
  - "**/.env"

Content exclusion is not a hard wall:

• GitHub's docs say content exclusion is not supported in the Edit and Agent modes of Copilot Chat in Visual Studio Code and other editors [2].
• Information from excluded files can still reach Copilot indirectly, for example through type information from the IDE [2].
• It does not apply to symbolic links or to repositories on remote file systems [2].
• Changes can take up to 30 minutes to reach IDEs that already loaded the settings [3].

The real fix is to keep secrets out of the repository. Content exclusion is a second layer, not the first.

Risk 3: Hallucinated and outdated packages (slopsquatting)

AI models sometimes suggest packages that do not exist. An attacker can register that fake name on npm or PyPI and fill it with malware. People call this "slopsquatting".

A USENIX Security 2025 paper by Spracklen and others tested 16 code-generating models on 576,000 code samples. Commercial models hallucinated packages at an average rate of at least 5.2%, and open-source models at 21.7%. The study found 205,474 unique fake package names [18]. The paper did not test Copilot as a product, but Copilot uses the same kind of models.

How to reduce this risk:

• Add the dependency review action to pull requests. It checks new or changed dependencies and can fail the pull request if they have known vulnerabilities. This workflow is from GitHub's docs [15]:

name: 'Dependency Review'
on: [pull_request]

permissions:
  contents: read

jobs:
  dependency-review:
    runs-on: ubuntu-latest
    steps:
    - name: 'Checkout Repository'
      uses: actions/checkout@v6
    - name: Dependency Review
      uses: actions/dependency-review-action@v4
      with:
        fail-on-severity: critical

• Turn on Dependabot alerts and security updates so old vulnerable packages get flagged and updated.
• Ask reviewers to check any new package name in a pull request. Is it real? Is it maintained? Is it the package you think it is?

Risk 4: Suggestions that match public code (licence risk)

Copilot does not copy and paste from a database, but in rare cases (less than 1% of outputs, by GitHub's research) its output can match public code [1]. If that code has a strict licence, you may have licence duties.

GitHub gives admins two tools:

• Duplicate detection filter ("Suggestions matching public code"). When set to "Block", Copilot checks outputs against public code on GitHub. If it finds a match of about 65 lexemes (on average 150 characters) or more, it does not show the suggestion [1].
• Code referencing. When the policy is set to "Allow", Copilot shows details of the matching public code, with links to the source repositories and licence information where available [1][4]. It works in inline suggestions and Copilot Chat in supported IDEs and on GitHub.com [4]. The index is refreshed every few months, so very new code may not show up [4].

IP indemnity depends on these settings. The Trust Center says Business and Enterprise customers get uncapped IP indemnity for unmodified outputs when they follow Microsoft's required mitigations. For most features, you do this in one of two ways: set the public code filter to "Block", or set it to "Allow" and follow the licences shown by code referencing [1]. The Trust Center also notes that this filter does not apply to the Copilot coding agent, but unmodified code from the agent is still covered [1]. Please confirm the exact terms with your legal team, because contracts can differ [12].

Risk 5: Prompt injection through issues, files and web content

This is the risk most teams overlook. Agent features read text that other people wrote: issues, comments, files, web pages and tool output. If that text contains hidden instructions, the agent may follow them. OWASP ranks prompt injection first (LLM01) in its Top 10 for LLM Applications 2025, and calls this form "indirect" prompt injection [19].

What GitHub does for the Copilot cloud agent (earlier called Copilot coding agent):

• Only users with write access can start the agent, and comments from users without write access are never shown to it [5].
• GitHub filters hidden characters from user input, and text inside HTML comments is not passed to the agent [5].
• The agent pushes to one branch only, usually a new copilot/ branch, and follows your branch protections and required checks [5].
• It cannot approve or merge its own pull requests, and the person who asked for the pull request cannot approve it [5].
• GitHub Actions workflows do not run on its pull request until a user with write access approves them [5].
• The agent runs in its own short-lived environment powered by GitHub Actions [6]. By default, a firewall limits its internet access to reduce data exfiltration risk [5][7].
• Before it finishes, the agent checks its own code with CodeQL, secret scanning, a malware check on new dependencies against the GitHub Advisory Database, and Copilot code review [5].

Know the firewall's limits. GitHub's docs say the firewall only covers processes the agent starts through its Bash tool. It does not cover MCP servers or processes started in setup steps. GitHub also says sophisticated attacks may bypass it and that it "should not be considered a comprehensive security solution" [7]. Keep the allowlist short. Organisation owners can set an organisation-wide allowlist and can stop repositories from changing the firewall settings [7].

Control MCP servers. MCP servers give Copilot new tools, and each tool is a new path for data to leave. GitHub has a "MCP servers in Copilot" policy. GitHub recommends keeping this policy on and, if needed, limiting users to an approved list of servers [8]. There are two ways to set that list. A managed settings file is generally available and gives stronger enforcement. A custom MCP registry is in public preview, and GitHub notes that users can bypass it by editing configuration files [8].

Risk 6: Over-trust and review fatigue

When Copilot writes more of the code, reviewers see more code in less time, and it is easy to approve a large, clean-looking pull request without reading it. GitHub says Copilot is "not intended to generate outputs without oversight" and that you should use the same safeguards you use for any third-party code [1].

How to reduce this risk:

• Keep pull requests small. Ask the agent for one change per task.
• Require Code Owner review for security-sensitive folders such as auth, payments and infrastructure [16].
• Make CI checks required, so a tired reviewer is not the only gate [16].
• Train developers to read the agent's session logs. Each agent commit links to its session logs, and the agent's commits are co-authored by the developer who asked for the work [5].

How do admins control and audit Copilot?

• Policies decide which Copilot features, agents and models users can access. They apply on every surface where users sign in to Copilot, including IDEs, GitHub.com and Copilot CLI. Enterprises can choose exactly which organisations get the cloud agent [9].
• Cloud agent access is off until an admin enables the policy for Business and Enterprise users. Repository owners can also opt out [6].
• Audit logs record plan and policy changes, licence changes and agent activity on GitHub.com. You can search agent activity with actor:Copilot [10].

Important: the audit log does not include the prompts that users send to Copilot locally. Events are kept for 180 days, so stream them to your SIEM if you need longer history [10].

Copilot enterprise security checklist

1. Use Copilot Business or Enterprise for all company work. Do not allow personal plans on company code.
2. Choose which Copilot features, agents and models are enabled. Review the list every quarter.
3. Set "Suggestions matching public code" to "Block", or to "Allow" with a clear process for following licences. Confirm with legal.
4. Add content exclusion rules for secrets, keys and sensitive config. Remember it does not cover agent mode in the IDE.
5. Turn on secret scanning push protection.
6. Turn on CodeQL code scanning (default setup is fine to start).
7. Add the dependency review action and Dependabot.
8. Protect main branches with rulesets: required pull requests, approvals, Code Owners, status checks and code scanning results.
9. Enable the cloud agent only for the organisations and repositories that need it. Keep its firewall on and its allowlist short.
10. Turn on the MCP policy and limit users to approved MCP servers.
11. Stream audit logs to your SIEM.
12. Train developers on prompt injection and on reviewing AI code.

Sources

1. GitHub Copilot Trust Center FAQ - GitHub, 2026
2. Content exclusion for GitHub Copilot - GitHub Docs, 2026
3. Excluding content from GitHub Copilot - GitHub Docs, 2026
4. GitHub Copilot code referencing - GitHub Docs, 2026
5. Risks and mitigations for GitHub Copilot cloud agent - GitHub Docs, 2026
6. About GitHub Copilot cloud agent - GitHub Docs, 2026
7. Customizing or disabling the firewall for GitHub Copilot cloud agent - GitHub Docs, 2026
8. MCP management for GitHub Copilot - GitHub Docs, 2026
9. GitHub Copilot policies - GitHub Docs, 2026
10. Reviewing audit logs for GitHub Copilot - GitHub Docs, 2026
11. GitHub Copilot plans - GitHub Docs, 2026
12. GitHub Generative AI Services Terms - GitHub, 2026
13. About push protection - GitHub Docs, 2026
14. Configuring default setup for code scanning - GitHub Docs, 2026
15. Configuring the dependency review action - GitHub Docs, 2026
16. Available rules for rulesets - GitHub Docs, 2026
17. Asleep at the Keyboard? Assessing the Security of GitHub Copilot's Code Contributions - Pearce et al., IEEE S&P, 2022
18. We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs - Spracklen et al., USENIX Security, 2025
19. LLM01:2025 Prompt Injection - OWASP Gen AI Security Project, 2025

FAQ

Does GitHub Copilot train on my company's code?

Not on Business or Enterprise plans. GitHub's terms say it will not use inputs or outputs to train models unless you give documented instructions [12]. It also says it does not train on content from paid organisations' repositories, even when a member uses a personal Copilot plan there [1].

Does Copilot Business store my prompts?

For IDE chat, code completions and Copilot CLI, prompts and suggestions are not retained by default. For other Copilot use, they are kept for up to 28 days by default. Cloud agent session logs are kept for the life of the account [1].

Does content exclusion fully protect sensitive files?

No. It does not work in the Edit and Agent modes of Copilot Chat in VS Code and other editors, and some information can still reach Copilot through the IDE [2]. Keep secrets out of the repository and use push protection.

How do we keep IP indemnity for Copilot?

Set "Suggestions matching public code" to "Block", or set it to "Allow" and follow the licences that code referencing shows [1]. Ask your legal team to confirm this against your contract.

Can the Copilot cloud agent merge code to main by itself?

No. It pushes only to its own branch, it cannot approve or merge its pull requests, and it follows your branch protections [5].

What is slopsquatting?

It is when an attacker registers a package name that an AI model often invents, so developers who trust the suggestion install malware. One study found 205,474 unique hallucinated package names across 16 models [18]. A brand-new fake package may have no security advisory yet, so a human check of every new package name is your main defence.

Need help securing AI-generated code?

Copilot can make your team faster, but only if the code it writes is safe to ship. At Eunix Tech, we help engineering teams audit and harden AI-generated code, set up Copilot policies, and build review and scanning pipelines that catch problems early. Learn more about our AI code assistant optimization service.