Agentic Trust Issues: From Prompt Injection to Full Supply‑Chain Compromise in Google’s gemini‑cli

Thesis

The discovery of a CVSS 10 vulnerability—dubbed TrustIssues—in Google’s AI‑powered GitHub workflows demonstrates that the convergence of three conditions—access to private data, exposure to untrusted content, and the ability to communicate externally—creates a deterministic path to supply‑chain compromise. The gemini‑cli repository, with over 100 000 stars, became the highest‑value target, showing that even well‑resourced cloud providers are vulnerable when AI agents are granted unchecked authority in CI/CD pipelines.

---

Key Arguments

1. The attack chain leveraged a prompt‑injection surface in an automated issue‑triage workflow.

• An attacker opened a public issue on a Google repository.
• Google’s Gemini‑powered agent automatically read the issue body, used it as part of its prompt, and executed tool calls in --yolo mode, which previously ignored fine‑grained allowlists.
• By embedding a malicious command in the issue text, the attacker forced the agent to read the runner’s environment (/proc/$PPID/environ) and write the contents back to the issue, exposing the workflow’s GEMINI_API_KEY and OIDC credentials.

2. Credential leakage was amplified by persistent Git credentials on disk.

• The actions/checkout step persisted the GITHUB_TOKEN in .git/config because persist-credentials: true is the default.
• The compromised agent could read this file, base64‑encode the token, and exfiltrate it to an attacker‑controlled server via a simple curl command.
• The token retained actions:write permissions for the duration of the workflow run, giving the attacker a five‑minute window to act.

3. Privilege escalation via workflow dispatch enabled full repository takeover.

• Using the stolen token, the attacker invoked a secondary workflow (smoke-test.yml) that allowed contents:write.
• By controlling the ref input, the attacker caused the secondary workflow to check out a malicious branch from a fork, where a modified package.json exfiltrated the new token.
• The new token granted write access to the gemini‑cli repository itself, allowing the attacker to push arbitrary code to main. The malicious commit propagated to every downstream user of the CLI.

4. The vulnerability was not isolated to gemini‑cli.

• Pillar’s automated scanner identified the same vulnerable workflow template in at least eight other Google repositories, indicating a systemic pattern rather than a single‑point mistake.
• The root cause was the combination of an AI‑driven triage step, unsanitized user input, and overly permissive workflow permissions.

---

Implications

• Supply‑chain risk is now quantifiable – The attack demonstrates a concrete, reproducible path from a public issue to code execution on millions of machines. Organizations that embed AI agents in CI/CD must treat prompt injection as a privilege‑escalation problem, not merely a text‑sanitization issue.
• Tool allowlisting must be enforced even in “yolo” modes – The --yolo flag previously bypassed all policy checks, effectively granting the agent unrestricted shell access. Google’s patch now forces allowlist evaluation regardless of --yolo, a necessary but insufficient safeguard.
• Credential persistence is a hidden attack surface – Default checkout behavior writes authentication tokens to disk, which can be read by any process with repository access. Disabling persist-credentials should become a baseline security setting for any workflow that processes untrusted data.
• Policy‑driven AI agents require a new threat model – Traditional CI/CD hardening (e.g., restricting GITHUB_TOKEN in the environment) does not protect against attacks that read credentials from the file system or from parent processes. Security policies must encompass the entire execution environment, including the runner’s process tree and mounted volumes.

---

Counter‑Perspectives

Some observers argue that the rapid patching timeline—Google released a fixed version of gemini‑cli (0.39.1) within two days—demonstrates that the ecosystem can respond quickly to AI‑related bugs. While the speed of remediation is commendable, it does not address the underlying design flaw: granting AI agents the same level of authority as human operators without explicit isolation. Even with patches, legacy workflows may remain deployed in private repositories, and the pattern of AI‑driven issue triage is likely to proliferate across the industry.

---

Recommendations

1. Enforce strict tool allowlists – Define a minimal set of permissible commands (e.g., gh issue edit only) and verify that the allowlist is honored even when agents run in “yolo” mode.
2. Disable credential persistence – Add persist-credentials: false to every actions/checkout step that precedes an AI‑driven stage.
3. Audit all AI triggers – Identify every workflow that can be invoked by external actors (issues, PR comments, scheduled runs) and ensure that the lethal trifecta is not present.
4. Separate secret storage from the runner – Use short‑lived OIDC tokens that are minted only when needed, and store them in secret management systems that are not mounted on the runner’s file system.
5. Model threat scenarios around escalation – Assume that any leaked token will be used to trigger higher‑privilege workflows; incorporate this assumption into your incident‑response playbooks.
6. Adopt dedicated agentic CI/CD scanners – Tools like Pillar’s Agentic CI/CD scanner can automatically detect vulnerable AI agents, surface over‑permissive permissions, and suggest concrete hardening steps.

---

The Path Forward

The gemini‑cli incident should be read as a cautionary tale rather than an outlier. As more organizations embed large language models into their development pipelines, the line between “automation” and “autonomous agent” blurs. Security teams must therefore evolve from protecting static code to defending dynamic, self‑modifying agents that can read, write, and communicate on behalf of the pipeline. Only by treating AI agents as first‑class security principals—subject to the same least‑privilege, audit, and isolation requirements as any other component—can the industry prevent the next supply‑chain hijack.

---

For a deeper dive into the technical details of the PoC and the full advisory, see Google’s GHSA‑wpqr‑6v78‑jr5g and the Pillar Security research blog.