By NHI Mgmt Group Editorial TeamDomain: Breaches & IncidentsSource: LEGIT SecurityPublished October 8, 2025

TL;DR: A critical GitHub Copilot Chat flaw let a researcher silently exfiltrate secrets and source code from private repositories, and steer responses toward malicious output, using remote prompt injection plus a CSP bypass built on GitHub infrastructure, according to LEGIT Security. The issue shows that AI assistants embedded in developer workflows can inherit repository access and become identity-sensitive attack surfaces, not just productivity features.


At a glance

What this is: This is an analysis of a CVSS 9.6 GitHub Copilot Chat vulnerability that enabled silent secret and source-code exfiltration from private repositories through remote prompt injection and a CSP bypass.

Why it matters: It matters because AI assistants that operate with repository permissions can turn hidden content into an access-control failure, forcing IAM, PAM, and NHI teams to govern assistant context, not just human users.

By the numbers:

👉 Read LEGIT Security's analysis of the GitHub Copilot Chat vulnerability


Context

GitHub Copilot Chat is a good example of how AI-assisted development expands the identity and access boundary inside engineering workflows. When an assistant can read repository context, render content, and act on behalf of the user, hidden instructions and permission inheritance become security issues rather than usability details. In this case, the core problem is not code completion itself but the combination of repository access, prompt injection, and data exfiltration through trusted infrastructure.

For IAM and NHI practitioners, the important lesson is that AI assistants can behave like privileged runtime actors even when they are not formally treated as identities. That means access scope, content provenance, and tool-mediated action need governance at the same level as service accounts, API tokens, and other non-human actors. This kind of failure is increasingly plausible in developer platforms that blend collaboration, execution, and AI assistance.


Key questions

Q: What breaks when AI assistants can read private repository context without strict content controls?

A: The trust boundary breaks first. Hidden prompts, comments, and rendered content can influence the assistant to reveal data the user never intended to expose. If the assistant can read private repositories and follow attacker-supplied instructions, the result is not just bad output. It is an access-control failure that can leak source code, secrets, or internal logic.

Q: Why do AI assistants in developer tools complicate identity and access management?

A: Because they inherit user permissions while also transforming content into actions or responses. That makes them function like non-human actors with delegated reach, even if they are not formally autonomous. IAM teams have to govern what the assistant can see, process, and render, not only which humans can sign in.

Q: How do security teams know if an AI agent is operating outside its approved role?

A: Teams should compare actual workflow behaviour against the approved use case. Signs of trouble include unexpected record access, unapproved action types, new system paths after an update, or repeated attempts to exceed the intended scope. In healthcare, behaviour review matters as much as entitlement review because unsafe actions often appear first as workflow drift.

Q: Who is accountable when an AI assistant surfaces private code from a cached repository?

A: Accountability usually spans the repository owner, the platform owner, and the team governing indexing or retrieval. The source system may be private, but the cached copy may still be live in another layer. That is why privacy incidents involving code and secrets should be handled as cross-platform access governance failures, not isolated GitHub hygiene issues.


Technical breakdown

How prompt injection crosses from content into assistant behaviour

Remote prompt injection works when an attacker places instructions in content the model is allowed to read, such as a pull request description, issue, or comment. If the assistant treats that content as operational context instead of untrusted input, it can follow attacker-supplied directions and override the user’s intent. In this case, the hidden payload was not a model jailbreak in the abstract. It was a context contamination problem, where a trusted workflow object became a control channel into the AI system.

Practical implication: Treat all user-generated repository content as hostile input to the assistant, not as safe context.

Why CSP bypasses matter in AI-assisted developer tools

Content Security Policy is supposed to limit where browsers can fetch remote content, but assistants that render markdown, proxy images, or rewrite links can introduce alternate paths around that boundary. GitHub’s Camo infrastructure became the delivery mechanism because it provided signed, allowed image retrieval through trusted domains. The technical weakness was not the policy alone, but the combination of HTML or markdown rendering with a proxy that could be repurposed for exfiltration when an attacker controlled what got embedded in the assistant response.

Practical implication: Review every image, link, and markdown rendering path as a potential exfiltration channel, not just a display feature.

Why repository permissions become assistant permissions

Copilot Chat operated with the same permissions as the requesting user, which meant the assistant could read private repositories and surface their contents in responses. That design is convenient for contextual answers, but it also means the assistant inherits the user’s effective access boundary and can be induced to reveal more than the user intended. Once the assistant can search code, format output, and include attacker-controlled URLs, the tool becomes an access broker rather than a passive helper. This is the identity problem behind agentic AI in developer environments.

Practical implication: Map assistant entitlements to the minimum repository scope needed and segment especially sensitive code from AI-enabled workflows.


Threat narrative

Attacker objective: The attacker wanted to extract private repository data and steer the AI assistant into producing content that advanced exfiltration or malicious code delivery.

  1. Entry occurred when the attacker planted hidden prompt instructions inside a pull request description that Copilot Chat could ingest as context.
  2. Escalation happened when the assistant followed those instructions, rendered attacker-controlled content, and used trusted image proxying to create a covert exfiltration path.
  3. Impact was silent leakage of secrets and source code from private repositories, along with the ability to influence Copilot’s responses toward malicious content.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.


NHI Mgmt Group analysis

AI assistants in developer workflows are now governance objects, not just productivity tools. The Copilot Chat issue shows that repository-aware assistants can inherit user permissions and become sensitive to prompt injection, rendering, and proxy abuse. That changes the control problem from model quality to access governance, provenance, and runtime trust. Practitioners should classify assistant pathways as part of the identity and access plane, not as a separate convenience layer.

Prompt injection becomes materially worse when the assistant can reach private code and secret-bearing context. The attack did not need model compromise in the classic sense. It exploited the ordinary assumption that content inside a repo or PR is safe for the assistant to process. This is the kind of trust collapse that OWASP-NHI and AI governance frameworks are meant to challenge, because the control boundary has shifted from human review to machine interpretation.

Context provenance is the named concept security teams need to operationalise. Hidden comments, markdown rendering, and assistant memory all create a provenance problem: the system cannot reliably distinguish user intent from attacker-supplied instructions. Once provenance is uncertain, the assistant should be treated as a constrained NHI with policy limits on what content it may process or act on. The practical conclusion is to govern assistant context the same way teams govern privileged secrets and tokens.

Content rendering is now an exfiltration surface in AI-assisted platforms. The CSP bypass is not just a web security issue, because the payload was embedded in AI-generated output and delivered through trusted infrastructure. That means identity governance teams need to work with application security to classify rendering, link rewriting, and proxying as privileged operations. The field should expect more attacks that combine AI output control with conventional web trust chains.

The security market will increasingly converge around assistant governance, secret exposure, and NHI-style controls. Developer AI is moving into the same risk category as service accounts and automation accounts because it can read, decide, and act with inherited permissions. That will push buyers to ask whether their governance model can observe assistant actions, restrict context, and bound exfiltration paths. The organisations that separate AI convenience from privilege management will be better placed to contain this class of failure.

From our research:

  • The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
  • Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
  • Forward-looking angle: Review the Guide to the Secret Sprawl Challenge for the operational patterns that make secret leakage persist across developer workflows.

What this signals

Context-aware assistants need policy-aware boundaries. The more an assistant can read from repositories, issues, and pull requests, the more it needs explicit rules for what content it may consume and what outputs it may produce. For programmes already struggling with secret sprawl, the practical signal is to align AI assistant governance with the same lifecycle thinking used for credentials, not with ad hoc productivity settings.

Context provenance will become a control requirement in AI-enabled engineering environments. Security teams should expect pressure to prove where assistant input came from, whether hidden content was processed, and how externally fetched material was handled. That aligns closely with the governance logic behind OWASP-NHI and the broader problem of managing non-human runtime behaviour.

AI output channels are becoming exfiltration paths. The combination of assistant-generated markdown, proxy-backed rendering, and inherited repository access means defenders need to inspect what gets rendered as closely as what gets executed. This is a programme-level signal that application security and identity governance can no longer be managed as separate lanes when AI is embedded in the workflow.


For practitioners

  • Restrict assistant access to sensitive repositories Segment private codebases with the highest secret density from AI-enabled workflows, and require explicit allowlisting before repository-aware assistants can access them. The point is to reduce the blast radius of inherited permissions, not just to audit after the fact.
  • Treat hidden markdown and comments as hostile input Apply secure content handling rules to pull requests, issues, and documentation that assistants can ingest. If a platform allows hidden comments, image links, or rich text rendering, assume an attacker can use those paths to shape assistant behaviour.
  • Disable or constrain high-risk rendering paths Review image rendering, link rewriting, and proxy-backed content delivery in AI-assisted interfaces. Where exfiltration is plausible, limit external fetches, strip active content, and require safe render modes for assistant responses.
  • Separate AI assistant permissions from user convenience Do not let the assistant inherit broad access by default. Map each assistant capability to a minimum scope, log the data it reads, and require stronger controls for repositories that contain secrets, credentials, or unreleased code.

Key takeaways

  • The breach shows that AI assistants can turn ordinary repository content into a secret-exposure path when prompt injection and rendering trust are not controlled.
  • The impact is not theoretical because private source code and secrets were exposed through a CVSS 9.6 flaw that used GitHub infrastructure against itself.
  • The limiting control is context governance, which means narrowing assistant permissions, constraining rendering, and treating hidden content as untrusted input.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Agentic AI Top 10, OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
OWASP Agentic AI Top 10Prompt injection and tool-mediated output control align with agentic AI abuse patterns.
OWASP Non-Human Identity Top 10NHI-01Repository-aware assistants inherit non-human access and need governed identity boundaries.
NIST AI RMFMANAGEAI assistant leakage is a risk management and control enforcement issue.
MITRE ATT&CKTA0006 , Credential Access; TA0010 , ExfiltrationThe attack combined credential-sensitive data access with covert data exfiltration.
NIST CSF 2.0PR.AC-4Least-privilege access is central when assistants inherit repository permissions.

Treat the assistant as a governed non-human actor and scope access to the minimum necessary repositories.


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.
  • Identity Provenance: Identity provenance is the record of how an agent was created, what authority it received, and what actions it performed over time. It turns agent activity into an auditable chain of trust that supports compliance, incident response, and post-event accountability.
  • Assistant Permission Inheritance: Assistant permission inheritance occurs when an AI tool operates with the same access as the signed-in user or workflow. That can be useful for accurate answers, but it also means the assistant can read, reveal, or transform data inside the user’s effective access boundary.
  • Exfiltration Channel: An exfiltration channel is any route through which data can leave an organisation, including browsers, cloud apps, email, collaboration tools, removable media, and AI assistants. Effective governance requires visibility across all relevant channels, not just endpoints, because attackers and insiders often choose the path that is least monitored.

What's in the full article

LEGIT Security's full analysis covers the operational detail this post intentionally leaves for the source:

  • The exact prompt-injection technique used inside pull request content and how it propagated into Copilot Chat responses
  • The Camo-based CSP bypass flow and the image-rendering behaviour that made covert exfiltration possible
  • The proof-of-concept logic used to encode private repository content and leak it through generated URLs
  • The remediation step GitHub used to contain the issue and what that change means for AI assistant design

👉 The full LEGIT Security post covers the prompt injection chain, CSP bypass, and exfiltration proof of concept.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and identity lifecycle control. It is designed for practitioners who need to govern non-human access across modern security programmes.
NHIMG Editorial Note
Published by the NHIMG editorial team on August 19, 2026.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org