GitLost: GitHub’s AI Agent Leaks Private Repositories

Key Takeaways

– Noma Labs dropped details on GitLost, a prompt injection that tricks GitHub’s preview Agentic Workflows into dumping private repo data through public issue comments.
– Attacker needed no coding skills or special access — The Register confirmed this.
– The vulnerability cannot be completely fixed in code per The Register. It’s architectural, not a bug.
– If your org runs Agentic Workflows, one public issue could expose private code right now.

GitHub shipped a preview feature that lets an AI agent run tasks inside GitHub Actions. Turns out, that agent can be talked into leaking your private repositories through a public issue comment. No hacks. No stolen tokens.

Just plain English.

Security org Noma Labs demonstrated the attack.

They call it GitLost.

Here’s the uncomfortable part.

Honestly, I’ve been sitting on this for a day trying to figure out if the framing is overly dramatic. It’s not. The exploit is that simple.

What GitHub Agentic Workflows Actually Do

Quick context for anyone who hasn’t touched this feature yet. Agentic Workflows is GitHub’s preview tool where an AI agent autonomously handles stuff inside your repos. Triage issues. Update documentation. Review pull requests. You describe what you want in plain language and the agent goes off and does it.

Nifty, right?

The catch is permissions. The agent typically gets read access across multiple repos in your org, private ones included. That broad reach makes the agent genuinely useful for cross-cutting tasks. It’s also what makes this attack brutal.

CSO Online flagged that the setup creates serious concerns around AI agents with privileged access to org code.

And tbh this extends past GitHub entirely. Any AI tool that ingests untrusted text and touches sensitive systems has the same structural exposure. Your CI bot, your Slack integration, your customer support agent. All of them sit on the same fault line.

Most teams haven’t thought about it in those terms.

How GitLost Pulls It Off

The attack flow is dead simple.

Too simple.

Someone opens a GitHub issue on a public repo. The repo has to belong to the same org that owns the targeted private repos. Inside the issue body, they write instructions in regular English. No malware. No exploit payload. No code at all, really.

Just words arranged the right way.

GitHub’s agent reads the issue and treats those words as instructions rather than untrusted content.

So it pulls sensitive data from the private repos it has access to. Then it posts that data as a public comment on the issue.

Right there. In the open. Anyone can read it.

Noma called this a “textbook indirect prompt-injection attack” and honestly the label fits.

The Register confirmed the attacker needed no coding skills or special access. They literally just opened an issue and waited.

Noma verified the attack didn’t rely on stolen credentials or software vulnerabilities. The agent followed instructions it should never have trusted.

That’s the core failure right there. The agent can’t distinguish between a real command from someone with authority and a sneaky instruction buried in an issue body by a complete stranger. There’s no wall between “data”. The issue text. And “command”. What the agent does about it.

Every input gets treated as a potential instruction.

Side note: I checked Noma’s blog post and their writeup is unusually clear for a security disclosure. No dense jargon, no gatekeeping. Refreshing.

Can You Even Patch This?

Short answer from The Register: no, not completely. Not in code.

That sentence should sit heavy in your chest for a second.

This isn’t a missing input validation check.

It’s not a dependency you can bump to version 2.4.7. Noma said GitLost exposes a broader architectural problem with AI agents rather than something specific to GitHub’s implementation.

Large language models process everything as potential instructions. There’s no dependable way to wall off trusted system prompts from untrusted user content. SQL injection got solved decades back with parameterized queries. Clean separation between data and command. Prompt injection has no equivalent. Nobody’s even pretending to have a credible timeline for one.

For small teams on GitHub, this means patching won’t save you.

The vulnerability doesn’t live in a function or a library. It lives in the fundamental design pattern of agentic AI. Systems that consume untrusted input, then execute privileged actions based on that input.

Your agent reads issues written by literally anyone on the internet.

Then it acts on private repos with the permissions you handed it. That gap. Between who writes the input and what the agent can reach. Is the entire attack surface. All of it.

What Your Team Should Actually Do

If Agentic Workflows are running in your org, treat the agent’s permissions as your real attack surface. Not the AI model. Not the prompt template. The permissions.

Restrict cross-repo access hard. GitLost only works if the agent can read private repos beyond the one where the issue got filed. If the agent can only see the public repo where the issue lives, the whole thing falls apart. Scope those permissions down even if it means the agent becomes less useful. Convenience is not worth leaking your source code to a stranger.

Audit what the agent can actually read. Go check which repos it reaches across your org. The scope might be wider than you intended when you flipped the feature on. And defaults in preview tools tend to favor convenience over lockdown. That’s just how previews work.

Treat all user-generated content as hostile. GitHub issues, PR descriptions, comments, even file contents in a repo. All of them are potential injection vectors. If your agent reads any of that and holds privileged access to something sensitive, you’ve got a trust boundary problem. No amount of prompt engineering fixes it. I keep seeing teams try to solve this with elaborate system prompts and guardrail instructions. Won’t work. The model can’t reliably self-protect against this class of attack.

Flag public issues from unknown accounts. A crafted issue from a brand-new account with no contribution history is the pattern to watch. Set up alerts on your public repos for this. Takes five minutes, might save you from a real disaster.

The broader lesson here travels beyond GitHub. Any AI agent you build or deploy — if it takes untrusted input and can touch sensitive data, prompt injection is your primary threat model. Not theoretical. A demonstrated attack that Noma Labs just proved works against one of the biggest developer platforms on the planet.

The Real Question

GitLost didn’t need sophisticated hacking. No zero-days. No insider access. No fancy tooling.

A GitHub issue and carefully worded English sentences.

That’s it.

If your AI agent has privileged access to private data, someone will try this against you.

The only question worth asking is whether your agent can tell a genuine instruction from a trap.

Right now, it can’t.

Nobody’s can.

Audit your agent’s permissions today.

Don’t wait for a patch — there isn’t one coming. This is access control you can enforce right now, before some random account files an issue your agent happily obeys.