TL;DR: A critical prompt injection flaw in Google’s AI-powered GitHub workflow let an external attacker exfiltrate workflow secrets, pivot through repository tokens, and reach full supply-chain compromise across gemini-cli and at least eight other Google repositories, according to Pillar Security. The breach shows that prompt hardening alone does not contain agentic CI/CD risk.
At a glance
What this is: This is a breach analysis of a prompt-injection path in Google’s Gemini-powered GitHub workflow that enabled secret exfiltration and supply-chain compromise across gemini-cli and other repositories.
Why it matters: It matters because CI/CD workflows that let AI agents read untrusted content, access private data, and communicate externally can turn a single issue comment into repository-wide compromise.
By the numbers:
- Pillar Security identified a CVSS 10 critical vulnerability in Google’s AI powered GitHub workflows.
Context
Prompt injection becomes a governance problem when an AI agent can read attacker-controlled text and act on it with workflow permissions. In CI/CD, that means the trust boundary is not the model prompt alone, but the whole execution path around it, including runners, checkout steps, tokens, and downstream dispatch rights.
This case is a classic agentic CI/CD failure because the agent had access to private data, exposure to untrusted content, and the ability to communicate externally. Once those three conditions align, prompt hardening does not stop exfiltration, because the privilege surface is already inside the pipeline.
For identity practitioners, the important point is that this is not just an application-security flaw. It is a non-human identity governance failure in which a workflow identity, its secrets, and its delegated write paths were not isolated from attacker-influenced input.
Key questions
Q: What breaks when an AI triage agent can read public issues and reach repository secrets?
A: The trust boundary breaks immediately. Public text becomes attacker-controlled input, and the agent can be steered into reading files, exposing tokens, or calling tools that were never meant to process hostile content. Once the agent can both ingest untrusted data and communicate externally, prompt injection becomes a workable exfiltration path rather than a theoretical risk.
Q: Why does CI/CD prompt injection create a supply-chain risk instead of a local workflow issue?
A: Because the compromise rarely ends at the first secret. Once an attacker gets a token that can dispatch other jobs or write to the repository, the initial leak becomes a path to code tampering and downstream distribution. The impact is supply-chain wide when the workflow identity can influence shipping code.
Q: What are the signs that a non-human identity in CI/CD is too permissive?
A: Look for agents that can read filesystem state, trigger other workflows, or access both private data and external destinations in the same job. If a workflow can escalate from issue triage to token reuse, it has already crossed a privilege boundary that should have been isolated. Those are the signs of unsafe blast radius.
Q: How should organisations govern AI coding agents in GitHub Actions?
A: Give them the minimum repository and secret access needed, add runtime monitoring for network and process activity, and tightly control external dependencies they can fetch during execution. The right model is layered control: authentication, task scope, egress limits, and evidence of behaviour after the job begins.
Technical breakdown
How prompt injection took control of the triage agent
The workflow used a Gemini-powered agent to read and label public GitHub issues automatically. Because the issue body flowed directly into the agent’s prompt, hidden instructions in attacker-controlled text could redirect the model’s behaviour without needing a traditional code exploit. The critical detail is that the agent also ran with tool access and no human confirmation gate, so the injected instructions were not just interpreted, they were executed. In this pattern, the prompt becomes an input channel into an operational identity, not merely a text-generation context.
Practical implication: treat any AI agent that reads untrusted repository content as a privilege-bearing workflow identity, not a passive parser.
Why secrets persisted beyond the environment variable boundary
The article shows why removing a token from the agent’s environment is not enough. The workflow still used actions/checkout with credential persistence enabled, which wrote Git credentials to disk in .git/config. That file sat on the runner filesystem where the agent could read it through shell access. This is a governance failure at the boundary between ephemeral execution and durable credential storage. The problem is not that the secret existed, but that the workflow left a second reachable copy in a location the agent could still access.
Practical implication: disable credential persistence in checkout steps and assume filesystem-resident tokens are reachable by any agent with local read access.
How the write token turned disclosure into repository compromise
After exfiltration, the attacker did not need the original secret for long. The stolen token had actions:write permissions, which allowed workflow dispatch into another job that checked out attacker-controlled content. That created a second-stage escalation path in which one workflow’s privilege was used to mint or recover a different token with contents:write on the target repository. The mechanism is important because it shows how CI/CD privilege is often chained across jobs, not held in one place. Once an agent can trigger another workflow, blast radius expands beyond the initial triage job.
Practical implication: map cross-workflow dispatch rights and token scope transitions as a single privilege chain, not as isolated jobs.
Threat narrative
Attacker objective: The attacker’s objective was to gain durable write access to the repository and use it to alter code shipped to downstream users.
- Entry occurred when an external attacker opened a public GitHub issue containing hidden prompt-injection instructions for the Gemini-powered triage workflow.
- Credential access followed when the agent executed attacker-directed reads against workflow state and filesystem-resident credentials, exposing secrets from the runner environment and .git/config.
- Escalation occurred when the attacker reused the stolen token to trigger a second workflow and obtain a stronger repository credential with write capability.
- Impact was full supply-chain compromise, because the attacker could push arbitrary code to main and affect downstream users of gemini-cli.
Breaches seen in the wild
- Shai Hulud npm malware campaign: Shai Hulud campaign: npm malware exposed secrets on GitHub.
- reviewdog Action compromise 2025: A stolen maintainer token poisoned reviewdog/action-setup, leaking CI secrets including the tj-actions bot token used in the next attack.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Prompt injection in agentic CI/CD is a privilege problem before it is a prompt problem. The article shows that the decisive failure was not model quality, but the fact that the agent could act on attacker-controlled text while holding real workflow permissions. Once the agent can read, execute, and communicate, prompt hardening alone is not a security boundary. Practitioners should treat untrusted-input triggers as identity events with blast-radius implications.
Lethal trifecta is the right named concept for this control collapse. Access to private data, exposure to untrusted content, and external communication formed a complete exfiltration path in the workflow. That combination invalidates the assumption that CI/CD agents can safely process public issues if secrets are hidden in the environment. The implication is architectural: the workflow must be redesigned so the three conditions do not coexist.
Git credential persistence created a standing secret trail that survived environment sanitization. The article makes clear that removing tokens from the agent process did not remove them from disk, which left the runner’s local state as an alternate credential source. This is a non-human identity lifecycle failure, because the secret outlived the intended trust boundary. Practitioners should rethink where machine credentials exist, not just where they are injected.
Workflow dispatch turned a single compromise into a cross-job privilege chain. The attack did not stop at disclosure because the stolen token could activate a second workflow with broader permissions and a different trust boundary. That is a governance pattern, not a one-off exploit path: repository automation often grants the next credential in a separate step. The practitioner conclusion is to model CI/CD identity as a chain of delegated authorities, not a single token.
System prompts are not a reliable control plane for non-human identity abuse. The proof-of-concept demonstrates that prompt refusals do not matter when the attacker can steer the execution environment instead of asking for secrets directly. That means policy text and model behaviour are insufficient unless the surrounding workflow constrains tool use, file access, and downstream token reuse. Teams should move from prompt trust to execution trust.
From our research library:
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
- 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
- Read next: Agentic AI Security Guide
What this signals
Lethal trifecta control gap: CI/CD agent governance must now assume that private data, untrusted content, and outbound connectivity can combine into a single exfiltration path. The practical response is to separate those three conditions wherever an AI agent can be triggered by external users, because prompt filtering does not break the underlying privilege chain.
Agentic CI/CD needs credential locality controls: secrets that are absent from the process environment can still exist on disk, in checkout state, or in downstream dispatch tokens. That means machine identity governance has to include filesystem reachability, not just secret injection points.
The compromise pattern maps cleanly to NHI governance, especially where workflow identities can mint or reuse higher-privilege tokens across jobs. Teams that already manage service accounts and workload identities should extend the same discipline to repository automation, because the attack path is an identity chain, not a model defect.
For practitioners
- Map every untrusted-input trigger Inventory issue, pull request, comment, and scheduled workflows that can activate an AI agent, then identify which of those runs can reach private data and external network calls.
- Disable credential persistence in checkout Set persist-credentials: false wherever a workflow processes untrusted content so repository credentials are not written into .git/config on the runner.
- Remove the lethal trifecta Break the combination of private data access, untrusted content exposure, and external communication in the same workflow; if all three remain, assume exfiltration is possible.
- Constrain tool allowlists and local file reads Audit agent tool permissions so reading filesystem state, shell execution, and outbound network access are not simultaneously available in triage or reviewer jobs.
- Model cross-workflow privilege escalation Trace how actions:write, contents:write, and OIDC minting can chain across jobs, then remove any dispatch path that lets a stolen token request a stronger one.
Key takeaways
- A public issue was enough to steer an AI triage agent into leaking workflow secrets and starting a supply-chain compromise.
- The compromise mattered because workflow permissions, persisted Git credentials, and cross-job token reuse created a path from disclosure to repository write access.
- The control gap was not prompt quality alone. It was the combination of untrusted input, reachable credentials, and downstream privilege escalation in the same CI/CD identity chain.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10, OWASP Non-Human Identity Top 10 and MITRE ATT&CK define the specific risk controls and attack patterns relevant to this term.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI02 — Tool Misuse | The agent was induced to use approved tools for attacker-directed actions. |
| ASI03 — Identity & Privilege Abuse | The attack abused workflow identity and repository permissions across chained jobs. | |
| Recommendation — Constrain agent tool use so external prompts cannot redirect tool execution into exfiltration paths. Bind agent privileges to the minimum workflow scope and block privilege reuse across jobs. | ||
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The core impact was leakage of workflow secrets from runner memory and disk. |
| NHI-05 — Overprivileged NHI | The triage workflow held permissions broad enough to pivot from issue handling to repository compromise. | |
| Recommendation — Scan runner state for exposed secrets and remove any local storage path that keeps credentials reachable. Reduce workflow permissions to the narrowest scope that still supports the automation task. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The attack moved from secret theft to cross-workflow token reuse and repository pivoting. |
| Recommendation — Map CI/CD compromise paths to credential access and lateral movement to detect chained escalation. | ||
Key terms
- Prompt Injection (Agentic): An attack where malicious instructions are embedded in content that an AI agent reads, causing the agent to execute unintended actions using its own legitimate credentials. A primary vector for agent goal hijacking and identity abuse.
- Agentic CI/CD: A delivery pipeline that embeds AI agents directly into build or deployment workflows. The agent can interpret text, select tools, and act inside the runner, which makes runtime authority part of the security model rather than just the workflow definition.
- Workflow Identity: A workflow identity is the non-human identity represented by an automated CI/CD process when it authenticates, accesses secrets, or performs actions in other systems. In practice, it is the authority carried by the pipeline itself, and it must be governed with explicit scope, review, and revocation.
- Credential Persistence: Credential persistence is the ability of an attacker to keep access after the original secret is revoked or the initial malware is removed. In identity terms, it usually means a second credential, key, or token has been added to the account lifecycle and now survives the first response action.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 12, 2026.
Updated on October 10, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org