GitHub Copilot Chat vulnerability exposes a new AI agent attack path

At a glance

What this is: A critical GitHub Copilot Chat flaw allowed prompt injection to exfiltrate private-repo secrets and source code while manipulating the assistant’s output.

Why it matters: It matters because AI assistants embedded in developer workflows can inherit repository permissions, turning context handling and rendering paths into governance and identity-control problems.

Context

GitHub Copilot Chat sits inside the developer workflow, so it is not just a text assistant. It can consume repository context, respond with code-aware output, and act on the permissions of the user making the request, which means the trust boundary shifts from the model alone to the full access path around it.

The vulnerability described in this article combines remote prompt injection with a content rendering bypass, which is why traditional application security thinking is not enough on its own. Once an AI assistant can process untrusted content in a privileged workspace, the governance question becomes how to constrain what context it may read, render, and reveal.

Key questions

Q: What breaks when a code assistant can read private repository context?

A: The main failure is that repository context becomes part of the assistant’s effective privilege set. If hidden instructions, comments, or rendered content can reach the assistant, it may reveal secrets, source code, or recommendations the user never intended to expose. Security teams should assume that any assistant with read access can also become a data disclosure path unless context boundaries are tightly constrained.

Q: Why do prompt injection attacks create access-control risk in developer tools?

A: Because the assistant often acts with the permissions of the authenticated user, so a successful injection can turn ordinary collaboration content into privileged instruction. That makes access control, context filtering, and output handling part of the same control plane. The risk is higher when the assistant can reach private repositories or generate outbound content that a browser or user might trust.

Q: What are the signs that an AI assistant is too deeply integrated into trusted content flows?

A: Warning signs include assistants that can consume unreviewed comments, process hidden markdown, render external media, or access broad repository history without a clear need. If attacker-controlled text can enter the assistant through normal collaboration features, the integration is likely too permissive. The safest design narrows inputs, limits repository reach, and logs assistant-triggered data access.

Q: How should security teams govern personal AI assistants that act on behalf of employees?

A: Treat each assistant as a distinct non-human actor with its own identity, policy scope, and audit trail. Human delegation alone is not enough when the assistant can move across email, documents, calendars, and internal systems. Governance should bind the sponsor, the executor, and the target resource so access reviews and investigations can separate request from action.

Technical breakdown

How prompt injection reaches a context-aware AI assistant

Prompt injection works when attacker-controlled text is placed into a context the assistant is likely to read as instruction-bearing content. In this case, the prompt was hidden in a pull request description, then surfaced to other users who visited the page. Because Copilot Chat is context-aware, the injected instructions were processed alongside legitimate repository content, which let the attacker influence outputs without needing to compromise the underlying model. The risk increases when hidden or indirect content can reach the assistant through normal product features rather than obvious user input. Practical implication: treat all assistant-visible repository content as untrusted instruction space, not just obvious chat prompts.

Practical implication: restrict what untrusted content can enter assistant context and review every surface that can feed instructions into the model.

Why CSP and proxy controls did not stop the leak

Content Security Policy normally limits where a browser can load external content from, but the attack abused GitHub-controlled infrastructure to create trusted-looking image delivery paths. The article describes Camo, GitHub’s image proxy, as the mechanism that rewrites and serves external images through GitHub infrastructure. By turning leaked data into a sequence of image-like requests, the attacker worked around the expectation that CSP alone would prevent exfiltration. This is a good example of why browser security controls can be bypassed when an application already has sanctioned rendering pipelines. Practical implication: review whether trusted proxy and rendering services can be repurposed for data exfiltration.

Practical implication: test sanctioned media and proxy pipelines for abuse paths that can carry encoded sensitive data out of the environment.

Why AI assistants become identity-sensitive attack surfaces

Copilot Chat operated with the permissions of the user making the request, which means the assistant effectively inherited identity scope from the session and the repository context. That makes the assistant a privileged intermediary, not a neutral feature. If the model can read private repositories, render attacker-controlled content, and emit URLs or code suggestions, then identity and access control decisions around the human session directly shape the assistant’s blast radius. This is where NHI governance becomes relevant: the assistant is not a human user, but it acts inside a human-authenticated workflow and can expose machine-accessible data. Practical implication: govern assistant privileges as part of access control, not as a separate UI concern.

Practical implication: classify AI assistants inside your access model and bound their effective permissions to the minimum context they need.

Threat narrative

Attacker objective: The attacker aimed to steal private repository data while controlling the assistant’s output to support malicious follow-on actions.

1. Entry occurred through hidden prompt content embedded in a pull request description and surfaced through normal repository viewing flows.
2. Credentialed context was abused because the assistant processed repository data and acted with the victim user’s permissions, exposing private information inside the session boundary.
3. Exfiltration was achieved by encoding sensitive repository contents into generated output and image delivery paths that could be recovered by the attacker.
4. Impact was silent disclosure of secrets and source code from private repositories, plus attacker influence over Copilot’s responses and suggested content.

Breaches seen in the wild

• Gemini CLI prompt injection flaw 2025: Tracebit showed a poisoned README could make Gemini CLI run hidden commands and exfiltrate developer secrets; Google fixed it in 0.1.14.
• Gemini AI Breach — Google Calendar Prompt Injection: Gemini AI assistant prompt injection attack leaks sensitive Google Calendar data.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

AI assistants inside development platforms need identity-grade governance, not just content filters. The article shows that assistant behaviour is shaped by repository permissions, session context, and trusted rendering paths, which means the security boundary extends well beyond the model prompt. Once an assistant can read private code and generate outbound content, access control becomes part of the AI safety problem. Practitioners should treat assistant context as governed access, not convenience text processing.

Prompt injection in developer tooling is a trust-boundary failure, not a novelty attack. The hidden comment technique matters because it exploits ordinary collaboration features to feed instructions into a privileged workflow. That means security teams must evaluate which inputs can become model instructions, not just which ones are visible to users. The right mental model is instruction contamination of a shared workspace, not a simple chat exploit.

Repository context creates a new blast-radius problem for AI-enabled engineering workflows. When a model can see source code, commits, and pull requests, any successful injection may expose more than text output. The issue is not only exfiltration, but also response integrity, because malicious code or links can be injected into the assistant’s recommendations. Practitioners should narrow assistant context to the minimum necessary and monitor for overbroad repository reach.

Content delivery controls must be tested against AI-era exfiltration paths. The CSP bypass described here shows that conventional browser controls can be undermined when trusted proxy infrastructure is repurposed to move data out of the environment. That broadens the scope of secure design: it is not enough to block arbitrary external requests if sanctioned paths can still encode sensitive material. Teams should validate proxy and rendering services against data-smuggling patterns.

Governance for AI agents and assistants should start with the permissions they inherit. Even when a tool is not autonomous in the strict sense, it can still operate as a high-risk non-human participant in a human workflow. The identity question is therefore central: what can the assistant access, what can it emit, and what can it influence on the user’s behalf? Practitioners should map assistant permissions into existing IAM and NHI governance models.

From our research library:

• Internal repositories are 6x more likely to contain secrets than public ones (32.2% vs 5.6%), contradicting the assumption that private repos are safe, according to the State of Secrets Sprawl 2026.
• Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
• Read next: Ultimate Guide to NHIs — What are Non-Human Identities

What this signals

Instruction contamination is the right concept for this class of attack. The problem is not simply that a model was tricked, but that untrusted collaboration content was allowed to become executable guidance inside a privileged workflow. That means the control question shifts from “can the assistant answer?” to “which inputs can become instructions and with what effective permissions?”

AI assistants need permission boundaries that are tighter than the humans around them. If a user can open a private repository, the assistant inherits a broad context surface unless the platform deliberately shrinks it. Only 5.7% of organisations have full visibility into their service accounts, which is a reminder that identity inventory gaps also apply when the “account” is an assistant operating inside a developer session.

For practitioners

• Constrain assistant-visible repository context Limit which pull request fields, comments, issue text, and file types can be passed into AI assistants, especially in private repositories and high-trust projects.
• Block hidden instruction surfaces Review features such as hidden comments, rendered markdown, and other collaboration artifacts that can carry instructions without obvious user visibility.
• Test trusted rendering and proxy paths Validate whether image proxies, markdown renderers, or other sanctioned delivery services can be abused to encode and exfiltrate sensitive data.
• Treat AI assistants as governed access subjects Document the permissions an assistant inherits from the user session and align them with identity, access, and secrets controls already used for sensitive workloads.

Key takeaways

• The core failure is not just prompt injection, but the collapse of trust boundaries between collaboration content, repository context, and assistant output.
• The article shows how trusted rendering infrastructure can be abused to move sensitive data out of a private development environment.
• Governance needs to treat AI assistants as privileged workflow participants whose permissions, inputs, and outputs must be explicitly bounded.

Key terms

• Prompt Injection (Agentic): An attack where malicious instructions are embedded in content that an AI agent reads, causing the agent to execute unintended actions using its own legitimate credentials. A primary vector for agent goal hijacking and identity abuse.
• Assistant Context: Assistant context is the collection of repository data, messages, files, and session inputs that an AI assistant can read when generating a response. The broader the context, the larger the attack surface for leakage, instruction contamination, and unintended privilege use.
• Privilege Inheritance: Privilege inheritance occurs when a system uses the permissions of the human or service identity that launched it. For agents, this means the workload can access anything the parent role can access, which makes entitlement design more important than the model’s natural-language capabilities.
• Content Security Policy Directive: A Content Security Policy directive is a rule in the policy that tells the browser what kind of content may load and from where. Directives such as script-src or img-src narrow execution and retrieval paths, helping teams define a trusted set of sources and reduce exposure to injected content.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. It is a useful fit for teams deciding how to govern AI assistants, service accounts, and other non-human identities.