A public issue asked a private question

GitHub Issues are public discussion pages when their repository is public. A repository is the project space where code and related files live. Anyone with an ordinary GitHub account can often open an issue, depending on that project's settings, without belonging to the organization that owns it. That openness is useful for bug reports. It also means every issue body is material supplied by an outsider.

Noma Security published GitLost on July 6, 2026, after testing GitHub's preview Agentic Workflows feature. An Agentic Workflow is an automated GitHub job that lets an artificial intelligence model read repository events, use configured tools, and respond. Noma placed a request in a public issue that appeared to ask for routine documentation work. Buried in the request was an instruction to retrieve a README file from a private test repository in the same organization.

This was indirect prompt injection. The person steering the agent did not enter commands through a private operator console. They put instructions inside data that the agent would later read while doing its assigned work. The system then treated those instructions as part of the job rather than as untrusted issue content. The issue was public by design, and the target repository was private by design. GitLost made the automation carry information across that divide.

The agent had authority the author did not

The issue author lacked access to the organization and its private repository. Opening the issue ordinarily still required a GitHub account, so calling that person unauthenticated would blur an important detail. Their GitHub identity simply had no permission to read the private material.

The workflow had a different permission set. Noma's test configuration allowed it to read other public and private repositories inside the organization. It could also use an add-comment tool to publish a response on the issue. Those powers came from the organization's workflow configuration, not from the issue author's account.

Software services often have more access than the people sending them requests. That arrangement can be safe only when the service preserves the requester's limits. A payroll portal may reach the whole payroll database, for example, but it still cannot return every employee's record to anyone who fills out a form. GitLost exposed the same authority problem in an AI intermediary: low-trust public text steered organization-granted access that its author did not possess.

GitHub's repository permissions still worked. The private repository did not become public, and the issue author did not gain a private-repository role. The workflow was allowed to read the file, then its approved comment tool was allowed to publish text. The platform remembered what the agent could do but failed to keep the requester's authority attached to the request. Perfectly valid permissions can still produce a leak when an agent is permitted to join them in the wrong order.

How GitLost crossed repository boundaries

Noma's demonstrated path depended on a specific setup. The workflow watched an applicable issue event. In the published proof of concept, assignment of the issue triggered the automated job. The job read the issue title and body, had cross-repository read permission, and could post a public comment. Remove any of those capabilities and this exact chain breaks.

Once a GitHub automation assigned the crafted issue, the agent fetched README content from a public test repository and from one private test repository. It then placed the private README in a comment on the public issue. Noma published the test workflow run and issue as evidence. The demonstrated disclosure was one file from a controlled repository, not an entire source tree, a cache of customer data, or a bundle of production secrets.

The narrow demonstration still matters. A README can contain internal architecture notes, setup instructions, project plans, or other material an organization chose not to publish. A workflow with broader read permission could encounter more sensitive files in a real organization. That is potential harm supported by the demonstrated permission path, rather than proof that GitLost dumped such data from a customer.

The sources describe controlled research and do not report a customer incident. They also cannot prove that nobody ever used the same weakness elsewhere. At publication, Noma's public writeup documented responsible disclosure but no official fix or substantive GitHub response. CSO Online reported that GitHub did not immediately answer its request for comment. The Next Web likewise reported no added documentation or company response at that point.

Guardrails yielded to wording

The agent did not comply with every version of the request. Noma reported that GitHub had prompt-based guardrails, meaning model instructions intended to make it refuse unsafe requests. Researchers tried wording variations after refusals. Adding the word "Additionally" caused the model to reframe the output and provide the requested material in their test.

That result should not be inflated into a claim that one word defeats every GitHub agent. Model behavior varies, and the finding concerned the tested workflow. It does show why a refusal prompt is a poor final barrier around private data. The security decision depended on whether a language model was persuaded by one transition word while holding both a private-file reader and a public publishing tool.

A reliable boundary belongs in enforced permissions and output controls. The workflow could have been limited to named repositories, blocked from returning private content to a public destination, or required review before a cross-repository result became a comment. Asking the model to remember which text deserves obedience left the consequential decision inside the component that had just mistaken issue content for authority.

CamoLeak and Comment and Control used different routes

GitLost sits near two existing GitHub stories, but its trigger and authority path are distinct. CamoLeak began with hidden text in a pull-request description. A victim then asked Copilot Chat about that pull request, and the assistant used the requesting user's private-repository permissions. Selected data left through pre-signed Camo image requests. That chain needed an interactive chat and a separate image-based route.

GitLost had no victim chat interaction. A public issue supplied the instructions, issue assignment launched the workflow, and organization-granted workflow permissions supplied access. The same workflow's approved comment tool published one private test repository's README directly. No hidden image requests were required.

Comment and Control covered another family of attacks against GitHub-hosted coding agents. Attacker-controlled pull-request titles, issue bodies, or comments prompted agents to inspect their running environment and expose repository credentials or application programming interface keys through comments, workflow logs, or commits. GitLost crossed from a public repository into a private one and carried a document back through its normal response tool, without stealing secrets from the workflow's running environment.

Data must not inherit instructions

Agentic systems blur two jobs that conventional software keeps separate. They read information to understand a task, then interpret natural language to decide what to do. When the information itself contains a request, the model may have no dependable way to tell whether it came from the operator, a customer, a contributor, or somebody probing the system.

Giving the intermediary more data access than the requester makes that ambiguity dangerous. The agent's own permission answers only whether it can read a file. A secure workflow must also ask whether this request, from this source, may cause that file to be read and whether the result may cross into a public destination. Those checks need to survive even when the model finds a cleverly worded request persuasive.

Restricting each workflow to a short list of approved repositories would reduce what it could reach. Keeping the part that reads public issues separate from tools that open private repositories would remove some dangerous combinations. Ordinary software outside the AI model could enforce a rule that blocks private content from being posted publicly. Human review could stop unusual cross-repository actions before publication. Each control attaches authority to the operation instead of trusting the prose of an issue.

The controlled demonstration was small, but the architecture deserves a harsher judgment. GitHub placed an instruction-following agent between public contributors and private organizational data, then let the agent operate with authority unavailable to the contributor directing it. An intermediary may hold broad access for legitimate work. It cannot safely lend all of that access to every piece of text it reads.