cd /news/ai-safety/github-ai-agent-leaks-private-reposi… · home topics ai-safety article
[ARTICLE · art-51079] src=infoworld.com ↗ pub= topic=ai-safety verified=true sentiment=↓ negative

GitHub AI agent leaks private repositories via prompt injection attack

GitHub's preview Agentic Workflows are vulnerable to a prompt injection attack that can leak private repository contents, according to Noma Security. An unauthenticated attacker can embed hidden instructions in a public GitHub issue, causing the AI agent to retrieve and publish sensitive data from private repos. The flaw highlights architectural risks in AI agents with privileged access to development environments.

read4 min views1 publishedJul 8, 2026

A prompt injection attack can trick GitHub’s preview Agentic Workflows into retrieving content from private repositories and publishing it publicly, exposing a broader risk as enterprises deploy AI agents with privileged access to software development environments, according to new research from Noma Security.

The AI security company detailed the attack, dubbed GitLost, in a blog post, saying an unauthenticated attacker could exploit GitHub’s preview Agentic Workflows by submitting a crafted GitHub issue to a public repository. If the AI agent has read access to private repositories within the same organization, it can retrieve sensitive information and publish it in a public comment, the company said.

GitHub Agentic Workflows combine GitHub Actions with AI models such as Claude or GitHub Copilot, allowing developers to define workflows in Markdown. At the same time, AI agents read issues, invoke tools, and perform tasks on their behalf.

“What will happen when the GitHub agent reads something it should not trust?” Noma researcher Sasi Levi wrote. “The answer is a textbook indirect prompt-injection attack, the kind of attack that quietly sends private data to anyone on the internet.”

According to Noma, the attack did not rely on stolen credentials, malware, or software vulnerabilities. Instead, an attacker embedded hidden instructions within a GitHub Issue submitted to a public repository.

Because the AI agent interpreted the issue as instructions rather than untrusted content, it accessed a private repository and posted its contents back to the public issue, the blog post added.

“The root cause of the GitLost vulnerability is, by now, a familiar one in agentic AI systems: prompt injection,” Levi wrote. “In this specific case, any malicious actor can create a GitHub Issue and, in the issue body, hide commands in plain English that GitHub’s agent will follow.”

To demonstrate the attack, the researchers created what appeared to be a routine GitHub Issue requesting documentation updates. Once the workflow was triggered, the AI agent retrieved the README file from a private repository and published its contents in a publicly visible comment.

The researchers also said they bypassed GitHub’s prompt-based guardrails by making a minor wording change that caused the AI agent to comply with instructions it had previously rejected.

GitHub did not immediately respond to a request for comment.

Noma said GitLost illustrates a broader architectural challenge for AI agents rather than a flaw unique to GitHub.

“The issue is not that GitHub’s AI agent is unusually insecure,” Levi wrote. “The issue is that any AI agent with access to both untrusted external content and sensitive internal resources can become an unintended bridge between the two if trust boundaries are not enforced.”

Independent cybersecurity researcher and red teamer Vibhum Dubey said the findings expose a more fundamental issue than prompt injection alone.

“This isn’t prompt injection in the abstract. This is GitHub shipping agent permissions before shipping agent security,” Dubey said. “The vulnerability exposes that AI agents operate on a service account permission model, not a user permission model. That’s an architectural assumption security teams made before considering LLMs as an attack vector.”

According to Dubey, the prompt injection itself is almost secondary.

“What’s dangerous is that trust boundaries exist in GitHub’s data model but nowhere in the agent’s execution context,” he said. “The agent doesn’t ‘know’ a repository is private. It just sees ‘accessible.’ As more organizations deploy agents, we’re accumulating these invisible permission gaps.”

Dubey said organizations should rethink how AI agents are granted permissions rather than treating the issue primarily as a monitoring challenge.

“Three concrete fixes: Agents get explicit repository whitelists, not broad service account access. All user inputs, including commit messages, PR descriptions, and issues, should be validated before reaching the LLM. And have an emergency kill-switch ready,” he said. “Most teams can disable a compromised API key. Can you disable a rogue agent?”

Dubey said GitLost demonstrates how AI agents can effectively become an insider threat once granted broad organizational access.

“The brilliance of GitLost isn’t that it fooled an AI. It’s that it weaponized GitHub’s assumption that service accounts are trustworthy,” he said. “Agents were explicitly built to bypass human judgment and operate autonomously. That’s exactly why they’re dangerous: we normalized cross-boundary operations the moment we automated them.” Noma also recommended applying least-privilege access controls, limiting AI agents’ cross-repository access, and treating GitHub Issues, pull requests, and comments as untrusted input.

── more in #ai-safety 4 stories · sorted by recency
── more on @github 3 stories trending now
sponsored brought to you by zahid.host 4,200+ EU-deployed projects
reading about agents? ship yours in a single git push.

Run your AI side-project on zahid.host

EU-based hosting, git-push deploys, automatic HTTPS, no cold starts. Free tier with a custom domain — perfect for shipping the agent you just read about.

$git push zahid main
Live at https://your-agent.zahid.host
Get free account → Pricing
from €0/mo · no card required
LIVE [news/github-ai-agent-leak…] indexed:0 read:4min 2026-07-08 ·