On 6 July 2026, researchers at Noma Labs published GitLost — a proof of concept in which a single, innocuous-looking GitHub issue coerced GitHub's own AI agent into reading a private repository and posting its contents into a public comment. There was no exploited software bug in the traditional sense: no memory corruption, no authentication bypass, no leaked token. The attacker needed only the ability to open an issue on a public repository belonging to the target organisation. The agent did the rest, using access it legitimately held, because it could not tell the difference between an instruction from its operator and text written by a stranger on the internet.
This is not a novel class of failure. It is the same structural weakness we have covered repeatedly through 2026 — in Meta's Instagram support agent, in Microsoft 365 Copilot, in the LangChain and LangGraph ecosystem. What makes GitLost worth a dedicated read for Swiss engineering and security teams is where it lands: not in a customer-facing chatbot, but inside the software supply chain, in a workflow many development teams are actively enabling this year. This article is a summary and analysis of Noma Labs' research; the original write-up is linked above and is the primary source for the technical details that follow.
What GitHub Agentic Workflows Actually Do
GitHub's Agentic Workflows pair GitHub Actions with an AI agent — backed by frontier models — that reads repository events such as new issues, and then executes tools autonomously based on natural-language instructions defined in Markdown workflow files. The appeal is obvious: an issue is filed, the agent triages it, gathers context across the codebase, drafts a fix, and comments back, all without a human in the loop. To do this usefully the agent is granted broad read access across the organisation's repositories, including private ones, and the ability to post public comments on the issues it processes.
Those two capabilities — cross-repository read access and public write access — are individually reasonable and jointly dangerous. The moment untrusted content can steer what the agent reads and where it writes, the combination becomes an exfiltration primitive. That is precisely the gap Noma Labs walked through.
The Attack, Step by Step
According to Noma Labs' write-up, the exploitation path required no privileged position:
- The attacker opens a seemingly innocent issue on a public repository within the target organisation. Anyone with a GitHub account can do this.
- The issue body carries hidden instructions written in plain English, disguised as part of a legitimate request.
- A workflow trigger — for example, the issue being assigned or labelled — causes the agent to read the issue title and body as part of its normal task.
- The agent treats that issue content as a trusted instruction rather than as untrusted data, and follows it.
- Using its cross-repository read access, the agent fetches content from a private repository the attacker could never see directly.
- The agent posts the retrieved private content as a public comment on the issue, where anyone can read it.
The researchers reported a detail that captures how brittle the guardrails were: prefacing the malicious request with the word "Additionally" was enough to get the model to reframe its output and slip past the controls that were supposed to prevent unauthorised access. Their proof of concept exfiltrated the README of a private repository (testlocal) alongside those of public ones — demonstrating that the boundary between "content the agent may surface publicly" and "content it must keep private" had effectively collapsed.
◆ Key Takeaway
GitLost is a data-exfiltration vulnerability with no exploit code. The attacker supplies natural-language text in a public issue; the agent supplies the privileged access and the public megaphone. The root cause is a trust-boundary failure — the agent treats attacker-controlled issue content as a trusted source of instructions. No amount of content filtering on the issue text fixes this, because the malicious instruction is indistinguishable from a legitimate one. The fix is architectural: constrain what the agent is allowed to do, not what users are allowed to say.
Why This Is the Same Story We Keep Telling
Readers of Swiss Security Insights will recognise the shape of this immediately. The mechanism is identical to incidents we have already analysed in depth:
- In the Instagram VIP takeover, attackers used multi-turn prompt injection to coerce Meta's support agent — which held write access to authentication data — into rerouting account recovery and bypassing MFA. Same trust-boundary failure, different blast radius.
- In SearchLeak (CVE-2026-42824), a Microsoft 365 Copilot flaw allowed one-click data theft when the assistant processed attacker-influenced content with access to a user's tenant data.
- In our analysis of AI agent vulnerabilities in LangChain and LangGraph, we set out how granting agents tool access without hard authorisation boundaries turns every reachable tool into a potential exfiltration channel.
- In our MCP agent security framework, we argued the same principle from the defensive side: agents must operate under least privilege and explicit allowlists, with human approval gating any consequential action.
GitLost adds an important twist. The Instagram and Copilot cases involved agents exposed to end users. GitLost involves an agent embedded in the development pipeline — the place where teams keep source code, secrets, infrastructure definitions and, increasingly, the AI-generated code we recently warned is shipping to production faster than it can be reviewed. A prompt injection that reaches into private repositories is not a customer-service embarrassment; it is a potential source-code and secrets breach.
Disclosure and GitHub's Response
Noma Labs reported that GitLost was responsibly disclosed to GitHub, with GitHub aware of the findings ahead of the 6 July 2026 publication. The research is credited to Sasi Levi of Noma Labs as part of the firm's vulnerability research programme. As of publication, Noma's write-up does not enumerate a specific GitHub-side remediation beyond acknowledging the disclosure; teams relying on Agentic Workflows should monitor GitHub's own security advisories and changelog for configuration changes and guardrail updates, and treat the mitigations below as controls they own regardless of platform-level fixes.
What Swiss Engineering Teams Should Do Now
The Swiss angle is straightforward. Agentic developer tooling is being adopted across Swiss software, fintech and industrial engineering teams at exactly the moment regulators are sharpening their expectations for supply-chain and AI governance. An agent with cross-repository read access processing untrusted issue content is, in effect, an automated decision-making system with access to sensitive data — which brings it within scope of nDSG technical-and-organisational-measure obligations and, for high-risk deployments in EU-facing groups, the EU AI Act's logging and human-oversight requirements. Concretely:
- Treat all issue, PR and comment content as untrusted input. Any agentic workflow that reads user-supplied text must never treat that text as instruction. Isolate untrusted data from the instruction context before it reaches the model, and assume any string an outsider can write is adversarial.
- Break the exfiltration chain by separating read scope from write scope. An agent that can read private repositories should not be able to post to public surfaces in the same run, and vice versa. Removing either half of the primitive defeats the attack even when the injection succeeds.
- Apply least privilege to repository access. Scope agent access to only the repositories a given workflow genuinely needs. Broad org-wide read access is the reason a public issue could reach a private README.
- Gate consequential actions behind human approval. Posting external comments, opening PRs against other repositories, or reading outside the triggering repository should require review, not autonomous execution.
- Log every agent tool invocation with the input that triggered it. Prompt injection is most reliably caught through behavioural analysis of tool-call sequences — an issue read followed by a private-repo fetch followed by a public comment is an anomalous pattern even when each step looks benign in isolation.
- Red-team your agentic workflows before enabling them org-wide. Test injection payloads through issues, PR descriptions and comments against your actual workflow configuration. The "Additionally" bypass shows how little effort a working attack can take.
- Keep secrets out of repositories the agent can reach. If exfiltration is possible, assume it will happen; a README is the demonstration, but the real prize is credentials, tokens and infrastructure definitions.
GitLost is not an exotic edge case — it is the predictable result of pointing a capable, broadly-permissioned agent at content that anyone on the internet can write. As Swiss teams wire AI agents ever deeper into their development pipelines, the lesson from Noma Labs' research is the same one we have drawn from every prompt-injection incident this year: you cannot filter your way to safety when the malicious input is indistinguishable from the legitimate one. The defensible posture is architectural constraint — least privilege, separated read and write scopes, human gates on consequential actions, and the working assumption that untrusted text is hostile. The organisations that internalise this before enabling agentic workflows will avoid discovering, the hard way, exactly what their agent was permitted to reach.
Source: Sasi Levi, Noma Labs — "GitLost: How We Tricked GitHub's AI Agent Into Leaking Private Repos" (6 July 2026). This article is an independent summary and analysis for a Swiss audience; refer to the original for full technical detail.