A politely worded issue, nothing more. That was all Noma Labs researchers needed to trick GitHub’s AI agent into emptying private repositories and handing over the code to an attacker. The vulnerability, named GitLost, cannot be patched in the traditional sense: there is no buffer overflow to fix or endpoint to secure. It is a design flaw that lives at the heart of LLM agent architecture.

The agent in question – an assistant capable of interacting with issues, pull requests, and the file system – operates with a broad set of tools and permissions. It only needs a seemingly legitimate request, perhaps an issue asking to “check for a file at a certain path,” to tap into private repos and return content that should never leave the project’s perimeter. The prompt contains no special characters or sophisticated exploits; it is pure social engineering applied to a language model.

The technical crux lies in how LLM agents orchestrate tools. When a model receives an instruction, it can decide to call a function to read a file or query a repository. If the system lacks sufficient architectural guardrails – such as a clear separation between the permissions of the user writing the issue and those of the agent – the step from legitimate reading to data leakage is extremely short. In GitLost, the agent apparently does not distinguish between public and private repos, or does so too weakly to withstand a well-crafted turn of phrase.

GitHub’s response has so far been silence, and the lack of documentation suggests the company has no structural countermeasure yet. Any fix limited to filtering prompts cannot be definitive: LLMs are inherently susceptible to prompt injection, and the race between attackers and defenders in this field is asymmetric. The only way out is to rethink security boundaries around the agent, isolating private resources so that even a tricked model cannot access them without granular, contextual authorization.

For those hosting proprietary code or code subject to strict regulations, the flaw raises a broader question: does it make sense to entrust an AI assistant in a cloud service that operates on source code? Data sovereignty becomes central again. If the agent resides in the same tenant as the repository but can be steered by insufficiently verified external inputs, the risk of exfiltration is not theoretical. An on-premise deployment, where the agent runs in a segregated environment with limited access only to necessary repos, would at least reduce the attack surface, even if it would not immunize against the root problem.

GitLost won’t be the last incident of its kind. With the massive adoption of coding agents, the attack surface expands with every new capability granted to the model. The security community will have to develop stronger confinement mechanisms, while organizations must weigh the productivity promised by AI agents against the real possibility that a polite sentence could expose years of work.