Passive prompt injection in GitHub Codespaces exposes repo tokens

At a glance

What this is: This analysis shows how passive prompt injection in GitHub Codespaces can steer Copilot into leaking a privileged GITHUB_TOKEN and enabling repository takeover.

Why it matters: It matters because IAM, PAM, and NHI teams must treat developer content, workspace automation, and AI assistants as part of the same identity and token trust boundary.

By the numbers:

• 17 minutes and as quickly as 9 minutes

👉 Read Orca Security's analysis of passive prompt injection in GitHub Codespaces

Context

Passive prompt injection is a governance failure, not just an AI quirk. In this case, untrusted issue text is processed inside Codespaces and can change assistant behaviour before a human ever reviews the content, which means the primary problem is a broken trust boundary around developer inputs, workspace files, and generated tokens.

For IAM and NHI programmes, the key issue is that the same workspace now contains user-controlled content, auto-executing assistant actions, and a privileged GITHUB_TOKEN. That combination creates a path where repository context becomes an identity control surface, and where secret exposure can lead directly to write access and takeover.

Key questions

Q: How should security teams prevent passive prompt injection in AI-enabled developer workspaces?

A: Treat repository content, issues, and pull requests as untrusted inputs when an AI assistant can act on them. Require confirmation before tool use, restrict automatic instruction following, and separate content reading from command execution. The key control is to stop attacker-controlled text from becoming operational intent inside the workspace.

Q: Why do AI-assisted workspaces increase the risk of token exposure?

A: They collapse multiple trust boundaries into one session. The assistant can read project files, follow links, and create new artifacts while a privileged workspace token is present. If that token can be discovered or exported, access moves from local convenience to repository authority in a single chain.

Q: What breaks when symbolic links are allowed to reach outside the workspace?

A: The workspace boundary stops being a boundary. A link can point from visible project files into shared runtime paths or secret stores, and an AI assistant may read the linked content as part of normal work. That turns file hygiene into an identity and access issue, not just a code organisation problem.

Q: Who is accountable when an AI assistant exfiltrates a repository token from developer tooling?

A: Accountability sits with the organisation that allowed the assistant to process untrusted content, hold privileged tokens, and reach external endpoints without sufficient guardrails. This falls under identity governance, secure developer platform design, and any policy that governs secrets, workspace permissions, and human approval boundaries.

Technical breakdown

Passive prompt injection in Codespaces

Passive prompt injection happens when malicious instructions are embedded in content the model will later read automatically. In GitHub Codespaces, opening an environment from an issue can feed the issue text directly to Copilot, which means the assistant is no longer only responding to developer intent. The attack succeeds because the assistant treats repository content as operational input, not as untrusted data. Once that trust boundary collapses, the model can be steered into tool use, file access, or command execution that benefits the attacker.

Practical implication: Treat issue, PR, and repository text as untrusted inputs to AI assistants and block automatic instruction-following from user-controlled content.

Schema fetching as an exfiltration path

The attack chain uses JSON schema retrieval as a covert outbound channel. When json.schemaDownload.enable is on, the editor can fetch a remote $schema URL for validation and IntelliSense. By placing sensitive data into that URL, the attacker turns a normal metadata lookup into a data leak. This is not a bug in JSON itself. It is a trust assumption failure: the environment assumes schema URLs are benign, while the attacker uses them as a transport layer for secrets.

Practical implication: Disable or tightly constrain automatic schema downloads in AI-enabled workspaces where remote references can be attacker-controlled.

Symlinks and privileged GITHUB_TOKEN exposure

Repository symbolic links can bridge from the visible workspace into files that should remain outside the assistant’s operating scope. In this case, a symlink can point to a shared secrets file, allowing Copilot to read content that the developer did not intend to expose. The environment also provides a privileged GITHUB_TOKEN in the Codespaces context, so file access can quickly become repository-level authority. The technical issue is not just file reading. It is the combination of workspace mounting, link traversal, and default token availability.

Practical implication: Prevent AI tools from traversing symlinks outside the scoped workspace and reduce the privilege available to automatically injected workspace tokens.

Threat narrative

Attacker objective: The attacker wants to exfiltrate a privileged repository token and use it to take over the target repository.

1. Entry begins when an attacker plants hidden instructions in a GitHub Issue that is later loaded into Codespaces and read by Copilot as if it were operational context.
2. Credential access occurs when Copilot is steered to follow a symbolic link and then create a JSON file that causes the privileged GITHUB_TOKEN to be sent to a remote schema endpoint.
3. Impact is repository takeover because the leaked token grants write access that can be used to modify code, content, or workflow state in the foreign repository.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• JetBrains GitHub plugin token exposure — CVE-2024-37051 in JetBrains IntelliJ GitHub plugin exposed GitHub access tokens.

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

NHI Mgmt Group analysis

Developer content is now an identity input, not just a collaboration artifact. When a GitHub Issue can steer an assistant inside Codespaces, repository text becomes part of the control plane for identity actions. That matters because the security model has shifted from human reading content to machine acting on content. Practitioners should treat issue, PR, and commit text as governance inputs with direct execution consequences.

Workspace trust assumptions fail when assistants can combine files, links, and tools in one session. The attack works because the environment assumes workspace scope, symlink boundaries, and generated tokens will stay aligned. They do not when an AI assistant can read context, select a file operation, and then trigger an outbound schema fetch. The implication is that least privilege for developer tooling must account for multi-step assistant behaviour, not just static file access.

Privilege becomes operationally unstable when the same session can discover and export it. The GITHUB_TOKEN in Codespaces is not merely present, it is reachable through the assistant’s runtime path. That creates a runtime governance gap: authority exists long enough to be abused but not necessarily long enough to be noticed in a normal human review cycle. Practitioners should recognise this as identity blast radius inside the development environment.

Hidden content and automatic fetches create a new class of covert exfiltration primitives. HTML comments, symbolic links, and schema retrieval are all legitimate features on their own. Combined through an AI assistant, they become a data-moving chain that bypasses the assumptions behind content review and workspace containment. This is exactly the kind of compound behaviour that OWASP-NHI and zero-trust thinking are meant to surface before developers normalise it.

Prompt injection in developer tooling is a governance problem for both NHI and human IAM. The same attack depends on repository content trust, token scope, and the operational boundaries of a human developer session. That is why this should not sit only with application security teams. Identity teams need to view AI-assisted developer environments as places where NHI authority, workflow automation, and human delegation overlap.

From our research:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, and as quickly as 9 minutes in some cases, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
• DeepSeek accidentally embedded over 11,000 secrets in its training data and left a database exposed online, revealing more than one million sensitive records including chat histories, backend credentials, and API keys.
• For the broader pattern of identity-driven compromise across machine access paths, see 52 NHI Breaches Analysis.

What this signals

Hidden-input attacks will increasingly be treated as identity incidents, not just application-security edge cases. Once assistants can act on repository text, the control question changes from whether a prompt is visible to whether untrusted content can alter execution. Teams should expect more pressure to define approval boundaries, logging, and token scope for AI-enabled development environments.

The practical signal is that workspace privilege, file traversal, and outbound network defaults now need to be reviewed together. A symlink rule, a schema-fetch rule, and a token rule may look unrelated in isolation, but they form one attack surface when an assistant can chain them. That is why the governance model has to move from component controls to session-level containment.

Identity blast radius in developer tooling is becoming a useful concept for security leaders: it measures how far a compromised or over-trusted assistant can move from conversation to code, from code to file access, and from file access to a usable credential. Teams that already map NHI exposure should extend that thinking to AI-assisted IDE and Codespaces workflows.

For practitioners

• Block assistant instruction execution from untrusted repository content Require explicit user confirmation before an AI assistant acts on issue text, PR text, or comments that originated outside the workspace owner. Treat repository-controlled prose as data, not directives, and separate summarisation from tool use.
• Disable or restrict remote schema retrieval in AI-enabled workspaces Turn off automatic JSON schema fetching where possible, or whitelist only approved schema hosts. Remote metadata lookups should not be allowed to carry user-derived data or secrets out of the workspace.
• Stop symlink traversal outside the scoped workspace Audit whether AI tooling follows repository symbolic links into shared or hidden files. Prevent reads that cross from the mounted project tree into runtime secret stores, temp directories, or environment-managed paths.
• Reduce default token authority inside Codespaces Scope automatically generated workspace tokens to the minimum repository permissions required and shorten their usable lifetime. The goal is to make accidental exposure less useful if an assistant or extension can read the token.
• Separate human review from machine execution paths Use policy gates for any assistant action that can create files, open network requests, or alter checked-out code after processing untrusted issue content. Human approval should sit before the action, not after the leak.

Key takeaways

• Passive prompt injection in developer tooling turns untrusted issue text into a live control path for AI-assisted actions.
• The breach chain worked because hidden instructions, symlink traversal, and automatic schema fetching together exposed a privileged repository token.
• The limiting control is not a single scanner or filter, but strict containment of assistant authority, token scope, and outbound fetch behaviour.

Key terms

• Passive Prompt Injection: Passive prompt injection is when malicious instructions are embedded in content that an AI system will later process automatically. The attacker does not need direct chat access. The risk comes from treating untrusted text as operational guidance inside a workflow that can trigger tool use, file access, or network requests.
• Workspace Token: A workspace token is a credential issued to a cloud development environment so it can access repository resources on behalf of the user or session. In AI-enabled workspaces, that token becomes high-value because the assistant may be able to read, create, or export it if guardrails are weak.
• Identity Blast Radius: Identity blast radius is the amount of damage an identity can cause if it is over-trusted, leaked, or misused. In developer tooling, it measures how far a session can move from conversation to code changes, file reads, outbound requests, and finally to usable credentials or repository takeover.

Deepen your knowledge

Passive prompt injection, workspace token scope, and AI-assisted file access are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for developer environments that combine human workflows with machine execution, it is worth exploring.

This post draws on content published by Orca Security: passive prompt injection in GitHub Codespaces and repository token exfiltration. Read the original.