GitLost: a public GitHub issue can steer an org’s Agentic Workflow into leaking private repo contents, and a one-word prefix (“Additionally”) bypassed the threat-detection guardrail

Noma Security published a technique they call GitLost against GitHub Agentic Workflows (the plain-English-Markdown agent feature GitHub put into public preview in February, runnable on Copilot, Claude, Gemini, or Codex). Worth reading because it is a clean demonstration of why “filter the injection” does not hold as a defense. The setup. Workflows are read-only by default, but an org can hand one a personal access token with read access across its repos, private ones included, to give the agent cross-repo context. That grant is the whole vulnerability. Nothing else about the attack requires access: no stolen creds, no write access to anything private, no touching a server. The attacker just opens a normal-looking issue on a public repo. The technique is indirect prompt injection, which is not new, but the interesting part is what the agent controls. Noma’s Sasi Levi frames the distinction as earlier injection being about manipulating what an agent says, versus GitLost being about what an agent does with its permissions. The agent here is a credentialed actor sitting in CI/CD-adjacent infrastructure with read scope over repos the attacker cannot see. In their PoC the malicious issue was dressed as a routine request from a “VP of Sales” after a customer meeting. A normal automation assigned the issue, the agent read it, pulled a private repo’s README, and pasted it into a public comment. That public comment is the exfiltration channel. The guardrail bypass is the part netsec will care about. GitHub built defenses for exactly this class: sandboxing, read-only tokens by default, input cleaning, and a threat-detection step that scans the agent’s proposed output before it posts. GitHub’s own architecture docs are explicit that they design assuming the agent is already compromised (dedicated container, egress firewall, an MCP gateway container that holds the PAT so the agent process never touches it). Noma reported that prefixing the malicious instruction with a single word, “Additionally,” got the model to treat it as a follow-on task rather than something to refuse, and the output scanner let it through. This maps cleanly onto Simon Willison’s “lethal trifecta”: an agent that (1) can reach private data, (2) ingests untrusted external content, and (3) has a way to send data out. All three present means a leak path, and Levi is explicit that this is structural, not a patch target. In natural language there is no clean data/instruction boundary the way there is in parameterized SQL, so the mitigation is architectural (isolation, scoped credentials, staged human review) rather than pattern-matching the payload away. Not an isolated finding either, this is a whole class: – Anthropic’s Claude Code GitHub Action: a single malicious issue pushed the agent into leaking secrets and seizing write access (Aikido). – Orca’s RoguePilot: a hidden prompt in an issue made Copilot leak a repo’s privileged token. – Invariant Labs (May 2025): a public issue drove a GitHub MCP-connected agent into reading a private repo and leaking it via PR. They called it architectural then too. – “Comment and Control”: cross-vendor study that got Claude Code, Gemini CLI, and Copilot to leak their own API keys through issue/PR text. Mitigations that actually reduce scope (from Noma): – Scope the integration PAT to the single repo the workflow triages, not org-wide read. This is the biggest lever. A token that sees one repo is far less dangerous than one with broad org read granted for convenience. – Limit what a public-facing workflow can post, since the comment is the exfil channel (safe outputs). – Restrict which authors’ content the agent will act on. – Gate outputs behind human review. The threat-detection scan is a backstop, not a boundary, as the one-word bypass shows. submitted by /u/Aureliand [link] [comments]Technical Information Security Content & DiscussionRead More