Noma Labs researcher Sasi Levi said a public GitHub Issue could steer GitHub's Agentic Workflows into reading from private repositories and posting the results back into a public thread, a disclosure that lands less than a month after GitHub moved the feature into public preview.
In a July 6th blog post, Levi named the technique GitLost and framed it as an indirect prompt-injection flaw in the way GitHub's AI workflow agent handled issue text. Noma's test case required no GitHub credentials for the attacker beyond the ability to open an issue in a public repository tied to an organization whose workflow agent had read access to other repositories, including private ones.
The narrow technical path matters. GitHub Agentic Workflows are designed to let teams write repository automations in Markdown and run them as GitHub Actions with an AI coding agent carrying out the work. GitHub's own documentation describes the feature as AI-powered repository automation, with frontmatter defining triggers, permissions, tools and safe outputs, and the Markdown body carrying the natural-language instructions. Supported engines include GitHub Copilot, Anthropic Claude, OpenAI Codex and Google Gemini.
Noma's finding hits the gap between that model and the way software collaboration actually works. Issues, pull requests and comments are often attacker-controlled input. Agentic workflows treat the same material as context for the agent. Once the agent has both access to code and permission to publish a response, a prompt-injection attack can turn a routine triage workflow into an exfiltration channel.
Levi's proof of concept used a workflow configured to trigger on issues.assigned
, read the issue title and body, and use an add-comment
tool. Noma said the workflow also had read access to other repositories in the same organization. The public issue body looked like a sales follow-up, then asked for the contents of a README in the public poc
repository and, with the word "Additionally," asked for the same file in the private testlocal
repository.
The public GitHub issue cited by Noma was opened on April 2nd and contains that request in plain text: a normal-looking message from a supposed sales executive, followed by a request for README contents from poc
and testlocal
. The workflow run tied to the demonstration was manually triggered the same day, succeeded in 4 minutes and 24 seconds, and shows the agent, threat-detection and safe-output stages in the run summary.
Noma said the agent fetched README content from sasinomalabs/poc
, attempted sasinomalabs/remote-ping
, and pulled README content from sasinomalabs/testlocal
, which Noma identified as private. The alleged leak path ended with the agent posting the retrieved data as a comment on the public issue. The company also said variants of the test worked across other workflow actions, though the published proof centers on the issue-assignment trigger.
The most telling detail is the guardrail bypass. GitHub's Agentic Workflows are marketed with several containment layers. When GitHub announced the public preview on June 11th, it said agents respect integrity-filter rules, run read-only by default, execute in sandboxed containers behind an Agent Workflow Firewall, and pass outputs through safe-output validation plus a threat-detection job before changes are applied. Noma said those controls failed in its test when the model's behavior was shifted by the word "Additionally," which caused the agent to reframe the request rather than refuse it.
That does not mean every GitHub Agentic Workflow leaks private repositories. The exploit depends on a specific configuration: a workflow that ingests untrusted public issue text, an agent with enough repository read scope to access private code, and an allowed output path that can publish material back to a public issue. GitHub's docs say workflows are read-only by default and write operations are limited to declared safe outputs. Noma's test shows how read access and safe comments can still be enough to leak data when the comment is the exfiltration surface.
GitHub first introduced Agentic Workflows in technical preview on February 13th, pitching Markdown-based automations for issue triage, pull-request review, CI failure analysis and repository maintenance. The feature moved into public preview on June 11th. The timing of GitLost is awkward because GitHub has been positioning agentic workflows as a way to automate real engineering work inside the same Actions infrastructure enterprises already use.
Security researchers have been warning about this class of flaw before GitLost. A May 2026 arXiv paper, "Demystifying and Detecting Agentic Workflow Injection Vulnerabilities in GitHub Actions", defined Agentic Workflow Injection as a flaw where untrusted GitHub event context, including issue bodies, pull-request descriptions or comments, reaches an agent prompt or agent-consumed input and drives behavior through tools or workflow logic. The authors said they analyzed 13,392 real-world agentic workflows from 10,792 repositories and reported 519 potential vulnerabilities, with 496 confirmed exploitable under their threat model.
GitLost is a concrete version of that pattern inside GitHub's own agentic workflow system. The old CI/CD security problem was untrusted input flowing into shell commands, environment variables or scripts. The agentic version swaps syntax for semantics. A sentence in an issue can become an instruction if the agent cannot reliably distinguish user data from operator intent.
Noma said it responsibly disclosed GitLost to GitHub and published the details with GitHub's knowledge. The post does not list a CVE, a bounty amount or a patch version. It does include builder recommendations that match the exploit chain: do not treat user-controlled content as trusted instructions, scope agent permissions to the minimum required, restrict public posting by agents, and isolate user input before it reaches the model.
For engineering teams trying GitHub Agentic Workflows, the operational takeaway is narrower and more urgent than "avoid agents." A workflow that reads public collaboration artifacts should have repository access scoped to the repo it needs, especially when the output is a public comment. Cross-repository context is useful for triage and maintenance, which is why GitHub and early customers have emphasized it. GitLost shows that cross-repository context also raises the blast radius when the agent follows the wrong instruction. The deeper problem is that agent security controls have to police meaning, not only permissions. Sandboxes, read-only tokens and safe-output gates still matter, but an agent with permission to read private data and permission to comment publicly can leak without writing files, executing shell commands or touching secrets. It only has to quote what it was allowed to read.