I do not usually get dramatic about GitHub Issues.
In most teams, an issue is boring infrastructure: bug reports, meeting follow-ups, half-shaped feature requests, and the occasional “can someone check this?” note that sits there longer than anyone wants to admit.
GitLost is uncomfortable because it turns that boring surface into something much more interesting: an instruction channel for an AI agent.
On July 6, 2026, Noma Security published a report called “GitLost: How We Tricked GitHub’s AI Agent into Leaking Private Repos.” According to Noma’s PoC, the vulnerable setup involved GitHub Agentic Workflows, where an agent could read a public GitHub Issue, use configured tools, access repository content, and then post a response back to the issue.
The attacker’s entry point, in the reported case, was not a stolen token or a compromised maintainer account. It was a crafted issue in a public repository that belonged to the same organization as the private repository being targeted.
That is the part worth sitting with for a minute.
This was not a classic “someone leaked a secret in CI” story. It was closer to a workflow design failure: untrusted text entered through a public collaboration feature, and an agent with broader access treated that text as something it could act on.
GitHub’s own Agentic Workflows documentation helps explain why the boundary is subtle. A workflow is written as a Markdown file with frontmatter for things like triggers, permissions, safe outputs, and the AI engine. The Markdown body contains natural-language instructions the agent follows when the workflow runs. As of the documentation checked on July 8, 2026, GitHub lists multiple supported engines, including GitHub Copilot, Anthropic Claude, OpenAI Codex, and Google Gemini.
That design is useful. It is also exactly why the line between “workflow instruction” and “issue content being inspected” has to be very clear.
In the GitLost PoC described by Noma, the workflow was triggered when an issue was assigned. The workflow read the issue title and body, and the agent was allowed to add a comment. Noma says the tested workflow also had read access to other repositories in the organization. The crafted issue asked about the README in the current public repo and then asked about the same file in another repo. The PoC issue referenced by Noma is sasinomalabs/poc issue #153.
I am intentionally not turning that into a copy-paste attack recipe. The defensive lesson is already clear enough: if an agent can read private repository content and can write into a public issue comment, then a public issue can become both the input path and a potential exfiltration path.
This is why I do not think GitLost is only a “prompt injection” story. That label is accurate, but it can make the problem sound smaller than it is.
The agent did not need to break into GitHub in the usual sense. In the reported configuration, it followed instructions inside context it was already allowed to read, then used an output channel it was already allowed to use.
That is a different review problem from the one many teams are used to.
For traditional automation, we usually ask:
What event triggers this workflow?
What token does it run with?
Which APIs can it call?
Can it write to the repo?
Can it publish comments, artifacts, or pull requests?
Those questions still matter. But agentic workflows add another one:
Whose text is allowed to become an instruction?
A GitHub Issue body is user-controlled content. So is a pull request description. So is a comment thread. So is a Markdown file from a repository the agent is asked to inspect.
In older automation, those were usually strings passed into scripts. In agentic automation, those strings may be summarized, prioritized, interpreted, mixed with system instructions, or accidentally followed.
That is the shift.
The context window is not just memory. It is part of the attack surface.
If I were reviewing an agentic GitHub workflow tomorrow, I would start with the access map.
First, I would list every trigger. From a security review perspective, an issue assignment trigger is very different from a manual dispatch by a maintainer. Anything triggered by public or semi-public user input deserves extra attention.
Second, I would list every repository the agent can read. GitHub documentation describes permission controls and safe output mechanisms, but “read” should not be treated as harmless by default. Read access can create a potential leakage path when it is combined with broad repository scope and a public output channel.
Third, I would review safe outputs as data-leak controls, not just write-operation controls. Allowing an agent to add a comment may feel safer than allowing it to push code. In a case like GitLost, a public comment is exactly where sensitive content can escape.
Fourth, I would separate trusted instructions from untrusted content in the workflow design. The agent should treat issue text as data to inspect, not authority to obey. That sounds obvious until you see prompts that effectively say, “read the issue and do what it asks.”
Fifth, I would add a human checkpoint before any agent output that includes repository content, cross-repository summaries, private project names, or anything that looks even slightly secrets-adjacent.
Some practical controls are boring, which is usually a good sign:
Use the narrowest permissions you can.
Avoid giving issue-triggered workflows access to unrelated private repositories.
Use repository allowlists for agent tools.
Treat public issues, PR descriptions, comments, and artifacts as possible exfiltration sinks.
Log cross-repository reads by agent workflows.
Add prompt-injection test cases to workflow review.
Use harmless canary files in private repos to test whether an agent repeats content into public channels.
Review imported or third-party agentic workflows before enabling them.
None of this requires panic. It does require teams to stop treating “the agent only has read access” as a satisfying answer.
Read access plus public output can still create a leak, depending on the workflow configuration.
The useful thing about GitLost is that it makes the failure visible. A lot of AI agent security discussion still floats around abstract words: jailbreaks, autonomy risk, hidden prompts. This case is easier to reason about. A public issue contained untrusted instructions. An agent had access the issue author should not have had. The output channel was public. According to Noma, private README content was exposed through that path.
That is not a benchmark problem.
It is a boundary problem.
As more teams wire agents into GitHub, Jira, Slack, CI, docs, ticket queues, and internal search, this pattern will show up in different shapes. The question will not only be “can the model follow instructions?” It will be “whose instructions are allowed to matter?”
For me, that is the practical takeaway from GitLost.
Before giving an agent access to private repositories, decide what public text is allowed to ask it to do. Before letting it comment publicly, decide what private context it is allowed to repeat. And before calling a workflow safe because it cannot push code, look at where it can speak.
An agent that can read privately and speak publicly may be crossing a trust boundary, depending on how you configure it.
Top comments (0)