GitLost: A GitHub Agentic Workflow Leaks Private Repos

What is GitLost?

GitLost is the name Noma Labs (author: Sasi Levi) gave to a vulnerability in GitHub Agentic Workflows, the feature that lets you hand repository tasks such as issue triage or contributor replies to an AI agent. An attacker who can open an issue in a public repository of an organization using this kind of workflow can get the agent to read private repositories and copy their content publicly.

The attacker needs no special skills, access or credentials. Opening an issue in a public repository of the organization, then waiting for the workflow to run, is enough.

How does the attack unfold?

In the configuration Noma demonstrated, the workflow triggered on issues.assigned events, read the issue title and body and replied with the add-comment tool. It ran with read access to the organization's other repositories, public and private. Noma says it obtained the same behavior with other triggers.

1. The attacker opens a public issue written to look like a plausible request from a sales executive after a customer meeting.
2. The workflow triggers. The agent, following the instructions hidden in the text, reads the README files of a public and a private repository.
3. The agent publishes the retrieved content as a comment on the public issue, readable by everyone.

What does the word "Additionally" change?

GitHub had put guardrails in place meant to prevent this scenario. Through repeated tests, Noma found that adding the word "Additionally" to the injected instructions made the model reframe its output instead of refusing. This detail illustrates a known limit: a guardrail based on model behavior is bypassed by rephrasing and is not a barrier.

Is it a bug a patch will solve?

Several analyses describe it as an architectural problem: the workflow gives the agent persistent credentials to private repositories while exposing it to attacker-controlled content. Noma writes only that it responsibly disclosed the flaw to GitHub; the articles consulted give neither a response timeline nor details of a fix. GitHub Agentic Workflows remained in public preview at the date of the articles.

This pattern gathers the three conditions of agentic risk: access to private data, exposure to untrusted content, ability to communicate outward. See the prompt injection page and the article on indirect injection.

How do you check whether your workflows are exposed?

1. Inventory: list the agentic workflows of each organization, their triggers and the repositories they can read.
2. Public triggers: spot those that react to content anyone can create (issues, comments, pull requests from forks).
3. Token scope: check whether the workflow token gives access to other repositories, especially private ones.
4. Output channels: can the agent publish a comment, open a pull request or call a URL from what it reads?
5. Test on a test repository: open an issue containing a traceable instruction asking to copy a file from a private test repository, and observe the comment produced.
6. Variants: try different phrasings ("Additionally", a credible business context, a multi-step instruction) to measure the guardrail's strength.
7. Past: review an agent's recent issue comments for code or text that should not have been public.

Which measures reduce the risk?

Noma recommends never treating user-controlled content as trusted instruction input, scoping permissions to the minimum, restricting what an agent can post publicly and isolating user input from the instruction context.

• Least privilege: the workflow that reads public issues only has access to the repository concerned, never to other private repositories.
• Separation: one agent for public content, another, unexposed, for private content.
• Human approval before any publication derived from a private repository.
• Output control: detect fragments of private code or files in a reply before publication.
• Logging of the repository reads performed by agents.

The general frame is described on the AI agent security page.

How do you design safer agentic workflows?

By treating each workflow as a small service exposed to the internet, with its own scope of rights. Four design patterns sharply reduce exposure.

1. One workflow, one repository: the workflow token is limited to the repository it serves. If the agent needs information from another repository, it is supplied by a separate, validated step that does not expose the whole repository.
2. Separate reading and publishing: the agent that reads public content publishes nothing directly; a second, deterministic step validates the format and content of the reply before posting it.
3. Allowlist of actions: the agent can only call the tools it needs (adding a label, for instance) and not a free comment tool when a reply template is enough.
4. Cautious triggers: limit sensitive workflows to issues created by organization members, and hold those from unknown accounts until a human review.

These choices cost little to implement and remove the core of the problem: the agent no longer holds both the private data and the ability to publish it.

Which detection signals should you look for afterward?

If you already have active agentic workflows, look for traces of abuse in the history.

• Agent comments containing excerpts of READMEs, configuration files or code from another repository.
• Recent issues whose text contains instructions addressed to an assistant ("request from management", "please attach the content of...").
• Workflow runs triggered by accounts with no contribution history.
• Unusual reads of private repositories in the organization's audit logs, correlated with an agent run.

If you find a case, delete the comment, consider the content public for the exposure period, rotate any secrets it may have contained and document the timeline.

It also helps to agree on a rule for new workflows: no agentic workflow goes live on a repository that has access to private data until someone has written down its triggers, its token scope and its output channels, and a second person has reviewed that note. The note takes ten minutes and is the document you will want during an incident.

What should you keep in mind for your agents?

The model was helpful rather than hacked. It treated public text as a legitimate request and used the access it was given. Protection rests on what it can read and publish.

CleanIssue's Agent Red Team Express (EUR 1,900, 5 days) attacks your agent with these scenarios and delivers a report with proof: see the offer. The discovery call, 30 minutes and free, is there to establish which private repositories your GitHub agent can read and expose.

Further reading

• agent hijack via PR comment
• prompt injection through a dependency