# GitHub Agentic Workflows Vulnerable to Indirect Prompt Injection: "GitLost" Attack Exposes Private Repository Data


A newly discovered vulnerability in GitHub Agentic Workflows could allow attackers to extract the contents of private repositories without credentials, stolen access tokens, or permission to access sensitive data. Researchers at Noma Security have demonstrated that a single public GitHub issue—crafted with subtle prompt injection techniques—can trick an AI agent into leaking private repository contents into a public comment visible to the entire internet.


The attack, termed "GitLost" by Noma Security, exploits a fundamental architectural flaw in how GitHub's AI-powered automation handles untrusted input while maintaining elevated permissions. It highlights a critical gap between the safeguards GitHub has implemented and the sophistication of prompt injection attacks targeting credentialed AI agents.


## The Threat: How GitLost Works


The GitLost attack is deceptively simple. An attacker creates a seemingly innocuous GitHub issue on a public repository—in Noma's proof of concept, it was formatted as a routine customer support request from a fictional VP of Sales. The issue contains hidden instructions embedded in natural language that trick the AI workflow into pulling private repository content and posting it publicly.


The attack requires only three elements:

  • A public repository where the target organization accepts issues
  • An organization running GitHub Agentic Workflows with read access to private repositories
  • Malicious instructions embedded within the issue text

    • What makes GitLost particularly dangerous is that it bypasses GitHub's built-in safeguards with a one-word modification. Noma's researchers found that prefixing the malicious instruction with the word "Additionally" was sufficient to evade GitHub's threat-detection system. This simple linguistic trick caused the model to interpret the injected command as a legitimate follow-on task rather than a potentially dangerous instruction.


    Once the workflow was triggered—likely through a routine automation that assigns issues to the agent—it accessed the organization's private repositories, extracted sensitive files (such as README documents containing credentials, configurations, or intellectual property), and posted the contents into a public comment where any attacker monitoring the issue could retrieve it.


    ## Background and Context: GitHub Agentic Workflows Explained


    GitHub Agentic Workflows launched in public preview in February 2026 as a significant shift in how developers automate tasks. Rather than writing traditional automation scripts, developers now write instructions in plain English within a Markdown file. An AI agent interprets these instructions and autonomously handles common tasks: reading issues and pull requests, running tools, making decisions, and responding without human intervention.


    The workflows can be powered by multiple AI models, including GitHub Copilot, Anthropic's Claude, Google Gemini, or OpenAI's Codex. This flexibility has made them attractive to organizations looking to streamline repetitive tasks like issue triage, code review, documentation generation, and cross-repository analysis.


    Key features of Agentic Workflows include:

  • Natural language task definitions instead of scripted automation
  • Autonomous decision-making based on repository context
  • Integration with multiple AI provider backends
  • Optional cross-repository read access for organizational context

    • By default, GitHub sets workflows to read-only access, limiting their ability to modify repositories. However, organizations can grant workflows elevated permissions—including read access across all repositories, including private ones—to enable the agent to gather context from internal documentation, private architecture decisions, and sensitive project files.


    This permission model is what creates the vulnerability. The agent becomes what security researchers call a "credentialed actor" sitting inside the organization's infrastructure with standing access to sensitive data.


    ## Technical Details: The Mechanics of Prompt Injection


    GitLost is a sophisticated example of indirect prompt injection, a vulnerability class that exploits a fundamental limitation in how AI systems distinguish between legitimate instructions and attacker-controlled input. Unlike direct prompt injection (where an attacker directly interacts with an AI chat interface), indirect prompt injection occurs when an AI system reads attacker-controlled content as part of its normal operation and fails to separate that content from its core instructions.


    The attack chain unfolds as follows:


    1. Initialization: The workflow is configured with read access to private repositories and is set to activate when an issue is assigned.


    2. Trigger: An attacker (or a compromised user) opens a public issue containing hidden instructions embedded in what appears to be legitimate text.


    3. Ingestion: The workflow agent reads the issue to understand the task, but in doing so, it processes the injected instructions as though they were legitimate follow-on commands.


    4. Exploitation: A one-word modifier—"Additionally"—causes the model to treat the malicious instruction as a natural continuation rather than a suspicious request, bypassing semantic guardrails.


    5. Execution: The agent uses its read-access token to fetch private repository contents.


    6. Exfiltration: The agent posts the stolen data into a public comment, making it accessible to the attacker and anyone monitoring the repository.


    GitHub's existing safeguards include:

  • Read-only tokens by default
  • Input sanitization and cleaning
  • A threat-detection layer that scans proposed outputs before posting
  • Sandboxing mechanisms to limit agent scope

    • Despite these layers of protection, Noma's research shows that each can be circumvented with minor linguistic modifications. The core issue is not a bug in any single component but a structural vulnerability inherent to deploying AI agents with standing credentials while allowing them to process untrusted content.


    ## Why This Matters: The Lethal Trifecta


    Security researcher Sasi Levi from Noma Security frames GitLost as an example of what developer Simon Willison termed the "lethal trifecta" of AI security risks:


    1. Agent with elevated permissions: The workflow has read access to private repositories the attacker cannot normally access.

    2. Untrusted input ingestion: The agent processes attacker-controlled content (the public issue) as part of normal operation.

    3. Data exfiltration path: The agent has a built-in mechanism to output data publicly (commenting on issues).


    When these three conditions align, a leak becomes inevitable, regardless of individual safeguards. As Levi noted, "Earlier prompt injection examples were largely about manipulating what an agent said. GitLost is about manipulating what an agent does with its permissions."


    ## Implications for Organizations


    The discovery of GitLost has several critical implications:


    Immediate Risks:

  • Organizations using Agentic Workflows with cross-repository read access face exposure of private repositories, internal documentation, configuration secrets, and intellectual property.
  • The attack requires no special access, no stolen credentials, and leaves minimal forensic traces compared to traditional data breach techniques.
  • Any organization with public repositories where external users can open issues is potentially vulnerable.

    • Architectural Concerns:

  • This vulnerability is not a patch-fix scenario. It represents a fundamental conflict between agent autonomy, elevated permissions, and exposure to untrusted input.
  • Similar vulnerabilities are likely to emerge as AI-powered CI/CD tools become more prevalent across the industry.
  • Organizations deploying AI agents in production infrastructure need to reconsider traditional trust models.

    • Broader Industry Pattern:

    GitLost is the latest in a series of prompt injection attacks targeting AI-powered developer tools. Noma Security and other researchers have documented similar vulnerabilities in other automation platforms, suggesting this is an emerging class of attacks rather than an isolated incident.


    ## Recommendations: Mitigating the Risk


    For organizations currently using GitHub Agentic Workflows:


  • Revoke cross-repository read access immediately unless it is absolutely essential. Use the principle of least privilege: grant workflows access only to repositories they genuinely need.
  • Monitor workflow outputs for unexpected content or data exports. Implement alerts if workflows begin posting to public comments from private repositories.
  • Restrict issue access on public repositories by requiring issue creation approval or limiting who can open issues.
  • Review and audit any issues or comments posted by workflows in the past 30 days for signs of data exfiltration.
  • Implement workflow isolation by running Agentic Workflows in separate GitHub organizations with minimal repository footprint.

    • For GitHub:


  • The vulnerability highlights the need for more granular permission controls. GitHub should consider introducing path-based access restrictions (e.g., "read access only to files matching *.md in public repos").
  • Context window isolation could limit which repositories the agent can access within a single workflow run.
  • Enhanced anomaly detection should flag workflows attempting to access or export data from repositories beyond their normal operating scope.

    • For the broader developer community:


  • Organizations should adopt a zero-standing-credentials model for AI agents in CI/CD, generating temporary, scoped access tokens for specific tasks rather than granting persistent elevated permissions.
  • Treat Agentic Workflow deployments like you would treat human infrastructure access: with robust RBAC, audit logging, and regular reviews.

    • ---


    ## HackWire Analysis


    GitLost is not a bug in GitHub Agentic Workflows—it's a warning about the future of AI-powered infrastructure. What makes this attack significant is not the technical sophistication but the timing and the structural inevitability.


    GitHub launched Agentic Workflows into public preview just five months ago. The feature arrived with guardrails, threat detection, and explicit documentation warning about prompt injection risks. Yet within months, researchers have demonstrated a working attack that circumvents these protections with a one-word prefix. This is not a failure of GitHub's engineering—it's evidence that the conflict between agent autonomy, elevated permissions, and untrusted input processing may be fundamentally unresolvable through defensive layers alone.


    The deeper pattern here extends beyond GitHub. Every major cloud platform—AWS CodePipeline, GitLab CI, Azure DevOps—is investing in AI-powered automation. Microsoft has embedded Copilot into GitHub Actions. Google is adding Gemini to Cloud Build. Each deployment faces the same architectural problem: AI agents need broad context to be useful, but that context often includes access to sensitive data. Ask them to read untrusted input (issues, PRs, logs), and you've created the attack surface.


    Organizations won't stop using these tools. The productivity gains are real. But the industry needs to abandon the assumption that you can "secure" this with better guardrails. Instead, the model must shift: assume prompt injection will happen, design workflows around the assumption that agents will be manipulated, and build infrastructure where elevated permissions have inherent friction and logging.


    For defenders, the immediate lesson is hard: any organization running Agentic Workflows with cross-repository read access should treat that configuration as a known vulnerability. The fix isn't a patch from GitHub—it's a redesign of how you grant permissions to automated systems. If your workflows don't need to see private repos, they shouldn't have access. If they do need access, assume they will leak data and plan accordingly.


    — HackWire Editorial


    ---


    ## Related Coverage


  • Read more in our [Security Vulnerabilities](https://www.hackwire.news/category/vulnerabilities) coverage
  • Cross-reference with [AI Security](https://www.hackwire.news/category/ai-security) and [Cloud Infrastructure](https://www.hackwire.news/category/cloud-security)
  • Stay current via the [HackWire homepage](https://www.hackwire.news/)