GitHub's AI Agent Leaked Private Code With One Word: "Additionally."
The patch is not the story. The access it had all along is.
On July 6, 2026, Noma Labs disclosed a vulnerability it calls GitLost: an attacker with no credentials, no repository access, and no coding skill opened a public GitHub Issue, hid a plain-English instruction in the body, and walked away with private repository contents pasted into a public comment by GitHub’s own AI agent. GitHub updated its documentation afterward. Noma says the design flaw that made this possible is still live. That is not the interesting part of this story. The interesting part is that the agent never did anything it wasn’t authorized to do.
What Actually Happened
GitHub Agentic Workflows pairs GitHub Actions with an AI agent backed by Claude or Copilot, configurable to read Issues, call tools, and respond on its own. Noma’s researchers found a workflow set up to trigger on issues.assigned events, read the Issue title and body, and post a reply using the agent’s own comment tool. To do that job, the workflow ran with read access to every other repository in the organization, public and private, all the time.
An attacker opened an Issue that looked like a routine internal request and buried an instruction in it: fetch a file from a specific private repo and paste it into a public comment. When the Issue got assigned, the agent read the text, treated the embedded command as part of its job, retrieved the file, and posted it. Noma’s proof of concept pulled private repository data in minutes.
GitHub had guardrails specifically built to catch this kind of hijack. Noma’s researchers defeated them by prefacing the injected instruction with one word: “Additionally.” That reframed the hijack as a legitimate follow-on task instead of something to refuse. One conjunction, and the defense fell over.
If your mental model of AI security still centers on “will the model get tricked,” you’re solving last year’s problem.
This Is Not GitHub’s Problem Alone
GitLost is a data point, not an outlier. The OWASP GenAI Security Project’s State of Agentic AI Security and Governance, version 2.01, maps prompt injection to six of the ten categories in its Top 10 for Agentic Applications and, per Help Net Security’s reporting on the group’s June 2026 findings, names it the leading driver of agentic AI security failures currently observed in production.
Look at what else that same reporting period produced. CVE-2025-6514, a remote code execution flaw rated 9.6 on CVSS, hit a widely used Model Context Protocol package after fifteen clean releases built trust before a malicious update shipped. CVE-2026-22708 against the Cursor coding agent let an attacker poison its execution environment so the agent’s own allowlisted commands became a delivery mechanism for arbitrary payloads -- the allowlist made the attack easier, not harder, because it auto-approved exactly the commands the attacker needed. CVE-2025-59532 against OpenAI’s Codex CLI showed an agent’s own output could redefine the boundary of its sandbox.
Four incidents, four vendors, one root cause. An agent trusted something it shouldn’t have, and nobody had scoped its access tightly enough to contain what happened next.
Why the Math Got Worse
Here’s the number that should bother you more than any CVE score. The Cloud Security Alliance’s State of Non-Human Identity and AI Security survey report, released in January 2026, found that fewer than one in four organizations have documented, formally adopted policies governing how AI identities get created or retired. Only 12% report high confidence in their ability to prevent an attack routed through a non-human identity. More than 16% don’t even track when new AI-related identities get created.
Twelve percent. Read that again. That means roughly nine out of ten security leaders, asked directly, admit they could not stop a GitLost-style attack if it happened to them tomorrow.
It gets worse when you check what leadership believes versus what’s actually happening. Gravitee’s State of AI Agent Security 2026 report found that 88% of organizations running production AI agents confirmed or suspected a related security incident in the past year -- while 82% of executives said their existing policies already protect them from unauthorized agent actions. Both numbers are true at the same time. Your board thinks you’re covered. Your incident log says otherwise.
Agentic AI didn’t invent this gap. It just moves fast enough, and touches enough systems, to make the gap load-bearing.
Stop Patching the Model. Fix the Permission.
Every vendor response to a prompt injection incident follows the same script: ship a better system prompt, tighten a filter, promise the next model version catches it. Noma just proved that script fails against a single well-chosen adverb. A filter tuned to catch today’s phrasing misses tomorrow’s synonym, forever, by construction. Build your AI security program around catching bad instructions, and you’ve picked a fight you cannot win.
The fight you can win is the one over access. GitLost’s agent needed permission to read one Issue in one repository. It had standing read access to the entire organization, indefinitely, because provisioning broad access once is less work than scoping it per task. That gap between what a task requires and what an identity is granted did all the actual damage. The prompt injection was just the trigger that found it.
This is the architectural shift a handful of platforms are starting to build around: treat every AI agent request the way you’d treat a request from an unfamiliar contractor, not a trusted employee. Evaluate it against policy every time, not once at connection. Kiteworks’ approach to this, for one, keeps the credentials an agent uses to act inside the operating system’s credential store -- never exposed to the model’s own context -- so that even an agent that falls for the “Additionally” trick can’t extract the keys to reach further than the one session already allows. That’s not a prompt-layer fix. It’s a plumbing fix, and plumbing fixes are the only kind that survive contact with a cleverer attacker next quarter.
Kiteworks’ own Data Security and Compliance Risk: 2026 Forecast Report tracks this same gap across enterprise AI deployments broadly: adoption is outrunning governance almost everywhere security teams look, and agentic AI is simply the sharpest edge of that trend right now.
What to Do Monday Morning
Stop debating which model vendor has the better guardrails. That debate is a distraction from the one that matters.
1. Pull the permission list for every AI agent or automated workflow with access to your repositories, file stores, or content systems. Write down what each one is supposed to do.
2. Compare that job description against what the agent can actually reach. Anywhere the two don’t match, you have a GitLost waiting for someone to find it.
3. Scope access per task, not per identity. An agent triaging one Issue doesn’t need visibility into every private repo in the org.
4. Isolate credentials from anything the model can see or influence. If the agent’s context can leak the keys, the keys aren’t isolated.
5. Log everything as though an auditor will ask for it next week -- because eventually, one will, and “the AI accessed it” is not an answer that survives a real investigation.
The organizations that get burned by the next GitLost will be the ones still arguing about which model is safer. The ones that don’t will be the ones who already knew what their agents were never supposed to reach in the first place.
If this is useful to how you’re thinking about agentic AI risk, subscribe to Zero Trust Data Exchange -- I write about exactly this pattern, incident by incident, every time it shows up somewhere new. And if you’re already living this problem inside your own organization, hit reply. I read every one.