TL;DR

• Secrets leakage tops the list: 6.4% of repositories with Copilot enabled leak at least one secret, 40% above the 4.6% public baseline in 2025.
• Suggestions inherit old flaws: Copilot's training data ages fast, and hallucinated package names hand attackers a ready supply chain target.
• Agent mode widens the attack surface: hidden prompt injection can steer Copilot, and 24,008 secrets turned up in public MCP config files in 2025.
• Your tier sets your data terms: Business and Enterprise do not train on your private code; Free tier interactions can feed model improvement unless you opt out.
• Configure once, review always: set organization-level privacy defaults, run secrets detection, and read every suggestion before it merges.

Is GitHub Copilot secure? As beneficial as it may be, it also comes with significant security and privacy concerns that individual developers and organizations must be aware of. As Frank Herbert put it in "God Emperor of Dune" (the 4th book in the Dune saga):

"What do such machines really do? They increase the number of things we can do without thinking. Things we do without thinking–there's the real danger."

The first step in protecting yourself and your team is to understand the pitfalls to avoid as we leverage these handy tools to help us all work more efficiently. 

How GitHub Copilot is trained

To better understand what to guard against, it is important to remember how data ends up in these AI models. GitHub Copilot ingests a large amount of training data from a wide variety of sources. This is the data it references to generate suggestions and answer user prompts. These training sources include the code in all public GitHub repositories and, essentially, the whole of the public internet. Like all machine learning models, Copilot can only be as reliable as the code and text its model training draws on.

Importantly, Copilot also learns from the prompts users input when asking questions. If you copy and paste code or data into any public LLM, you are encouraging the AI to share your work. For open-source projects or public information, there is not a lot of danger here on the surface, as it has likely trained on this already. But here is where the danger starts for internal and private code and sensitive data.

Security concerns with GitHub Copilot: 6 key risks

Here are the key risks to be aware of and to watch out for as you use any code assist tool in your development workflow.

Potential leakage of secrets, API keys, and private code

GitHub Copilot may suggest code snippets that contain sensitive information, including API keys and other credentials that unlock your data and machine resources. This is at the top of our list because it means an attacker can potentially use Copilot to gain an initial foothold.

While some safeguards are in place, clever prompt rewording can yield suggestions that contain valid credentials. This is an attractive path for attackers looking for ways to gain access for malicious purposes.

Recent research by GitGuardian quantifies these concerns. In a sample of approximately 20,000 repositories where Copilot is active, over 1,200 leaked at least one secret, representing 6.4% of the sampled repositories. That incidence rate is 40% higher than the 4.6% observed across all public repositories. Two factors likely explain the gap. First, code generated by LLMs may contain more insecure patterns. Second, and probably more significant, coding assistants may push developers to prioritize productivity over code quality and security. Despite the continuous improvement of coding assistants, this data underscores the ongoing need for robust security controls in application security, particularly in the area of secrets detection.

Attackers are also looking for clues about your applications and environments. If they learn you are using an outdated version of some software, especially a component with a known, easily exploited flaw, that is likely an attack path they will attempt to exploit. While more time-consuming than using a discovered API key, this is still a serious concern for any enterprise.

Insecure code suggestions

While we would love to say ChatGPT and Copilot only ever suggest completely secure code and configurations, the reality is the suggestions will only ever be as reliable as the data they are trained on. By definition, Copilot is an average of all developers' shared work. Unfortunately, all the security failings added to all known public codebases are part of the corpus on which it bases its suggestions.

The data it is trained on is also aging rapidly and cannot keep up with the latest advances in threats and vulnerabilities. Code that would have been fine even a couple of years ago, thanks to new CVEs, known security vulnerabilities, and new attack techniques, is sometimes just not up to modern challenges. Vulnerable code that looks plausible is harder to catch than code that fails outright, which is why code quality reviews still matter.

Poisoned data can mean malicious code

A research team uncovered a method of injecting hard-to-detect malicious code samples used to poison code-completion AI assistants into suggesting vulnerable code. Attackers working to lure developers into using purposefully insecure code is not a new phenomenon, but attackers now count on developers simply trusting the code suggestions from their friendly Copilot and not overly scrutinizing them for security holes. Finding and using a random code sample on StackOverflow would likely give every developer pause, especially if heavily downvoted. AI suggestions rarely trigger the same skepticism.

Package hallucination squatting and dependency risks

One of the more disturbing problems across all AIs is that they simply make things up. When asking trivial questions, these hallucinations can be entertaining. When writing code, this issue can be dangerous.

In the best scenario, the package Copilot suggests simply does not exist, and you will need to find an alternative. This pulls you out of your flow and wastes your time. One researcher reported that as much as 30% of all packages suggested by ChatGPT were hallucinated.

Attackers are well aware of this issue and have begun exploiting it to find commonly suggested non-existent packages and register those packages themselves. The most clever of them will clone similar packages that perform the functionality Copilot describes and then hide malicious code within, counting on the developer not to look too closely. This practice is similar to typosquatting; so the security community has dubbed this issue "hallucination squatting." Strong dependency management, including lockfiles and registry allowlists, is a critical defense.

Prompt injection and agent-mode risks

Copilot has grown from an autocomplete tool into an agentic assistant that can read issues, browse context, call Model Context Protocol (MCP) servers, and open pull requests. That expanded reach creates a new class of risk: prompt injection. Malicious instructions hidden in code comments, issue descriptions, or web content the assistant processes can steer it toward insecure suggestions or unwanted actions, and any data the agent can read becomes a potential channel for data leakage.

The configuration files that wire up these agent workflows are themselves becoming a leak surface. GitGuardian's research found 24,008 unique secrets exposed in public MCP config files in 2025. Treat everything an agent can access as untrusted input, restrict which MCP servers and extensions are approved for use, and review agent-initiated pull requests with the same scrutiny you would apply to an unknown external contributor. Your AI agents are using your credentials, and incidents like the ChainDrop npm worm show how quickly agent-adjacent credential abuse now moves.

Lack of attribution and licensing

One of the more commonly overlooked issues with code suggested by any LLM is understanding the licensing of suggested code. When Copilot generates code, it does not always provide clear attribution to the original source. This does not pose an issue for permissive licenses like Apache or MIT. But what if you inject a copyleft-licensed bit of code, such as the GPL, which demands that the inclusion of this code makes the entire codebase open-source? What do your legal and compliance teams say about this? If you doubt whether you can include the code, it should likely be left out of your project.

Privacy concerns with GitHub Copilot and data protection laws

Privacy is the second class of concern. Data protection laws such as the General Data Protection Regulation (GDPR) and the California Consumer Privacy Act (CCPA) differ between jurisdictions, but these issues affect our users, the people we work to keep safe.

Sharing private code and enterprise data

GitHub Copilot collects data on user interactions, including the code that users write and how users respond to the suggestions it generates. While the goal is to refine the model and give everyone a better experience, for developers working on sensitive or proprietary projects, it raises serious privacy concerns. Your organization may not want its proprietary code, enterprise data, or development practices to be analyzed or stored by GitHub, even if it is for improving AI performance.

Retention of user data and model training

The community has many questions about how long LLMs retain user data, how much data is stored, and what specifically is in there. Companies go to great lengths to secure customer data and keep it safe. Using real data to build a query is a temptation for developers, especially if you can just upload a .zip folder and ask AI to generate the needed code to run analytics or transform it. Sharing this data might directly violate regulations like GDPR or CCPA, and prompts or feedback data retained for model improvement can outlive the session that produced them.

Copilot Free vs Business vs Enterprise: how your Copilot data is handled

Not all Copilot tiers treat your data the same way, and the differences matter for anyone responsible for code exposure and intellectual property protection.

According to GitHub's documentation, GitHub Copilot for Business does not train on your private code. Copilot Business and Enterprise customers get organization-level policy management, the "block suggestions matching public code" filter, content exclusion for sensitive files and directories, and audit logging of Copilot usage across the organization. Enterprise customers layer on governance features designed for regulated environments.

The free tier is a different story. Copilot Free operates under terms that may allow user interactions to contribute to model improvement, so review the model training opt-out in your user settings before using it for anything beyond open-source or learning projects. Organizations evaluating Copilot Free should prohibit its use for anything involving customer data or proprietary algorithms and define when teams must move to Copilot Business.

Whichever GitHub Copilot tier you run, a few settings deserve attention first: enable the public code matching filter, configure content exclusion so sensitive code, configuration files, deployment scripts, and other sensitive assets are never processed, restrict Copilot access to approved repositories, and review telemetry collection settings. Decide deliberately which Copilot features are enabled for which teams. Secure defaults at the organization level, paired with your existing access controls, beat relying on every developer to configure their own user settings correctly.

Using GitHub Copilot safely: 4 best practices

Despite all these concerns, GitHub Copilot can still be a valuable tool if used cautiously. Here is what security teams and developers can do to avoid these common security and privacy risks.

#1. Review AI-generated code carefully

Just as you would not run random, untested code, even locally, you should scrutinize any AI-generated code from Copilot or any other AI code assistant. Treat GitHub Copilot's suggestions as exactly that: suggestions. Read what is there carefully to see if it makes sense, use it as a learning tool, or ask Copilot to suggest improvements to code you already understand. Always check whether the suggested code lives up to your organization's coding standards and security guidelines, and remember it is your responsibility once the code is merged through your pull requests.

#2. Keep secrets out of your source code

Even with tiers that do not train on private code, it is still crucial not to expose your secrets anywhere. You might think it would be hard to copy and paste your credentials into an AI assist tool. However, if you have integrated Copilot into your IDE, it is always reading your code and trying to anticipate what you need next. The only true way to prevent secrets from leaking into a code assist tool, or anywhere else, is to eliminate plaintext credentials from source code entirely.

Finding and helping teams eliminate hardcoded secrets is exactly what the GitGuardian Secrets Detection Platform has been helping teams accomplish for years.  

We have extended the power of the platform into the AI coding agent workflow to prevent an agent from ever touching a secret. GitGuardian's CLI, ggshield, can add hooks that prevent an agent from accepting a prompt with a secret, or using any secrets it discovers through file reads, MCP calls, or any other input it receives. 

Further, developers can run ggshield with pre-commit hooks to check for hardcoded secrets before code ever leaves their machine, and the GitGuardian VSCode extension catches plaintext credentials in Visual Studio Code as files are saved. GitGuardian complements Copilot's native filters rather than replacing them: the filters reduce what Copilot suggests, while secrets detection catches what lands in your source code.

#3. Tune your Copilot privacy settings

GitHub provides settings that allow users to control aspects of data sharing with Copilot. Review and configure these settings to minimize data sharing where possible, especially in environments where privacy is a significant concern.

#4. Train developers on security best practices

Developers are on the front lines, delivering features at an ever-increasing rate. Developer training should ensure that anyone using Copilot understands the threats and your organization's security best practices. Less experienced developers especially need to understand the risks of relying too heavily on AI generated suggestions.

We need balance, though, and should not discourage all Copilot usage, as AI assist tools are not going away and will only gain wider adoption. Security needs to move past being the department of no and become the team that empowers developers to work more safely and efficiently.

Balancing developer productivity and security

GitHub Copilot is an increasingly valuable tool that can significantly speed up software development and reduce the toil developers face daily. It is not without its security and privacy challenges. Developers and organizations need to be deliberate about how they adopt and use Copilot: understand how each tier handles your data, configure secure defaults, keep sensitive data and plaintext credentials out of prompts and code, and review every AI suggestion before it merges. As with any new technology, a strong GitHub Copilot security posture lies in balancing the productivity benefits with the potential drawbacks and prioritizing security at every step.