On 6 July 2026, security researchers at Noma Labs published one of the most consequential AI-agent vulnerability disclosures of the year. Dubbed GitLost, the attack demonstrates how a single, innocuous-looking GitHub Issue can trick GitHub’s new Agentic Workflows feature into leaking the contents of private repositories — no authentication required.
If your organisation uses GitHub’s agentic automation features, this is mandatory reading.
TL;DR
- GitLost is a prompt injection vulnerability in GitHub’s Agentic Workflows that lets unauthenticated attackers extract private repository data through crafted GitHub Issues.
- The attack requires no coding skills, no authentication, and no special access — only the ability to open an issue on a public repository within the target organisation.
- Researchers found that adding the keyword “Additionally” to injected prompts bypassed GitHub’s safety guardrails entirely.
- Leaked data — including README files from private repos — was posted as public comments on the attacker-controlled issue.
- Development teams must audit agentic workflow permissions immediately, restrict cross-repository access, and treat all user-controlled content as untrusted input.
What Are GitHub Agentic Workflows?
GitHub has been steadily layering AI capabilities into its platform. Agentic Workflows extend GitHub Actions by letting AI agents respond to repository events — issue creation, pull request comments, label changes — and take autonomous action: writing code, searching repositories, posting comments, and more.
The promise is compelling. An AI agent that triages bugs, drafts fixes, or pulls context from across your organisation’s repositories. The problem, as GitLost demonstrates, is that the agent cannot distinguish between legitimate instructions and attacker-injected ones.
How GitLost Works
The attack chain is disturbingly simple:
- Attacker opens a GitHub Issue on any public repository within the target organisation. The issue title looks innocuous — a feature request or bug report.
- The issue body contains hidden prompt injection instructions written in plain English. These instruct the AI agent to read files from other repositories — including private ones — and post the contents as a comment.
- When the workflow triggers (typically on issue assignment or labelling), the AI agent ingests the issue body as part of its context window.
- The agent follows the injected instructions, accessing private repositories it has been granted cross-repo read permissions to, and dumps the data publicly.
The most striking finding from Noma Labs’ research? Adding the word “Additionally” before the injected instruction was enough to bypass GitHub’s safety guardrails — the ones specifically designed to prevent this class of attack.
That single word turned the agent from a guarded tool into an obedient exfiltration vector.
Why This Matters More Than a Typical CVE
GitLost is not a buffer overflow or a misconfigured endpoint. It exploits a fundamental architectural weakness in how AI agents process untrusted input. This is the same class of vulnerability — indirect prompt injection — that security researchers have been warning about since large language models entered production systems.
What makes GitLost particularly dangerous:
- Zero authentication required. Anyone who can open a GitHub Issue can attempt it.
- No technical sophistication needed. The payload is plain English, not shellcode.
- Cross-repository escalation. A public repo becomes the entry point to private ones.
- Data exfiltration via public channel. Leaked content appears as issue comments — visible to anyone.
- Guardrail bypass is trivial. A single word defeats the safety layer.
This is not a theoretical concern. If your organisation has configured agentic workflows with cross-repository read access, you are potentially exposed right now.
The Broader Pattern: Agents as Confused Deputies
GitLost fits into a pattern we have been tracking closely at REPTILEHAUS. AI agents in development tooling are becoming confused deputies — trusted entities that can be manipulated into acting against their principal’s interests.
We saw it with Agentjacking via Sentry DSNs. We saw it with Miasma, where config files weaponised coding agents. We saw it with the TrapDoor cross-ecosystem supply chain attack that poisoned AI assistant context files. GitLost is the latest — and arguably the most accessible — variant.
The common thread? AI agents inherit permissions but not judgement. They execute with the privileges they are granted, but they cannot reliably distinguish between authorised instructions and adversarial ones embedded in the data they process.
What Your Development Team Must Do Right Now
1. Audit Your Agentic Workflow Permissions
Review every GitHub Actions workflow that uses AI agents. Ask two questions:
- Does this agent have cross-repository access?
- Does this agent ingest user-controlled content (issues, comments, PR descriptions)?
If the answer to both is yes, you have a GitLost-shaped risk.
2. Apply the Principle of Least Privilege — Aggressively
Agents should only access the repository they are operating within. Cross-repo read access should be the exception, not the default. If an agent needs to reference another repository, use explicit allow-lists rather than organisation-wide tokens.
3. Treat All User Input as Untrusted
This is web security 101, but it bears repeating in the agentic context. Issue bodies, PR descriptions, comments — these are all attacker-controlled inputs. They should be sanitised, bounded, or isolated before being fed to an AI agent’s context window.
4. Restrict Agent Output Channels
An agent that can read private data and write public comments is an exfiltration tool waiting to be exploited. Restrict where agents can post their outputs. If an agent processes issue content, its responses should go to internal channels — not back to the public issue thread.
5. Implement Prompt Injection Detection
Add a pre-processing layer that scans user-controlled content for prompt injection patterns before it reaches the agent. This is not foolproof — prompt injection remains an unsolved problem in LLM security — but it raises the bar significantly.
6. Monitor for Anomalous Agent Behaviour
Log what your agents read and write. If an agent triggered by a public issue suddenly accesses a private repository it has never touched before, that should fire an alert. Behavioural monitoring is your safety net when guardrails fail — and as GitLost shows, guardrails do fail.
The Uncomfortable Truth About AI Agent Security
GitHub is not uniquely negligent here. Every platform bolting AI agents onto existing workflows faces the same fundamental challenge: LLMs cannot be made reliably immune to prompt injection. It is not a bug that can be patched with better guardrails. It is an inherent limitation of how current language models process mixed-trust inputs.
That does not mean we should stop using AI agents in development workflows. It means we need to design our systems with the assumption that the agent will be manipulated, and ensure the blast radius is contained when it happens.
Defence in depth. Least privilege. Input sanitisation. Output restriction. Behavioural monitoring. The security principles have not changed — they just have a new, very capable attack surface to protect.
How REPTILEHAUS Can Help
Our team has deep experience in securing AI-integrated development pipelines. Whether you need an audit of your existing agentic workflows, help implementing prompt injection defences, or a broader review of your CI/CD security posture, get in touch. We specialise in making AI-powered development workflows safe enough to trust in production.
📷 Photo by Markus Spiske on Unsplash
