GitLost: How Researchers Tricked GitHub's AI Agent Into Leaking Private Repos

TL;DR
Security researchers discovered a prompt injection vulnerability in GitHub's Agentic Workflows that allows attackers to extract private repository contents through public issues.
Security researchers at Noma Labs disclosed a critical vulnerability in GitHub's Agentic Workflows feature that allows unauthenticated attackers to extract data from private repositories. The attack requires nothing more than posting a crafted GitHub Issue in any public repository within an organization.
What Is GitLost?#
GitLost is the name researchers gave to a prompt injection vulnerability affecting GitHub's new Agentic Workflows system. The core issue: insufficient trust boundary enforcement between untrusted user input and AI agent instructions.
When an organization enables Agentic Workflows with cross-repository access, the AI agent can read files from both public and private repositories. The problem is that the agent also processes the content of GitHub Issues - which anyone can create on public repos.
How the Attack Works#
The attack chain is straightforward:
- Identify target: Find an organization with GitHub Agentic Workflows enabled and cross-repository access configured
- Create malicious issue: Post a GitHub Issue in any public repository within that organization
- Trigger the agent: When the workflow assigns the issue, the AI agent activates
- Extract data: Hidden instructions in the issue body direct the agent to fetch private repository contents
- Exfiltrate: The agent posts the extracted data as a public comment
The researchers demonstrated successful extraction of README files and code from private repositories, with the agent dutifully posting the contents as public issue comments.
The "Additionally" Bypass#
One detail from the disclosure stands out. GitHub appears to have implemented guardrails to prevent obvious prompt injection attempts. The researchers found that adding the word "Additionally" to their payload bypassed these protections, forcing the model to reframe output rather than refuse.
This highlights a fundamental problem with LLM guardrails - they are essentially more prompts, and prompts can be overridden with... more prompts.
What HN Is Saying#
The Hacker News discussion (280+ comments at time of writing) is filled with developers debating whether this is a GitHub vulnerability or a user misconfiguration issue.
One commenter framed the core problem clearly:
"Who thought having a LLM with access to private information, with public access to ask it questions, would ever be a secure process?"
Several commenters pointed out this is analogous to setting up a CI job with access to secrets and running it on public PRs. If you configure GitHub to allow public code or LLM instructions to run in contexts with access to sensitive data, that data will leak.
The discussion around guardrails was particularly pointed:
"LLM guardrails are either just written prompts as in 'Please do not bad stuff :(' or other LLMs verifying that the first LLM didn't do some bs. Both methods do not work sufficiently as time shows again and again."
Another commenter offered a succinct take on the architectural issue:
"The answer is you should not allow LLMs access to untrusted input and sensitive data at the same time."
A few developers noted that the proper fix is for GitHub to prevent agentic workflows from executing in a public repo context if they also have private repo access. Several mentioned they're moving to self-hosted alternatives like Forgejo.
The SQL injection comparison came up repeatedly, with commenters pointing out a key difference: SQL injection is fully mitigated by prepared statements. There is no equivalent "prepared statement" solution for prompt injection.
Read the full thread at https://news.ycombinator.com/item?id=48827858.
Why This Matters#
This vulnerability illustrates what security researcher Simon Willison calls the "Lethal Trifecta" - the dangerous combination of:
- An AI agent with access to sensitive data
- The ability to receive instructions from untrusted sources
- The ability to take actions (like posting comments)
Any two of these might be acceptable. All three together creates an exploitable system.
GitHub's Agentic Workflows shipped with all three by default. Organizations that enabled cross-repository access effectively gave every GitHub user on the internet a channel to query their private repositories.
Recommendations#
The researchers and HN commenters suggest several mitigations:
For organizations using GitHub Agentic Workflows:
- Review cross-repository permissions immediately
- Restrict agentic workflows to private repos only, or remove private repo access entirely
- Consider whether the workflow needs to respond to issue content at all
For anyone building AI agent systems:
- Never treat user-controlled content as trusted instructions
- Minimize agent permissions to the absolute minimum required
- Separate agents that handle untrusted input from agents with access to sensitive data
- Implement hard permission boundaries, not just prompt-based guardrails
For the industry:
- Stop shipping AI features with maximum permissions by default
- Recognize that guardrails are not security boundaries
- Accept that prompt injection is currently unsolvable at the model layer
The Bigger Picture#
This is not the first AI agent security incident, and it will not be the last. As one HN commenter noted, we are in "the wild west phase of agent usage."
The pattern is now well-established: a company ships an AI feature with broad permissions, researchers find a prompt injection path, the company patches that specific attack, and researchers find another. The underlying architecture - mixing untrusted input with trusted instructions in the same context window - remains unchanged.
Until the industry develops architectural solutions (not just guardrails) for separating instructions from data in LLM contexts, every agent system that processes untrusted input while holding sensitive permissions is a vulnerability waiting to be discovered.
Continue Reading#
- 13.5 Million Copilot Sessions: What Production Coding Agent Traffic Actually Looks Like
- DCAS: Why Fine-Tuned Coding Agents Fall Apart When You Switch Scaffolds
- The DD Stack Cookbook: Five Recipes That Compose
Sources#
- GitLost: We Tricked GitHub's AI Agent into Leaking Private Repos - Noma Security
- Hacker News Discussion
- Simon Willison's Lethal Trifecta Talk - Referenced in HN comments
Get the next deep dive like this in your inbox
One email a week on News and the rest of the AI dev stack. Free.
Read next on AI coding tools
GitHub Stacked PRs Hit Public Preview: Small Reviews for the Agent Era
GitHub's stacked pull requests went into public preview on July 30. Stacks turn one large change into an ordered chain of small, reviewable PRs with one-click merge, plus a gh-stack skill for coding agents.
7 min readA Security Camera Shipped a GitHub Admin Token in Its Login Page
A security researcher found a GitHub personal access token with admin privileges to hundreds of repos baked into Hanwha Vision camera firmware. The cause: a Vite build leaking process.env into production.
6 min readVercel Sandbox Gets a Real Network Boundary: Why Egress Control Is the Missing Half of Agent Security
Vercel Sandbox now polices all outbound traffic on the host, outside the microVM, with SNI-based domain policies, CIDR rules, host-level credential injection, and a deny-all default. Here is why a network boundary is the half of agent isolation that VM escapes missed.
6 min readNew here? Start with
Technical content at the intersection of AI and development. Building with AI agents, Claude Code, and modern dev tools - then showing you exactly how it works.








