The report
A Gemini CLI pull request describes a chained_e2e test workflow in which a workflow_run job can receive a GEMINI_API_KEY and may also check out or install code controlled by a fork contributor. The workflow trigger itself is trusted to run with repository privileges, but the code it subsequently checks out has a different origin. That separation is the central concern in the source discussion.
The mechanism does not require a model to decide to steal anything. A CI step that executes untrusted repository scripts in an environment containing a provider key creates an opportunity for ordinary shell or package lifecycle code to reach the secret. The affected product is an AI coding tool, but the trust error is a GitHub Actions privilege transition. The technical Case limits the claim to the described workflow and review state.
A privileged trigger is not a trusted checkout
A workflow_run job can be intentionally privileged, for example to upload results from another workflow. That does not change the provenance of the pull request's bytes. A safe design keeps secrets in a phase that never runs fork-controlled commands, or consumes only strictly bounded artifacts whose provenance has been checked. Merely checking which event started the job is insufficient.
The cited pull request is evidence of an identified risk and proposed correction. It is not evidence that a real key was exfiltrated, that every Gemini CLI workflow is affected, or that an upstream release already contains the final fix.