SURIQ
The private repository did not get hacked. It got read out loud, on command, by an assistant working exactly as designed. Researchers at Noma Security demonstrated that a stranger with no account, no credentials, and no code could open an ordinary issue on one of your public repositories and walk away with the contents of a private one. They call it GitLost, and the reason it matters is not the single flaw. It is that GitLost is a reusable blueprint for every place an AI agent touches untrusted text while holding real keys.
GitHub's Agentic Workflows, in public preview since February, let a team describe automation in plain English and hand it to a model (Claude, Copilot, or Gemini) that reads issues and pull requests, calls tools, and replies on its own. That is the feature. GitLost is the feature pointed in the wrong direction.
What the researchers actually demonstrated
The chain is short. An attacker opens a public issue whose body carries hidden instructions written as plain prose. When the workflow assigns that issue, the agent reads the title and body as part of its context, and the model cannot cleanly separate content to act on from instructions to obey. In Noma's proof of concept the agent, running with read access to other repositories in the same organization, opened a private repo's README and republished its text as a public comment under the issue. Anyone watching that public repo could then read it.
GitHub does run a threat-detection guardrail meant to catch exactly this. As The Hacker News reported, the researchers got past it by prefixing their hidden instruction with a single innocuous connective word, which nudged the model to treat the payload as a follow-on task rather than a request to refuse. One word. That detail is the whole argument against relying on such filters, and it comes back below.
Why a patch does not close this
There is no version number to bump here. Noma's research lead, Sasi Levi, framed prompt injection as the SQL injection of agentic AI: a whole category of failure, not a single defect. The comparison is apt, and it carries a warning most of the coverage skipped. SQL injection was never fixed by a patch either. It was contained by architecture: parameterized queries, least privilege, input that can never reach the interpreter as code. Agentic systems sit roughly where web apps sat twenty years ago, and the same discipline is what will contain them.
Strip GitLost to its mechanics and three conditions had to be true at once for it to work. Every agentic-CI leak we have written up needs the same three:
- Standing access to private data. The workflow token could read private repositories across the organization, so there was something worth stealing in reach.
- Exposure to attacker-controlled text. Anyone could open a public issue, and the agent read that text as if it were trusted instruction.
- A channel the attacker can read. The agent could post a public comment, so the stolen data had somewhere to land in the open.
Remove any one leg and the attack collapses. That is not a GitHub-specific observation. It is a checklist you can run against your own agent wiring today, and it is the useful thing to carry out of this story.
You will rebuild this on your own runners
The temptation is to read GitLost as a GitHub preview problem and move on. That is a mistake. The pattern is trivial to recreate anywhere you have wired a model into a pipeline: a GitLab CI job that lets an assistant triage merge requests, a self-hosted Gitea instance with a review bot, a homegrown script that hands ticket text to an API with a personal access token stapled to it. In practice the self-hosted versions are worse, because the token is usually an organization-wide PAT (scoping is tedious, so people skip it) and there is no guardrail model in front of it at all. GitHub at least had a filter to bypass. Your internal bot has nothing. We have watched this same shape play out in a poisoned GitHub Actions pull request, in a clean-looking repository that talked a coding agent into a reverse shell, and in a Copilot prompt-injection leak. GitLost is the same lesson wearing a new logo.
Scope the token first, then watch the output
Two moves matter, in order. The first is the single most effective fix available and it needs no model at all: scope the agent's credential to exactly the repository it serves. An agent token that cannot read across the organization turns GitLost from a private-repo breach into a non-event. The injected instruction still runs, but there is nothing cross-repo to hand back. Least privilege beats prompt hygiene for one reason: it survives the next guardrail bypass, and there will always be a next one.
The second move follows from that one-word bypass. Treat a prompt-safety classifier as a speed bump, never as a boundary. If prevention is bypassable by construction, detection is where you catch this, and the place to look is the agent's output. Every public comment, commit, and pull request an agent produces is a possible exfiltration channel, and it should be monitored like egress. A managed detection team watching those output surfaces and hunting for an agent posting file contents it was never asked for will see the leak a content filter waved through. We covered the filter weakness itself when researchers walked a coding agent's guardrail with a rewording; GitLost is the data-exfiltration version of the same crack.
Agentic automation will keep spreading through CI because it saves real time. The teams that come through the next year without an incident will be the ones who decided early that an agent is a program with credentials and an attacker-reachable input, and who scoped it, gated it, and watched it accordingly. GitLost is cheap tuition for that lesson. Pay it now.