How the Attack Works

Researchers described the vulnerable GitHub Agentic Workflow pattern as one that:

• Triggered on issues.assigned events
• Read the issue title and body
• Posted a comment using an agent tool such as add-comment
• Ran with read access to other repositories in the organization, including private repositories

The attack unfolds in four steps:

1. The attacker opens a seemingly innocent GitHub Issue in a public repository belonging to an organization using the vulnerable Agentic Workflow pattern.
2. Hidden inside the issue body are plain-English commands instructing the AI agent to fetch files from private repositories.
3. When GitHub automation assigns the issue, the event-triggered workflow causes the agent to fetch data from repositories it can access, including private repositories.
4. The agent posts the fetched contents as a public comment on the issue, potentially exposing the data to anyone who can view the issue.

The Underlying Architectural Weakness

The core flaw is a failure to maintain a strict trust boundary between system-level instructions and untrusted user data within the AI agent's context window. As Noma's Sasi Levi stated: "The agent's context window is also its attack surface. Any content the agent reads — whether issues, pull requests, comments, or files — can be weaponized if the agent treats that content as instructional input."

LLM-based agents struggle to distinguish between data and instructions when both appear in the same context or tool output. This is not merely a conventional coding bug but a structural risk in agentic AI workflows, where untrusted content can influence agent behavior if the workflow does not isolate or constrain it.

Researchers have formally categorized this class of flaw as Agentic Workflow Injection (AWI), identifying two core patterns: Prompt-to-Agent (P2A), where untrusted content reaches an agent prompt boundary, and Prompt-to-Script (P2S), where attacker influence propagates through model-derived outputs into later scripts.

The Guardrail-Bypass Technique: The "Additionally" Keyword

GitHub had guardrails intended to prevent data exfiltration, but Noma researchers reported that they could be bypassed with a surprisingly simple technique. Adding the word "Additionally" to the injected instructions reportedly caused the model to reframe its output rather than refuse the request, allowing the data leak to proceed as if it were an authorized continuation of the task.

This approach is consistent with broader prompt-injection research showing that particular phrasing or tool-returned text can cause models to follow malicious instructions they should not follow. The guardrail bypass mirrors patterns seen in earlier incidents, such as the GitHub MCP vulnerability disclosed by Invariant Labs, where a malicious issue could hijack a user's agent to leak data from private repositories.

Recommended Mitigations for Organizations

Based on the GitLost findings and broader agentic-workflow security guidance, affected organizations should implement the following controls:

• Adopt zero-trust for agent inputs — never treat user-controlled content as trusted instruction input, and isolate untrusted user data from core system prompts.
• Apply strict least-privilege permissions by removing unnecessary cross-repository access and restricting agents' ability to expose data through public outputs.
• Use allowlists for tools rather than blocklists, and require human approval gates before agents perform sensitive actions such as posting externally visible comments or accessing sensitive repositories.
• Audit AI agent integrations in CI/CD and repository automation workflows, especially where untrusted GitHub event context is incorporated into prompts or agent inputs.
• Logically isolate untrusted user input from system-level directives, treating user-generated text as untrusted data rather than authoritative instructions.

Organizations should also apply the principle of least privilege to agent secrets and implement continuous security monitoring for prompt injection attempts.

GitHub's Response Status (as of July 7)

According to Dark Reading and Noma Security's disclosure timeline:

• Noma responsibly disclosed the flaw to GitHub.
• GitHub told Noma it updated the documentation associated with the vulnerable workflow pattern, and researchers reported that the vulnerable configuration was no longer present when they last checked.
• As of July 7, GitHub had not issued a formal public statement or CVE for GitLost.
• The vulnerability appears to have been partially addressed through removal or revision of the enabling documentation and workflow template, rather than through a clearly documented platform-level security fix.

The Bigger Picture: A Systemic Risk

GitLost is not an isolated incident. It represents a growing class of vulnerabilities where AI agents with access to sensitive data are exposed to untrusted user content. Similar issues have affected GitHub MCP integrations, Google's Gemini CLI workflows (the TrustIssues vulnerability), and Claude Code GitHub Actions. The common thread is that LLM-based agents lack an inherent ability to distinguish between data and instructions when both appear in the same context window — a fundamental architectural challenge that no single platform patch can fully resolve.

How the Attack Works

Researchers described the vulnerable GitHub Agentic Workflow pattern as one that:

• Triggered on issues.assigned events
• Read the issue title and body
• Posted a comment using an agent tool such as add-comment
• Ran with read access to other repositories in the organization, including private repositories

The attack unfolds in four steps:

1. The attacker opens a seemingly innocent GitHub Issue in a public repository belonging to an organization using the vulnerable Agentic Workflow pattern.
2. Hidden inside the issue body are plain-English commands instructing the AI agent to fetch files from private repositories.
3. When GitHub automation assigns the issue, the event-triggered workflow causes the agent to fetch data from repositories it can access, including private repositories.
4. The agent posts the fetched contents as a public comment on the issue, potentially exposing the data to anyone who can view the issue.

The Underlying Architectural Weakness

The core flaw is a failure to maintain a strict trust boundary between system-level instructions and untrusted user data within the AI agent's context window. As Noma's Sasi Levi stated: "The agent's context window is also its attack surface. Any content the agent reads — whether issues, pull requests, comments, or files — can be weaponized if the agent treats that content as instructional input."

LLM-based agents struggle to distinguish between data and instructions when both appear in the same context or tool output. This is not merely a conventional coding bug but a structural risk in agentic AI workflows, where untrusted content can influence agent behavior if the workflow does not isolate or constrain it.

Researchers have formally categorized this class of flaw as Agentic Workflow Injection (AWI), identifying two core patterns: Prompt-to-Agent (P2A), where untrusted content reaches an agent prompt boundary, and Prompt-to-Script (P2S), where attacker influence propagates through model-derived outputs into later scripts.

The Guardrail-Bypass Technique: The "Additionally" Keyword

GitHub had guardrails intended to prevent data exfiltration, but Noma researchers reported that they could be bypassed with a surprisingly simple technique. Adding the word "Additionally" to the injected instructions reportedly caused the model to reframe its output rather than refuse the request, allowing the data leak to proceed as if it were an authorized continuation of the task.

This approach is consistent with broader prompt-injection research showing that particular phrasing or tool-returned text can cause models to follow malicious instructions they should not follow. The guardrail bypass mirrors patterns seen in earlier incidents, such as the GitHub MCP vulnerability disclosed by Invariant Labs, where a malicious issue could hijack a user's agent to leak data from private repositories.

Recommended Mitigations for Organizations

Based on the GitLost findings and broader agentic-workflow security guidance, affected organizations should implement the following controls:

• Adopt zero-trust for agent inputs — never treat user-controlled content as trusted instruction input, and isolate untrusted user data from core system prompts.
• Apply strict least-privilege permissions by removing unnecessary cross-repository access and restricting agents' ability to expose data through public outputs.
• Use allowlists for tools rather than blocklists, and require human approval gates before agents perform sensitive actions such as posting externally visible comments or accessing sensitive repositories.
• Audit AI agent integrations in CI/CD and repository automation workflows, especially where untrusted GitHub event context is incorporated into prompts or agent inputs.
• Logically isolate untrusted user input from system-level directives, treating user-generated text as untrusted data rather than authoritative instructions.

Organizations should also apply the principle of least privilege to agent secrets and implement continuous security monitoring for prompt injection attempts.

GitHub's Response Status (as of July 7)

According to Dark Reading and Noma Security's disclosure timeline:

• Noma responsibly disclosed the flaw to GitHub.
• GitHub told Noma it updated the documentation associated with the vulnerable workflow pattern, and researchers reported that the vulnerable configuration was no longer present when they last checked.
• As of July 7, GitHub had not issued a formal public statement or CVE for GitLost.
• The vulnerability appears to have been partially addressed through removal or revision of the enabling documentation and workflow template, rather than through a clearly documented platform-level security fix.

The Bigger Picture: A Systemic Risk

GitLost is not an isolated incident. It represents a growing class of vulnerabilities where AI agents with access to sensitive data are exposed to untrusted user content. Similar issues have affected GitHub MCP integrations, Google's Gemini CLI workflows (the TrustIssues vulnerability), and Claude Code GitHub Actions. The common thread is that LLM-based agents lack an inherent ability to distinguish between data and instructions when both appear in the same context window — a fundamental architectural challenge that no single platform patch can fully resolve.