A public GitHub issue should not be able to pull text out of your private repositories.
With a dangerously over-permissioned GitHub Agentic Workflow, that is exactly what Noma Labs demonstrated.
Their July 2026 write-up showed a simple but nasty chain: an attacker opens an issue in a public repository, an AI agent reads it as part of an automated workflow, the agent reaches into other repositories it can access, and the results come back as a public comment. No stolen login. No insider access. No clever memory corruption. Just a workflow that trusted the wrong text.
I run Hermes agents against GitHub-adjacent workflows on my own kit, and this is the class of bug I worry about far more than model benchmark scores. Once an agent can read one place, write somewhere else, and decide its own next step in between, your problem is no longer "AI output quality." Your problem is access control.
My view is blunt: if an agent can read private code and post publicly in the same run, the design is already wrong.
What GitLost actually showed
Noma Labs published GitLost on 6 July 2026. The attack targeted GitHub's new agentic workflow pattern: Markdown-defined workflows tied to GitHub Actions, with an AI agent reading issues, calling tools, and replying automatically.
The dangerous part was not "AI" in the abstract. It was the permission mix.
According to Noma's write-up, the vulnerable pattern looked like this:
- a public repository in the same GitHub organization as private repositories
- an automated workflow triggered by issue activity such as
issues.assigned - an agent that reads the issue title and body
- permission for that agent to read other repositories in the organization
- permission for that same agent to post back into the public issue
That combination is enough.
Noma's proof of concept showed the agent fetching README.md from both a public repo and a private repo, then posting the contents back into a public comment thread where anyone could read them. Their write-up says the leaked files came from repositories named poc and testlocal, and that the workflow was triggered after the public issue was assigned.
That matters because it turns a boring workflow event into a trust-boundary failure.
A lot of people still hear "prompt injection" and imagine someone typing "ignore previous instructions" into ChatGPT for fun. This is not that. This is a live automation path with real repository permissions attached.
The attack is simple because the system is over-trusted
The rough sequence looks like this:
- An attacker opens an issue in a public repository.
- The issue looks harmless enough to survive normal human scanning.
- The workflow assigns or otherwise triggers the agent.
- The agent reads the issue body as part of its input.
- Hidden instructions in that issue push the agent to read other repositories and publish what it finds.
Noma says one small wording change, adding the word "Additionally", was enough in their testing to push the model around GitHub's intended guardrails and make it reframe the answer instead of refusing it.
That is the part people need to sit with.
This was not a case of the attacker breaking GitHub authentication. The attacker used the workflow exactly as exposed. The workflow itself bridged public input and private data too freely.
If you teach computer science, the classroom analogy is straightforward. This is like letting a student write a note on the whiteboard, having an assistant treat that note as an instruction sheet, then letting the same assistant walk into the locked filing cabinet and pin the contents back on the classroom door.
The filing cabinet is not the weak point there. The procedure is.
Why this matters even if you do not use GitHub's exact setup
Most people will read GitLost and ask, "Am I affected if I do not use GitHub Agentic Workflows?"
Maybe not by this exact proof of concept.
But the broader lesson applies to every agent stack, including self-hosted ones.
I wrote recently about why local AI matters and about securing self-hosted Ollama. Running your models locally does help with privacy. It stops your prompts and code from automatically leaving for a cloud provider.
It does not solve this problem.
GitLost is not mainly a model-hosting problem. It is an orchestration problem.
If your agent can:
- read public issues or comments
- access private repositories, secrets, or internal docs
- open pull requests, comments, emails, or tickets automatically
then you have built a system where untrusted text can influence trusted actions.
That is the trust boundary that matters.
I see the same misunderstanding in a lot of AI tool conversations. People obsess over which model is smartest and ignore which tool has the broadest token, the loosest repository scope, or the most dangerous default action. That is backwards. In practice, the model is often the least interesting part. I made the same argument in my post on multi-agent debate and AI architecture: the intelligence people admire usually lives in the orchestration, and so do the failure modes.
The real mistake: one agent, too many powers
The cleanest way to think about GitLost is this: one actor in the system was allowed to do too many kinds of work.
It could inspect untrusted public text. It could fetch private information. It could speak publicly.
That is too much authority for one automated step.
If I gave a student account permission to read every exam paper, every answer sheet, and every staff note, I would not also let that same account publish messages to the whole class without review. Yet that is roughly what some agent workflows are doing.
And this is why GitLost is a better lesson than a lot of headline-friendly AI panic. It exposes a design error you can actually fix.
Five changes that reduce this risk fast
None of these make an agent workflow "safe." That word is too absolute for security work. They do reduce the attack surface.
GitHub Agentic Workflows are read-only by default and separate write operations through safe outputs, but those controls cannot compensate for an agent that has unnecessarily broad read access and is allowed to publish sensitive output.
1. Scope each agent to one repository whenever possible
Cross-repository access is convenient, but it is also how a public issue in one repo turns into a leak from another.
If a workflow only needs access to the repository where the issue was opened, give it only that. If a second private repository is genuinely required, make that an explicit separate step with its own token and its own review point.
This is the same least-privilege logic that applies to any secret or service account. If the agent does not need the key, do not hand it the key.
2. Split public-writing steps away from private-reading steps
This is the biggest architectural fix.
Do not let the same workflow run both of these operations automatically:
- read internal or private material
- publish directly to a public thread
If you need both, add a gate between them. Make the first step collect data into a private review channel. For sensitive workflows, require human approval before anything goes back out publicly.
Yes, this slows the workflow down.
Good.
Security controls that cost nothing usually protect nothing.
3. Treat issues, pull requests, and comments as untrusted input
Every issue body, PR description, code comment, changelog, and Markdown file the agent reads should be treated as hostile until proven otherwise.
That does not mean you stop using automation. It means you stop pretending user-controlled text is just data. In an agentic system, text is also control surface.
This is why I still like a simpler self-hosted LLM setup with Docker, Ollama, and Open WebUI for a lot of personal work. A local chat interface that helps me think is a very different risk profile from a workflow agent with repository permissions and public posting rights.
4. Use narrower tokens and installation scopes
Org-wide access is comfortable for setup and dangerous in production.
Use repository-specific installation permissions where you can. Separate read access from write access. Separate code access from issue-management access. Separate internal automation from external-facing bots.
The goal is not elegance. The goal is blast-radius reduction.
When something goes wrong, you want one repo affected, not twenty.
5. Log the agent's tool calls like you would log an admin session
If an agent fetches a private file because a public issue nudged it there, you want a trail.
Log which trigger fired. Log what repositories were touched. Log what tools were called. Log what text was posted back out.
Without that, your first sign of trouble is often the leaked output itself.
I would also add one practical rule: run new workflows in dry-run mode against test repositories first. If a public comment can influence a private read in staging, it will do it in production too.
What GitLost teaches CS students
This is a strong teaching example because it bundles several core ideas into one incident.
Authentication is not authorization
The attacker did not need to break into the private repository directly. The system's own authorized agent did the reading on the attacker's behalf.
That is an authorization design failure.
Public input can change private outcomes
Students often think of user input as something that affects only the page or form it was typed into. Agent systems break that mental model. A sentence written in one place can trigger actions somewhere else entirely.
Security is a property of the whole system
The model, the workflow trigger, the GitHub token, the repository permissions, and the response path all matter together. Focusing on only one piece misses the point.
That is why I find incidents like this more useful than generic AI doom-posting. They are concrete. You can diagram the data flow. You can point to the trust boundary. You can explain exactly where the design went wrong.
My bottom line on agent workflows
I like agents. I use them. I think they are useful.
I also think a lot of people are wiring them into production systems far too casually.
GitLost is the warning shot. Not because AI is uniquely dangerous, but because it shows how quickly old access-control mistakes turn into leaks when you automate them.
If your agent reads public text, touches private code, and posts publicly without a human checkpoint, fix that before you worry about the next model upgrade.
That is the part worth taking seriously.
