A public issue can trick GitHub Agentic Workflows into leaking the contents of an organization’s private repositories, researchers at Noma Security have shown.
The attacker needs only to open a normal-looking issue on a public repository, with no stolen credentials and no access to the organization. If that organization has given the agent read access across its repositories, private ones included, the issue can steer it into pulling private contents into a public comment.
Noma calls the technique GitLost. The target is GitHub Agentic Workflows, a feature now in public preview that GitHub launched in February. Instead of writing automation scripts, you write instructions to an AI agent in plain English in a Markdown file. The agent reads issues and pull requests, runs tools, and replies on its own.
It can be powered by GitHub Copilot, Anthropic’s Claude, Google Gemini, or OpenAI Codex. Workflows are read-only by default, but an organization can hand one a token with read access across its repositories to give it cross-repo context, private ones included.
That grant is the setup GitLost turns against it.
How the trick works
The weakness is a well-known one: indirect prompt injection. An AI agent cannot reliably tell the difference between instructions from its owner and instructions hidden inside the content it happens to read. So if an attacker writes those instructions into an issue, the agent may simply follow them.
In Noma’s proof of concept, the malicious issue was dressed up as a routine request from a VP of Sales after a customer meeting. The workflow it hit was set to wake up when an issue is assigned, read the issue, and reply with a comment. It also had read access to the organization’s other repos.
Once a routine automation assigned the issue, the agent pulled a private repository’s README and pasted it into a public comment on the issue.
GitHub built guardrails to stop exactly this. In its own documentation, the company warns that “AI agents can be manipulated by prompt injection, malicious repository content, or compromised tools,” and the product ships with sandboxing, read-only tokens by default, input cleaning, and a threat-detection step that scans an agent’s proposed output before it posts.
Noma reported that in its test, a one-word change was enough to slip past. Prefixing the malicious instruction with “Additionally” led the model to treat it as a follow-on task, not something to refuse, and the guardrail let it through.
Why is this one different?
What sets GitLost apart is what the attacker gets to control. “Earlier prompt injection examples were largely about manipulating what an agent said,” Sasi Levi, Security Research Lead at Noma Security, told The Hacker News. “GitLost is about manipulating what an agent does with its permissions.”
The agent here, he said, is not a chat window but a credentialed actor sitting inside an organization’s CI/CD-adjacent infrastructure, with read access spanning repos the attacker cannot see. It touches no server, needs no stolen credentials, and does not require write access to anything private. The attacker only has to open a public issue.
The setup fits what developer Simon Willison named the “lethal trifecta”, and Levi uses the same term: an agent that can reach private data, takes in untrusted outside content, and has a way to send data out. Combine all three, and you have a leak path.
This is not the kind of bug a patch closes; as Levi frames it, it is a structural consequence of giving AI agents standing credentials while having them read attacker-reachable text.
Why does this keep happening
GitLost is the latest in a run of the same kind of attack, and THN has reported several in recent months. A flaw in Anthropic’s Claude Code GitHub Action let a single malicious issue push the agent into leaking secrets and seizing write access to a repository.
Orca Security’s RoguePilot used a hidden prompt in a GitHub issue to make Copilot leak a repository’s privileged token. The GitHub-agent version of the problem goes back to at least May 2025, when Invariant Labs showed that a public issue could push an agent connected to GitHub’s MCP server into reading a private repo and leaking it through a pull request; the researchers called it architectural, with no server-side patch to close it.
A cross-vendor study named Comment and Control then tricked the Claude Code, Gemini CLI, and GitHub Copilot agents into leaking their own API keys through issue and pull-request text, slipping past GitHub’s added runtime defenses along the way.
What to do now
Noma disclosed GitLost to GitHub and published its findings with the company’s knowledge. Exposure is limited to organizations that have enabled the preview and wired an agent to read untrusted public input while holding read access to private repositories and are able to post in public.
What an attacker could pull depends on what the agent’s token can see, from proprietary source code to internal keys, design documents, or CI/CD secrets. As Levi puts it, scope is what matters most: an agent token scoped to the single repository it triages is “far less dangerous than one issued broad org-wide read access” for convenience.
In practice, that cross-repo access comes from a personal access token the organization sets up, so scope the token to the one repository the workflow triages rather than the whole organization. Writes flow only through declared safe outputs, so limit what a public-facing workflow can post, because the comment it produces is the exfiltration channel. Restrict which authors’ content the agent will act on, and gate its outputs behind human review.
GitHub’s threat-detection step scans an agent’s output before it posts, but Noma’s one-word bypass is a reminder that a filter is a backstop, not a boundary.
GitHub, like the other vendors, built guardrails for exactly this class of attack, and a one-word change bypassed them. Researchers and the vendors themselves keep filing the result under “architectural limitation,” and Levi’s point is why the label sticks: in natural language, there is no clean line between data and instruction the way there is in SQL, so the fix leans on architecture rather than filtering the injection away, on isolation, scoped credentials, and staged review.
Until that boundary exists, any agent that reads private data, takes in untrusted input, and can post in public is one cleverly worded issue away from a leak.
