---
title: "One Word Beat GitHub's Guardrail, and the Word Was 'Additionally'"
pubDatetime: 2026-07-07T00:00:00.000Z
description: "Noma Labs' GitLost shows an unauthenticated attacker leaking a private repo's contents by opening one public GitHub Issue. GitHub built a scanner to stop exactly this; prefixing the malicious line with 'Additionally,' walked the data straight past it."
tags: [security, ai-agents, prompt-injection, github, lethal-trifecta, 2026, 2026-q3, 2026-07]
---
> [!tldr] TL;DR
> Noma Labs disclosed **GitLost** on 6 July: a prompt-injection flaw in GitHub Agentic Workflows that lets an unauthenticated attacker read a private repo by opening a single Issue in any public repo in the same org. GitHub shipped sandboxing, read-only defaults, and an output scanner to block this exact leak. Noma got past all of it by prefixing the malicious instruction with the word "Additionally," which nudged the model to reframe its answer as a routine follow-on task instead of refusing. The vulnerable workflow held cross-repo read scope, so the agent fetched a private `README.md` and posted it as a public comment. There is no CVE and no code patch; GitHub updated the documentation that suggested the risky config. If you run these workflows, drop cross-repo read scope and stop agents from posting publicly in response to Issue content.

The whole exploit rides on one adverb. Noma Labs' researcher tried the obvious injection, GitHub's guardrail refused it, and then he added "Additionally," in front of the request. The agent handed over a private repository's contents and posted them where anyone on the internet could read them. That is the entire fix an attacker needed to defeat a defense GitHub built specifically to catch this.

[Noma Labs](https://noma.security/blog/gitlost-how-we-tricked-githubs-ai-agent-into-leaking-private-repos/) calls it GitLost, and it targets GitHub Agentic Workflows, the feature that pairs GitHub Actions with an AI agent backed by Claude or Copilot. You write the workflow in plain Markdown, GitHub compiles it to YAML, and the agent reads Issues, calls tools, and responds on its own. The pitch is triage automation: a bot that reads a new Issue and does something useful. The problem is that "reads a new Issue" means "ingests attacker-controlled text and treats it as instructions."

## The attack needs an Issue and nothing else

The vulnerable workflow Noma reproduced was configured to trigger on `issues.assigned`, read the Issue title and body, post a reply with the `add-comment` tool, and run with read access to other repos, public and private, across the organization. That last line is the whole game.

Here is the flow. An attacker opens an Issue on a public repo in the target org, dressed up as a bland request from a VP of Sales after a customer meeting. A routine automation assigns the Issue. The assignment fires the workflow, the agent reads the body, and the body tells it to fetch `README.md` from both a public repo and a private one. The agent holds credentials with cross-repo read scope, so it complies. Then it pastes the contents into a public comment on the original Issue.

Noma's [proof of concept](https://github.com/sasinomalabs/poc/actions/runs/23909666039) leaked `README.md` from `sasinomalabs/poc` (public) and, crucially, `sasinomalabs/testlocal` (private) into a [public Issue thread](https://github.com/sasinomalabs/poc/issues/153). No stolen token, no write access, no server access. On a public repo, opening an Issue usually needs zero privileges. As research lead Sasi Levi put it to [Dark Reading](https://www.darkreading.com/cyber-risk/gitlost-leaks-private-data-github-agentic-workflows), attackers "need to hide plain-English commands within content to trick a highly permissioned AI into bypassing its own guardrails and silently handing over private intellectual property."

## Why "Additionally" worked

GitHub did not ship this naively. There were restrictive guardrails, including an output-side threat scanner meant to catch precisely the "dump a private file into a public comment" move. Noma tested variation after variation, the way an actual attacker would, and found that leading with **"Additionally,"** flipped the model's behavior. Instead of refusing, it reframed the exfiltration as a reasonable extra step in a task it was already doing, and the scanner passed the output through.

That should worry anyone leaning on content filtering as their injection defense. The bypass was a discourse marker that made a malicious request read like a to-do item. No clever encoding, no three-page jailbreak prompt, just one adverb. A scanner tuned to spot "leak this private file" doesn't fire on "Additionally, include the following file for completeness," because at the token level the second version looks cooperative. In natural language there is no reliable boundary between data and instruction, and every filter that pretends otherwise is one adverb from being wrong.

## The lethal trifecta, textbook edition

GitLost maps cleanly onto Simon Willison's [lethal trifecta](/posts/ai-agent-security-lethal-trifecta), the three conditions that together make agent data theft possible: access to private data, exposure to untrusted content, and an outbound channel. Here the cross-repo PAT supplies the private data, the public Issue supplies the untrusted content, and `add-comment` supplies the exit. All three legs in one workflow means a leak path exists, and the model's instruction-following is what walks the data across it.

Noma frames the root cause in one line: "the agent's context window is also its attack surface." Levi's follow-up is the part worth pinning up. This "isn't a one-off implementation slip in a single feature; it's a structural consequence of giving AI agents standing credentials while also having them process attacker-reachable text." Swap the credential and the tool and you have described half the agent deployments shipping right now. It rhymes with the [AGENTS.md file that sat weaponized in a Meta repo for 18 days](/posts/ghostty-agents-md-trap): the injection lives in ordinary content the agent was always going to read, and [the harness is the trust boundary now](/posts/agent-harnesses-standard), not the code.

## No patch, because there's nothing to patch

GitLost was disclosed responsibly, and here is the uncomfortable part: there is no CVE and no code fix. Per Dark Reading, GitHub told Noma it updated the documentation that had suggested the vulnerable configuration, and when researchers last checked, the risky guidance was gone. That's the available remedy. You cannot patch "the model followed instructions in text it was told to read," because that is the feature working as designed.

Which pushes the burden onto whoever configures these workflows. Noma's advice is the boring, correct kind: never treat user-controlled content as trusted instruction input, scope permissions to the minimum (an agent with cross-repo read is a high-value target by construction), restrict what any agent can post publicly, and isolate untrusted input from the instruction context before the model sees it. If your triage bot can read private repos and comment on public Issues in the same breath, you have already built the trifecta. Take away a leg before someone else does it for you, one adverb at a time.

**Sources**

- Noma Labs, ["GitLost: How We Tricked GitHub's AI Agent Into Leaking Private Repos"](https://noma.security/blog/gitlost-how-we-tricked-githubs-ai-agent-into-leaking-private-repos/) (6 July 2026)
- Dark Reading, ["GitLost Leaks Private Data via GitHub Agentic Workflows"](https://www.darkreading.com/cyber-risk/gitlost-leaks-private-data-github-agentic-workflows)
- SC World, ["GitLost prompt injection leaks private repos via GitHub Agentic Workflows"](https://www.scworld.com/news/gitlost-prompt-injection-leaks-private-repos-via-github-agentic-workflows)
- PoC evidence: [workflow run](https://github.com/sasinomalabs/poc/actions/runs/23909666039) and [malicious Issue](https://github.com/sasinomalabs/poc/issues/153)
- [r/netsec discussion thread](https://www.reddit.com/r/netsec/comments/1upy3gm/gitlost_a_public_github_issue_can_steer_an_orgs/)

**Related on this blog**

- [Three Indirection Steps From a Reverse Shell](/posts/ai-agent-security-lethal-trifecta): the lethal trifecta framework GitLost lands on exactly
- [The Trap Fired in Seconds. The Humans Took 18 Days.](/posts/ghostty-agents-md-trap): injection hidden in ordinary repo content an agent was told to read
- [Agent Harnesses: A Standard for a Word Nobody Agrees On](/posts/agent-harnesses-standard): why the config layer, not the code, is the trust boundary now