Agentic developer tools have moved out of the demo stage and into daily production work inside real organizations. GitHub Agentic Workflows, a feature that runs on models such as Anthropic's Claude and GitHub Copilot, lets a team stand up an autonomous agent that reads issues, calls tools, posts comments, and reaches across the organization's repositories on its own. The convenience is obvious, and so is the exposure once that agent holds real permissions inside a codebase.
Security researchers at Noma showed how thin the margin can be. A stranger with no account access and no coding skill was able to reach a company's private source code by posting one public issue, because the agent read the attacker's text as if it were a legitimate instruction. The failure fits what the security researcher Simon Willison named the lethal trifecta, the dangerous combination of an agent that can read sensitive data, take in untrusted outside input, and send information back out, all in the same system.
As more companies wire agents with genuine read access into their development environments, the blast radius of a single successful prompt injection grows with every token and repository the agent can touch. The account below walks through exactly how the attack worked, maps the failure across the four control layers that should have stopped it, and sets out what still has no answer.
What actually happened
Noma Labs, the company's research team, disclosed the flaw and named it GitLost, publishing its findings after coordinated disclosure with GitHub. The target was GitHub Agentic Workflows, a feature in public preview that lets teams define automation in plain-language Markdown that compiles into GitHub Actions files, with an agent that can read issues, execute tools, and post comments. An organization can hand that agent a token with read access across its repositories, private ones included, to give it broader context, and that grant is the setup GitLost turns against its owner.
Noma created an issue that looked like a routine request from a vice-president of sales following a customer meeting, and hid instructions inside the body of it. Once the workflow was triggered, the agent read contents from a public repository and a private repository and posted the combined output as a public comment, visible to anyone who opened the page. The attacker needed no credentials and no technical skill beyond writing a cleverly phrased issue in a public repository belonging to an organization that had enabled the preview.
GitHub had seen this class of attack coming and said so in its own product documentation.
The chain of failure
The break ran in sequence, and each link handed the next one more room to move. The workflow was configured to trigger when an issue was assigned, then to read that issue's title and body and respond with the add-comment tool, all while holding read access to other repositories across the organization. The agent read the issue text as instruction, which is the root of indirect prompt injection, because a language model does not reliably separate the data it was asked to look at from the commands it was told to follow when both arrive as ordinary prose.
From there the permissions did the damage. The org-wide read token gave the agent reach into private repositories it never needed for the task in front of it, so a bot meant to triage issues became a path to exfiltrate source code. The add-comment tool then served as the outbound channel, publishing private contents in a place the attacker could simply refresh and read. GitHub's output scanner, which inspects an agent's proposed comment before it goes live, was the last line of defense, and Noma found that prefixing the malicious instruction with the single word "Additionally" reframed it as a follow-on task and let it slip past the check.
Noma's research lead drew the distinction that separates this from the prompt-injection demos that came before it.
GitLost is about manipulating what an agent does with its permissions.
Sasi Levi, Security Research Lead, Noma Security
The wider point the researchers make is that GitLost belongs to a category rather than standing alone. Prompt injection is becoming to agentic AI what SQL injection was to web applications a generation ago, a systematic class of weakness that shows up wherever an agent reads content it did not write, which means the same failure will keep surfacing across tools until the architecture changes.
Governance gaps: the four control layers
Read through GAIG's four control layers, GitLost is less a single bug than four controls that each gave way in turn.
Identity and access control. The origin of the blast radius was the token. The agent carried organization-wide read access rather than a credential scoped to the one repository the workflow actually triaged, which turned a low-stakes automation into a route out for private data. Levi's own guidance points the same way, that a token confined to a single repository is far less dangerous than one granted broad org-wide read access for convenience, and that gap is exactly the least-privilege discipline for non-human identities that we have argued for in its coverage of identity controls for AI systems.
Input and context integrity. The agent failed to separate untrusted user input, the issue body, from its own operating instructions, and that is the core architectural weakness rather than a configuration slip. Current models and agent frameworks still struggle to hold a clean boundary between data and command when both are written in natural language, so the fix has to live in separating the two before the text ever reaches the model, rather than in scrubbing the injection after the fact.
Action and execution control. The add-comment tool operated as an unrestricted outbound channel, with too little standing between the agent and a public post once external input had set it in motion. An agent that answers to untrusted triggers needs hard limits on what it may publish, because the comment it writes is the exfiltration channel, and bounding that output shrinks the channel toward nothing.
Monitoring, logging, and audit. Nothing in the workflow distinguished an action taken by the agent from one taken by a person, so the leak could run quietly. Runtime observability, action logging, and staged human review are the difference between a silent exfiltration and one a defender catches while it is still a proposed comment rather than a published one.
Mapped to the frameworks the field already uses, the picture is consistent. OWASP ranks prompt injection as the top risk in its Top 10 for large language model applications, the NIST AI Risk Management Framework speaks directly to this through its Govern and Map functions, and MITRE ATLAS catalogs the adversary techniques for prompt injection and tool misuse that GitLost strings together. The architectural verdict was stated most plainly by Invariant Labs, the team that found the predecessor flaw in GitHub's MCP integration in 2025, when it warned that this kind of weakness cannot be fixed on the vendor's side alone.
What's still missing
GitHub had already built several real defenses into the product, including sandboxing, read-only tokens by default, input handling, and the output scanner meant to catch exactly this. The uncomfortable result is that the one control left standing between a broadly scoped agent and a leak was a content filter, and a single word defeated it, which tells you how weak filtering is as a last line rather than a boundary.
The deeper problem is the one the researchers keep returning to. Natural language carries no clean separation between instruction and data the way a query language like SQL does, so the industry keeps filing these failures under architectural limitation, and the burden falls on the organization deploying the agent to scope its tokens, bound its outputs, and stage human review rather than trust the platform to hold the line. Exposure here is genuinely narrow, limited to organizations that turned on the preview and granted broad read access, so this is not a mass breach, and the pattern is just as genuinely not GitHub's alone, since the same failure has surfaced in other agent platforms and in MCP integrations.
The question none of the current responses answers is the foundational one. No widely accepted standard yet exists for how an agent proves that an action was authorized rather than merely instructed, and until that boundary exists, any agent that reads private data, takes in untrusted input, and can post in public sits one cleverly worded issue away from a leak.
Our Take
AI Security Take
GitLost is not, at bottom, a GitHub problem. It is a preview of what happens whenever an organization hands an AI agent real permissions while still treating it as if it can safely read untrusted input, and the defense that matters is architectural rather than a smarter filter bolted on at the end. GitHub deserves credit for coordinated disclosure and for shipping genuine guardrails, and the honest criticism alongside that credit is that offering an agent with org-wide read access as a configurable convenience builds the risk into the product.
The practical work is the same discipline security teams already know from human access, applied to software that acts. Scope every agent's access to the narrowest repository or resource it needs, treat all user-generated content as hostile by default, cap what a public-facing or externally triggered agent can post, and put runtime logging and staged review between the agent and anything it cannot take back. Those four moves map one to one onto the layers that failed here.
The thread running through the week points the same direction. From JADEPUFFER to the enterprise agent deployments GAIG has examined, the recurring failure is autonomy and access granted without matching controls on permission and oversight, and GitLost is that story told from the defender's chair. Firms that treat agent permission scoping and runtime oversight as a standing capability, the way they already treat least privilege for people, will not be the ones explaining a leak.
