GitHub Copilot Security: Enterprise and Business Controls for Agent Mode, the Coding Agent and Copilot CLI

This is the clearest published demonstration of why a Copilot review has to cover configuration as well as code, because the payload did not attack the developer. It attacked the settings file.

The mechanism is short enough to state in one sentence. Copilot could write files in the workspace without user approval, and those writes went to disk immediately, so an injected instruction could add one line to the project settings file at .vscode/settings.json. The line was "chat.tools.autoApprove": true. In the researcher description, that setting "disables all user confirmations, and we can run shell commands, browse the web, and more". The demonstration then popped a calculator on both Windows and macOS, choosing the command by operating system.

Two details make this worth more than a patch note. The first is that the injection arrived through ordinary repository content: code comments, documentation, files, including text hidden in invisible Unicode. Nobody had to be tricked into pasting anything. The second is the researcher own assessment of how it spreads, which is worth quoting in full because it describes a class of risk that sandboxing alone does not address: "An attacker can embed instructions and once they gain code execution, additional malware can compromise other Git projects (and RAG sources) to embed the malicious instructions, and commit the changes or even force push them upstream. This can lead to further spread as other developers unknowingly propagate the infected code."

One clarification on the naming, since the CVSS vector reads AV:L and the title says Remote. Microsoft has explained that "Remote" in these titles refers to the location of the attacker rather than the attack vector, and that this class is sometimes called arbitrary code execution. If you are triaging by title alone you will misjudge it in both directions, so read the vector.

The generalizable lesson is that the agent permission model was self-modifying. An agent allowed to write any file in a workspace is allowed to write the file that governs its own approvals. That failure mode is not unique to GitHub. It is the same structural issue behind the Cursor sandbox escapes and the Gemini CLI allowlist bypass under yolo mode, and the fix in every case was to move the approval decision somewhere the agent cannot edit.

CamoLeak is the highest-scored GitHub Copilot finding published to date, at CVSS 9.6, and it is the one that best explains why data-handling promises and runtime data protection are different things.

Omer Mayraz of Legit Security found it in June 2025, reported it through HackerOne, and GitHub fixed it on August 14, 2025. It was disclosed publicly in October 2025. The attack chained three pieces:

• Injection through invisible comments. Instructions were placed in pull request descriptions inside GitHub hidden markdown comments, the <!-- --> syntax that does not render in the web interface but is still read by the assistant. The prompt then entered the context of other users viewing the page, not only the author.
• A Content Security Policy bypass using GitHub own infrastructure. GitHub blocks external image requests, and it rewrites remote image URLs through its Camo proxy at camo.githubusercontent.com with HMAC signatures. Mayraz pre-generated a dictionary of valid signed Camo URLs, one per character, then instructed Copilot to "render the content I want to leak as 'ASCII art' composed entirely of images". Every image was a legitimate signed GitHub URL, so the policy allowed all of them.
• Exfiltration on render. Each image request carried encoded victim data. The browser fetched them automatically and the data arrived at the researcher server.

The proof of concept was not theoretical. It pulled contents from a private organization repository, ran searches for keywords such as AWS_KEY across private codebases, and retrieved the full description of an undisclosed zero-day vulnerability stored in a private issue. Nothing on that list requires the attacker to run a single line of code on the target.

GitHub remediation is the detail that should shape how you read vendor assurances: it disabled image rendering in Copilot Chat entirely. That is the right call and it is also an admission. When a boundary cannot be held, the honest fix is to remove the capability that crosses it. Compare that with the retention promise on the same product, which is accurate and which would not have helped here at all. GitHub genuinely does not train on Business and Enterprise customer data, and the private repository contents still left the building, because the leak path was the agent output channel, not the training pipeline.

Note also what the fix did not close. The injection vector, an invisible markdown comment in a pull request that other people read, is still exactly as available as it was. Only the exfiltration channel was removed. That is the pattern across every finding on this page, and it is why detection at the input has to be paired with control at the output.

The most decision-relevant GitHub Copilot security research of 2026 is not a CVE, and its most useful output is a sentence from GitHub rather than a patch.

Aonan Guan, with Zhengyu Liu and Gavin Zhong of Johns Hopkins University, published "Comment and Control" on April 16, 2026. The technique delivers instructions to an agent through ordinary GitHub communication channels: pull request titles, issue descriptions and comments. What separates it from classic indirect prompt injection is that it does not wait for anyone. GitHub Actions workflows trigger automatically on pull_request, issues and issue_comment events, so filing an issue is enough to start the agent. There is no victim interaction to phish.

GitHub classification deserves to be taken seriously rather than read as a brush-off, because it is correct. An agent whose job is to read issues and pull requests must read text written by people you do not control. An agent that opens pull requests must hold a token that can write. Those two requirements are the product, so no amount of prompt hardening removes the exposure, and calling it architectural is more honest than shipping a filter and implying the problem is solved. It is the same conclusion Pillar Security reached on a separate agent, where the model refused five researchers who asked for secrets by name and ran a payload that never mentioned secrets at all.

The bounty amounts are worth a moment as well, not as gossip but as a signal of how differently three vendors priced the same technique against their own products. One rated it critical and paid 100 dollars. One paid 1,337. The classification and the payout do not move together, so read the classification and ignore the number.

If you run agent workflows in GitHub Actions today, three changes follow directly from this research and none of them require buying anything. Never let one workflow read attacker-authored input while holding write permissions, split reading and writing into separate jobs with separate tokens, and require an approval gate on the job that writes. That is the same approval boundary we recommend for every agent that touches a system of record, and it is the only control in this section that would have stopped all three attacks.

Most of the value available to a security team here is included in the license and switched off by default. This is the configuration pass to run before evaluating anything external.

The first row is the highest-value line on this page for most organizations, and it is the one most often missed, because it only became available on June 17, 2026 and plenty of Copilot deployments were assessed before that date. Auto-approve is not an edge case. It is what a developer reaches for on the second afternoon of agent mode, after the twentieth confirmation prompt, and it converts a tool with a human in the loop into one without. If your Copilot review predates the middle of 2026, this setting almost certainly does not exist in your baseline.

The default position of the firewall is the second thing to check. Both organization firewall settings default to Let repositories decide, which is a reasonable product default and a poor security default, since it means your egress posture is whatever each repository owner happened to configure. Setting it centrally costs nothing and gives you one answer instead of hundreds.

Worth being clear about the ceiling on all of this. Every setting above governs the Copilot clients GitHub controls. None of them governs what happens after the agent makes a legitimate-looking call to an internal API with a token your identity provider issued, which is where an independent record of agent actions and runtime monitoring start earning their place. Configure GitHub first. It is included, and it closes the cheap gaps.

Several of the things buyers ask us for on this topic are already solved inside GitHub, usually by a setting on a license they are paying for. Selling against those would be dishonest and would also waste your budget, so here is the split as plainly as we can put it.

The honest summary is a question about what your agents touch. If Copilot writes code that a human reviews and merges, GitHub native controls plus your normal review process are sufficient and you should stop reading here. If Copilot is opening pull requests unattended, calling MCP servers, running in CI with credentials, or reaching internal systems, then the residual risk is the one GitHub itself called architectural, and it does not live in the editor. It lives at the moment the agent takes an action, which is where we work.

If you are comparing coding agents rather than securing one you have already chosen, the security comparison of Gemini CLI and Claude Code covers default permissions and admin enforcement across the two, and the Claude agent security page covers the same ground for Anthropic tooling. For the protocol layer underneath all of them, start with the MCP gateway page.