Researchers say a crafted public GitHub issue could steer an AI agent into posting private repository data, underscoring why agent permissions, output gates and CI/CD trust boundaries now need first-class review.
NEW DELHI, July 8, 2026, 10:53 p.m. IST – A reported prompt-injection weakness in GitHub Agentic Workflows is putting a familiar DevSecOps problem into sharper focus: AI agents can only be as safe as the permissions, inputs and output channels wrapped around them.
Noma Security said this week that its researchers demonstrated a technique, dubbed GitLost, that could make a configured GitHub Agentic Workflow read from private repositories and publish the contents in a public issue comment. The attack described by Noma does not require stolen credentials or direct access to the private repository. It depends on a public issue being processed by an AI agent that also has broader repository read access inside the same organization.
The disclosure matters now because agentic coding systems are moving quickly from experiments into CI/CD-adjacent automation. GitHub introduced Agentic Workflows earlier this year as a way to write repository automations in Markdown and let an AI agent run inside GitHub Actions. GitHub’s own documentation says the feature uses layered controls such as sandboxing, scoped permissions and gated outputs, while also warning that AI agents can be manipulated by prompt injection, malicious repository content or compromised tools.
GitLost is not a report that every GitHub repository is exposed. It is a warning about a specific operating pattern: an agent reads untrusted public input, holds access to private code or internal files, and can write a response into a place outsiders can see. For platform teams, that combination should be treated as a design review trigger before any agentic workflow is allowed near production repositories.
What Researchers Confirmed
In Noma’s published proof of concept, the workflow was configured to run when an issue was assigned, read the issue title and body, and post a comment. The agent also had read access to other repositories in the organization, including private repositories. Noma said a normal-looking public issue containing hidden plain-English instructions was enough to direct the agent to fetch README content from both public and private repositories and paste it into the public issue thread.
The researchers said GitHub had guardrails intended to block this class of behavior, but their testing found a bypass. Noma reported that adding a transition word to the prompt caused the model to treat the malicious request as a follow-on task rather than something to refuse.
Independent coverage by SecurityWeek, The Hacker News, DevOps.com and The Register broadly described the same finding: the issue is an indirect prompt-injection scenario in which untrusted public content is treated as operational instruction by an AI agent with more privileges than the attacker. The Register reported that GitHub had not responded to its request for comment by publication time.
Why This Is a DevOps Issue, Not Just an AI Issue
The practical risk is not that the model says something wrong. The risk is that an agent with repository permissions does something wrong. That makes the control plane familiar to DevOps and platform engineering teams: identity, least privilege, event triggers, secrets handling, logging, change approval and output review.
Teams adopting AI coding agents often want cross-repository context because real software systems span services, libraries and infrastructure code. But broad read permissions become dangerous when the same agent also consumes public issues, pull request text, comments or files from forks. In traditional CI/CD, untrusted input from a public issue would not normally be granted the ability to read private repositories and publish derived content. Agentic workflows can blur that boundary if access reviews focus only on the automation feature and not on the end-to-end data path.
This is also why simple prompt wording is not a sufficient control. A model-level refusal is a backstop, not an authorization boundary. The stronger boundary is architectural: keep the agent from seeing data it does not need, keep untrusted text out of privileged instruction paths, and require review before an agent can publish anything derived from private systems.
What Platform Teams Should Check Today
Organizations using GitHub Agentic Workflows or similar AI-backed repository automation should first inventory which workflows can be triggered by public issues, pull requests or comments. Any agent that can process outsider-controlled content should have tightly scoped tokens, ideally limited to the repository where the work occurs. Broad organization-level read access should be treated as exceptional and reviewed separately.
Second, teams should examine output paths. If an agent can comment on a public issue, update a public pull request, create artifacts, open tickets or call webhooks, that output channel becomes part of the security model. Human approval gates are slower than fully autonomous agents, but they are appropriate when the agent can combine public input with private context.
Third, security teams should monitor agent activity with the same seriousness given to service accounts and CI runners. Logs should show what event triggered a run, which repositories were accessed, what files were read and what the agent posted or attempted to post. Alerts should fire when a workflow triggered by public content accesses private repositories or produces unusually large comments, attachments or outbound calls.
Finally, teams should update their threat models for AI-assisted delivery. If a workflow relies on retrieval, agents, model context or tool calls, the relevant question is not only whether the model is accurate. It is whether the system can preserve trust boundaries when the model is asked to act on untrusted text. GravityDevOps readers already building with LLMs may find related context in our guides to prompt engineering for developers, LLMOps, RAG systems and CI/CD tooling.
Context and Caution
GitLost fits a broader pattern seen across agentic development tools: the more useful an agent becomes, the more it tends to need access to repositories, tickets, package managers, terminals, documents and cloud systems. That access can raise productivity, but it also turns the agent into a credentialed actor inside the software delivery system.
The balanced takeaway is not to abandon AI automation in DevOps. It is to stop treating agent security as a prompt-design problem. Developers and platform teams should evaluate agentic workflows the way they evaluate CI runners, deployment bots and privileged service accounts. Restrict their scope, separate trusted and untrusted inputs, gate sensitive outputs and assume that attackers will try to put instructions wherever the agent reads.
Noma’s disclosure is especially useful because it describes a realistic path: public issue, event trigger, private repository read, public comment. That is the kind of concrete chain a DevSecOps team can test against its own environment. If an internal agent can reproduce that pattern, the problem is not theoretical.
FAQ
Are all GitHub users affected? No. The reported risk applies to organizations that have enabled agentic workflows or comparable AI automation, process untrusted public content, give the agent access to private repositories and allow the agent to post output publicly.
What is the fastest mitigation? Remove broad cross-repository read access from agents that process public issues or pull requests. Then add human review for public outputs and audit recent agent runs for unexpected private repository reads.
Is this only a GitHub problem? No. The same architectural risk can appear in any agentic system that combines sensitive data access, untrusted instructions and an output path. GitHub is the current example because GitLost was demonstrated against GitHub Agentic Workflows.
Sources
This article is based on Noma Security’s GitLost research disclosure, GitHub’s Agentic Workflows technical preview announcement, the GitHub Agentic Workflows documentation, and reporting from SecurityWeek, The Hacker News, DevOps.com and The Register.
