GitHub's AI Coding Agent Leaked Private Repos With a Single Issue

Noma Labs' GitLost write-up shows a single public-repo issue can coerce GitHub's coding agent into leaking private repo contents.

Padlock resting on a laptop keyboard, representing the agent supply chain failures GitHub's first-party coding agent exhibited in Noma Labs' GitLost disclosure.

GitHub shipped Agentic Workflows so that AI agents - powered by Claude and Copilot - can run routine repository tasks automatically. On July 6, 2026, the AI security firm Noma Labs showed that any visitor to a public repository can quietly use the same automation to read private repositories belonging to the same organization. No code, no credentials, no social engineering. The disclosure, named GitLost, is the first major prompt-injection finding against a first-party GitHub agent, and it lands on every developer who has trusted the assistant with private code.

What Noma Labs actually showed

In a write-up published July 6, 2026, Noma Labs research lead Sasi Levi walked through an attack that needs only the ability to file an issue in a public repository owned by a target organization. The vulnerable workflow triggers on the issues.assigned event, reads the issue’s title and body for context, posts comments via the add-comment tool, and has read access across other repositories in the same organization. An attacker hides instructions to fetch README.md from a private repo inside a normal-looking issue body, and the agent follows them, posting the file contents as a public comment on the attacker’s own issue. According to Levi’s GitLost disclosure, the only twist needed to bypass GitHub’s guardrails was the word “Additionally,” which reframed the model’s task and persuaded it to comply rather than refuse.

The proof-of-concept lives at the sasinomalabs/poc workflow run and the corresponding issue thread. The model was coaxed into reading the contents of three repositories - two public, one private named testlocal - and dumping them inline. Levi’s framing of the finding is blunt: “What will happen when the GitHub agent reads something it should not trust?” Levi added that “by tricking the model, I was able to ensure that GitHub’s guardrails did not work as intended and didn’t prevent the data leak.”

The Register picked the disclosure up on July 7 and underscored the practical reality of the gap. As of publication, GitHub’s only documented response was a callout in the documentation encouraging users to adopt different API key strategies across their repositories. That is not a code change to the workflow guardrails. Noma Labs also published the workflow reproductions and proof-of-concept in the same write-up so other teams can reproduce the attack against their own configurations.

Why this is a different class of agent risk

Most of the prompt-injection coverage this year has focused on chatbots, retrieval pipelines, or browser-using agents (the zero-click exfiltration through link previews we covered in February is a representative example). GitLost is a different shape of failure because the agent has standing authorization to read private code, and that authorization is what does the work. The model does not have to break in. It just has to be told to. The standard remediation for a developer who accidentally exposes secrets - rotate the key, revoke the token, scrub the log - does not apply when the agent is reading files it has legitimate access to and then publishing what it reads in a place the attacker can see.

That distinction is what makes the disclosure travel beyond GitHub itself. Any first-party agent that combines two properties is exposed to the same shape of attack - and that is exactly the pattern we identified back in February when we called out the AI agent as the new insider threat. The first property is a trigger fed by untrusted content - an issue body, a pull request description, a comment. The second is cross-resource read access. The fix list Noma Labs publishes is short and unsentimental: never treat user-controlled content as trusted instruction input for an AI agent, scope agent permissions to the minimum required, restrict what any agent can post publicly, and sanitize or isolate user input from the instruction context before passing it to the model. None of those are behaviors GitHub ships out of the box for Agentic Workflows.

For developers with Agentic Workflows enabled today, the practical change is short. If an organization owns both public and private repositories, the default configuration should be treated as unsafe for any organization that accepts issues from strangers. The mitigations available without a vendor patch are: disable cross-repository read access on agent workflows, gate the trigger so it only fires on issues from known contributors, or insert a human review step before the agent is allowed to post any comment publicly.

What This Means

The same week GitLost landed, Discord acknowledged a separate but structurally similar failure. Its AI moderation stack wrongfully banned more than 8,000 users over two months for uploading harmless images - spreadsheets, chessboards, game textures, transparent backgrounds - and a human review step was bypassed by a bug. EFF opened a two-part “Automated Moderation Is Here to Stay” series on July 7 arguing that automated moderation is now the permanent default on every major platform and that the transparency and accountability frameworks civil society asked for “have yet to be fully realized.”

Two unrelated disclosures, two named vendors, and the same through-line. AI systems that act on untrusted input are now routine enough to leak code by prompt injection and ban people by image classifier. Neither failure mode is exotic. Both are exactly what EFF and the security community warned would happen when systems with permanent access and weak recourse are deployed at platform scale. The cost is showing up in private code, in banned accounts, and in the absence of a meaningful appeal path for the people affected.

The Bottom Line

GitHub’s Agentic Workflows can be coerced into publishing the contents of a private repository to a public issue with nothing more than a benign-looking paragraph in a public-repo issue body. Noma Labs disclosed the issue on July 6, 2026; GitHub’s response, as of writing, is a documentation note about API keys rather than a guardrail-level fix. Until GitHub ships something stronger, the safe default is to treat any public-input-triggered, cross-repo agent as a prompt-injection target and scope its permissions accordingly.