GitLost Shows How a GitHub Issue Could Make an AI Agent Leak Private Repo Data

A newly disclosed AI security issue called GitLost shows how a crafted GitHub Issue could trick GitHub Agentic Workflows into pulling content from private repositories and posting it in a public comment.

The issue was discovered by Noma Labs, which said an unauthenticated attacker could exploit a vulnerable workflow by opening a public issue in an organization that also had private repositories available to the agent.

The attack did not require stolen credentials, repository access, or code execution on GitHub infrastructure. It relied on indirect prompt injection, where attacker-controlled text in an issue body gets treated by an AI agent as an instruction instead of untrusted data.

What GitLost targeted

GitHub Agentic Workflows combine GitHub Actions with coding agents that can understand repository context and perform automation based on Markdown instructions. The official GitHub Agentic Workflows site describes the feature as repository automation that runs coding agents in GitHub Actions with guardrails, cost controls, and security-first design principles.

GitHub announced the feature in February 2026 as a technical preview. In that GitHub changelog post, the company said users could write workflows in Markdown instead of complex YAML and let AI handle tasks such as issue triage, pull request review, CI analysis, and repository maintenance.

That flexibility also creates a new trust problem. If an AI workflow reads public issues, pull requests, comments, files, or other user-controlled content, attackers may try to hide instructions inside that content and influence what the agent does next.

Item	Details
Issue name	GitLost
Researcher	Noma Labs
Attack type	Indirect prompt injection
Entry point	A crafted GitHub Issue in a public repository
Main risk	Private repository content exposed through a public issue comment
Required attacker access	No GitHub credentials or repository access in the demonstrated attack path

How the GitLost attack worked

The vulnerable workflow Noma Labs tested was triggered when an issue was assigned. It read the issue title and body, used an add-comment tool to respond, and had read access across public and private repositories in the same organization.

The attacker’s issue looked like a normal business request. Inside the issue body, the researcher placed natural-language instructions that asked the agent to retrieve README content from repositories, including a private repository, and include the output in its public reply.

According to the GitLost write-up, once the issue was assigned and the workflow ran, the agent fetched README.md content from both public and private repositories and posted it as a public comment.

• The attacker opened a normal-looking issue in a public repository.
• The issue contained hidden or framed instructions for the AI agent.
• The workflow was triggered when the issue was assigned.
• The agent used its repository access to fetch data from other repositories.
• The agent posted the private repository content in a public comment.

Why the word “Additionally” mattered

Noma Labs said the attack became more reliable when the prompt used the word “Additionally.” The word helped reframe the request in a way that bypassed existing guardrails in the tested workflow.

This detail matters because it shows how small wording changes can influence agent behavior. Traditional security checks often look for clear signs of malicious input, but prompt injection can hide inside ordinary business language.

The risk also matches a broader problem described by the OWASP prompt injection guidance, which says attackers can manipulate model responses through crafted input and cause systems to ignore or bypass intended controls.

Why private repo access made the flaw more dangerous

GitLost became serious because the agent had access beyond the public repository where the issue was created. Once the agent accepted the issue text as an instruction, it could use its legitimate permissions to retrieve data the attacker could not access directly.

The official GitHub Agentic Workflows documentation says these workflows use layered controls such as read-only tokens, sandboxing, scoped permissions, and safe outputs. GitLost shows why those controls must also account for untrusted text entering the model’s context window.

GitHub’s technical preview announcement also noted that workflows run with read-only permissions by default and use preapproved safe outputs for write operations. In this case, a read operation combined with a public comment output still created a data leak path.

Control area	GitLost lesson
Read permissions	Read-only access can still leak sensitive data if the agent can publish the output.
Issue content	User-controlled issue text should never become trusted instruction input.
Cross-repository access	Private repository access should be narrowly scoped to the workflow’s real task.
Safe outputs	Public comments need content filtering when an agent can read private data.
Prompt guardrails	Model refusals alone cannot replace deterministic permission boundaries.

GitLost fits a wider agentic workflow risk

GitLost is not only a GitHub issue. It reflects a wider security challenge for agentic AI systems that read external content and then use tools on behalf of users or organizations.

A recent academic study on Agentic Workflow Injection described how untrusted GitHub event context, including issue bodies, pull request descriptions, and comments, can flow into agent prompts and influence tool use or downstream workflow logic.

The same Agentic Workflow Injection study found hundreds of exploitable cases in real-world agentic workflows. That makes GitLost part of a broader category, not a one-off trick against one workflow.

How developers can reduce GitLost-style exposure

Organizations using agentic workflows should review every workflow that reads public issues, comments, or pull request content. Any workflow that can read private repositories and write public comments deserves special attention.

The safest approach is to separate untrusted user content from system instructions. Developers should also restrict which repositories an agent can read and block public output that includes private repository data, secrets, source snippets, internal paths, or sensitive metadata.

The OWASP prompt injection guidance recommends treating prompt injection as a major LLM risk. For agentic systems, that means combining model-level safeguards with classic controls such as least privilege, input handling, output validation, and audit logging.

1. Review all agentic workflows that trigger on issues, comments, pull requests, or discussions.
2. Remove cross-repository access unless the workflow clearly needs it.
3. Do not allow public issue comments to include content retrieved from private repositories.
4. Label issue titles, issue bodies, comments, and pull request text as untrusted input inside workflow instructions.
5. Use allowlists for repositories, files, and tools that the agent can access.
6. Require human approval before an agent publishes content gathered from private repositories.
7. Log agent tool calls and review cases where agents read private repositories during public issue workflows.

Bottom line

GitLost shows that an AI agent’s context window can become part of the attack surface. If an agent reads untrusted content and has access to private repositories, attackers may be able to turn normal collaboration features into a data exposure path.

The fix is not only better prompting. Teams need strict repository scoping, safer output rules, human review for sensitive actions, and clear separation between instructions and user-controlled content. For agentic workflows, read access can still become a leak if the agent also has a public place to write.

FAQ