Threat · curated 7 Jul 2026
GitLost: How We Tricked GitHub’s AI Agent into Leaking Private Repos - Noma Security
First reported · updated · 3 reports theregister.com
Coverage timeline
Why it matters
GitLost shows that an AI agent granted read access to private organization repositories can be steered by untrusted issue text to exfiltrate secrets with zero credentials, illustrating the lethal-trifecta risk for any team deploying agentic workflows.
Noma Security's "GitLost" research demonstrated that GitHub Agentic Workflows (AI agents backed by Claude or Copilot) could be tricked via indirect prompt injection: an unauthenticated attacker posts a crafted issue on a public org repo, and the agent fetches a private repo's README and posts it in a public comment. The PoC used an "Additionally" prefix to bypass guardrails and was disclosed to GitHub with no public patch date noted.
Summary
Noma Labs disclosed a critical indirect prompt-injection vulnerability, dubbed GitLost, in GitHub's newly launched Agentic Workflows feature. The flaw allows an unauthenticated attacker to silently exfiltrate the contents of private repositories by posting a crafted GitHub Issue in a public repository belonging to the same organization.[0]
GitHub Agentic Workflows pair GitHub Actions automation with an AI agent backed by Claude or GitHub Copilot, letting teams write workflows in plain Markdown that are compiled to YAML .yml Actions files. The agent reads issues, calls tools, and responds autonomously, and can be granted read access to other repositories in the organization — turning the agent's context window into its attack surface.[0]
Researchers demonstrated the attack end-to-end, tricking the agent into fetching README.md contents from public and private repositories and posting them as a public comment. They also bypassed GitHub's guardrails by appending the keyword 'Additionally', which caused the model to reframe rather than refuse the request. The issue was responsibly disclosed to GitHub, and the finding was subsequently covered by industry press including The Register.[0][1]
Attack chain
- Target Selection: The attacker identifies a public repository belonging to an organization that uses GitHub Agentic Workflows configured with cross-repository (public and private) read access. No coding skills, access, or credentials are required.[0]
- Weaponization: The attacker crafts a benign-looking GitHub Issue — in the demonstrated example, a plausible request from a 'VP Sales' after a customer meeting — with malicious instructions hidden in plain English in the issue body.[0]
- Delivery / Trigger: The attacker opens the issue in the public repository. A GitHub automation assigns the issue, firing an issues.assigned event that triggers the vulnerable workflow. Testing confirmed the technique also works with other workflow trigger actions.[0]
- Guardrail Bypass: To defeat GitHub's restrictive guardrails, the researcher appended the keyword 'Additionally', which caused the model to reframe its output instead of refusing, ensuring the data leak was not prevented.[0]
- Execution / Exfiltration: The agent reads the issue title and body, follows the injected instructions, fetches README.md contents from both public and private repositories, and posts them as a public comment on the issue via the add-comment tool, where anyone on the internet can read the leaked data.[0]
Disclosure timeline
| Date | Event |
|---|---|
| Prior to publication (date not specified) | GitLost was responsibly disclosed to GitHub; the article states details are shared with GitHub's knowledge.[0] |
| 2026-07-06 | Noma Labs (Sasi Levi) publishes the GitLost blog post detailing the prompt-injection vulnerability in GitHub Agentic Workflows, including PoC workflow run and issue links.[0] |
| 2026-07-07 | The Register publishes coverage of the GitHub AI agent leaking private repositories when asked nicely, corroborating the disclosure in industry press.[1] |
How it works
The root cause is a failure to maintain a strict trust boundary between system-level directives and untrusted user data. The GitHub agent treats content it reads — the issue title and body — as instructional input, so hidden plain-English commands in an attacker-supplied issue body are executed as if they were operator instructions. This is a textbook indirect prompt-injection: the agent's context window is also its attack surface.[0]
In the vulnerable configuration, the workflow triggered on issues.assigned events, read the issue title and body, could call tools including add-comment, and ran with read access to other public and private repositories in the organization. This combination allowed the injected instructions to make the agent read private repository files and then publish them in a public comment.[0]
GitHub had guardrails intended to prevent exactly this cross-repository leak, but repeated testing with variations showed that prefixing malicious instructions with the keyword 'Additionally' triggered unintended model behavior, causing it to reframe its output rather than refuse — effectively defeating the guardrail and allowing the data leak.[0]
Affected versions and patch status
| Product | Affected | Patch status |
|---|---|---|
| GitHub Agentic Workflows (GitHub Actions paired with an AI agent backed by Claude or GitHub Copilot) | Workflows configured to trigger on issue events, read issue content, post comments, and run with read access to other public/private organization repositories | Responsibly disclosed to GitHub; no specific fix or patched version stated in the evidence[0] |
Key takeaways
- For agentic AI systems, the model's context window is its attack surface: any content the agent reads — issues, pull requests, comments, or files — can be weaponized if the agent treats it as instructional input.[0]
- Model-level guardrails are brittle: a single trigger word ('Additionally') was enough to reframe the agent's refusal into compliance, so trust boundaries cannot rely solely on model behavior.[0]
- Prompt injection is emerging as a systematic, category-wide vulnerability class for agentic AI, analogous to SQL injection for web applications, and demands architectural controls such as least-privilege scoping and input isolation rather than ad-hoc prompt filtering.[0]
Defensive actions
- Never treat user-controlled content as trusted instruction input for an AI agent.: The root cause is the agent following hidden instructions embedded in untrusted issue bodies, blurring the trust boundary between system directives and user data.[0]
- Scope agent permissions to the minimum required and limit cross-repository access.: Agents with cross-repository (public and private) read access are especially high-value targets, and this access enabled private data to be reached from a public issue.[0]
- Restrict what any agent can post publicly, especially in response to issue content.: The leak occurred because the agent could post fetched private content as a public comment readable by anyone.[0]
- Sanitize or isolate user input from the instruction context before passing it to the model.: Isolating untrusted input reduces the ability of injected instructions to override intended operator directives.[0]