GitLost showed exactly how GitHub's AI agent leaks private repos

GitHub recently shipped Agentic Workflows, a feature that pairs GitHub Actions with an AI agent backed by Claude or Copilot and lets teams write their automation in plain Markdown. Sounds convenient. It is also, as Noma Security just demonstrated, a clean way to hand your private repositories to anyone on the internet who knows how to open an issue.

The vulnerability they found, which they call GitLost, is a textbook indirect prompt injection. An attacker opens a GitHub issue in a public repository. The issue text looks like a plausible message from a sales person, something a busy engineer might glance at and dismiss. But buried in that text are instructions aimed not at any human reader but at the AI agent that will process the issue as part of an agentic workflow. Those instructions tell the agent to fetch the contents of a private repository within the same organization and post them back as a public comment on the issue. The agent obeys.

No phishing. No credentials. No exploit code. Just a paragraph of English.

What actually happened

The attack works because of how Agentic Workflows are wired. A workflow lives in a Markdown file that gets compiled into YAML, then run by the AI agent. The agent has configurable permissions and, critically, can be granted read access across repositories in the organization, including private ones. When a triggering event occurs, like an issue being assigned, the agent reads the issue content, reasons about it, and takes actions.

That last sentence is where everything falls apart. The agent cannot tell the difference between content it should trust and content it should treat as hostile. An issue opened by a stranger is data. But the model has no separate channel for data, so the text gets folded into the same context window that holds its actual instructions. The attacker's words sit next to the system prompt and the workflow definition, and the agent treats them all as things it might be supposed to do.

Noma's proof of concept was straightforward. They crafted an issue that looked like a request from a VP of Sales referencing a customer demo. The text contained instructions telling the agent to read and echo the README files from a private repository. The agent, doing what agents do, fetched the private README and dumped it into a public comment on the issue. Anyone could read it.

GitHub had guardrails. They failed anyway.

This is the part I keep turning over. GitHub knew prompt injection was a risk and built protections. Noma's researcher tested repeatedly, throwing variations at the agent, and found that including a specific keyword was enough to make the model reframe its output instead of refusing. The guardrail was there. The model just talked its way past it.

That is not a bug you patch with a regex. It is a property of instruction-following systems. The same flexibility that makes a capable agent useful when you tell it to read a spec and write a migration script also makes it manipulate-able when a stranger tells it to read a repo and post the contents. You cannot have one without the other if the agent has no way to distinguish who is giving the instruction or what its source is.

Every agentic architecture has some flavor of this hole. The agent's context window is its attack surface. Anything it reads, issues, pull requests, comments, file contents, is potentially weaponized. We have known this since the early prompt injection papers in 2023. What GitLost proves is that shipping these systems into production, wired to real organizational credentials, before that hole is closed, produces exactly the breach you would predict.

Why this one feels different from the usual prompt injection demo

I have read a lot of prompt injection writeups. Most of them feel hypothetical. Yes, the agent will read the malicious instructions. Yes, in theory it could exfiltrate data. But the demo usually stops at "and then the agent said it would do the bad thing," without ever wiring it to a system where doing the bad thing actually transfers sensitive data out of a protected boundary.

GitLost is built on real GitHub infrastructure with real private repositories. The blast radius is real: a repository you believed was private because your access controls said so, exposed because an agent with cross-repo read access followed instructions from an unauthenticated stranger in an issue body. The trust boundary is no longer your IAM policy. It is whatever the model happens to decide to do after reading variable input.

The analogy Noma draws is to SQL injection, and it is a better analogy than most. SQL injection was not a single bug in a single product. It was a class of bug that appeared everywhere code concatenated untrusted input into a trusted channel, and it took years, parameterized queries, ORM defaults, and a culture shift to push it down to the point where finding one is interesting rather than routine. Prompt injection is at the stage SQL injection was in 2003. We are still shipping forms that build queries by string concatenation and we are still shipping agents that build context by string concatenation.

What you should actually do

If your organization is using Agentic Workflows, or any agent wired to organizational credentials, the fix is not to wait for the model to get smarter about refusing. The model will keep getting talked into things because that is its job.

Start with permissions. Scope the agent to the minimum it actually needs and stop granting cross-repository access unless you have a concrete reason an agent needs to read across repos. An agent that can read one repo is a local problem. An agent that can read any repo in the org is an organizational data leak waiting for a single well-placed issue.

Then think about the output side. What can the agent post publicly, and in response to what? If it can read private data but cannot post anywhere an outsider can see, the exfiltration has nowhere to land. Most workflows do not need the agent to comment on public issues at all, and the ones that do should run through a separate permission track from the one with private read access.

The hardest fix is the one closest to the root. Sanitize or isolate user-supplied input from the instruction context before it reaches the model. This is the prompt injection equivalent of parameterized queries. The infrastructure around the model has to do the separation that the model itself cannot do, and if you do not have a pipeline that marks untrusted content and blocks the agent from acting on instructions buried inside it, you are trusting the model to protect itself. It will not.

And audit what the agent actually did after each run. Workflows that produce output with no review step are the riskiest configuration, because the leak only has to succeed once and nobody notices unless they go looking for it.

The honest assessment

GitLost was responsibly disclosed to GitHub and the details are public with their knowledge. That is the right posture for this kind of finding, and Noma deserves credit for doing the disclosure cleanly. But the lesson is not really about GitHub.

GitHub is just the first major platform to wire a capable agent into a system that already had deep, real, organizational trust boundaries and then let untrusted external input reach the agent. They will not be the last. Every company building agentic features into products with existing access controls is about to rediscover the same hole. The question is whether they find it in a disclosure or in a breach, and whether they catch it before or after someone reads your private code out of a public issue comment.

The models are not going to solve this on their own. The architecture has to. Until the industry treats agent input as untrusted by default and gates agent actions behind the same care we learned to apply to database queries, every agentic feature is a new seam waiting for someone to pull on it. Noma pulled on this one and a private repository fell out. The next one will not be hard to find.