Prompt injection in CI: how did issue text reach release jobs?

TL;DR: Attacker-controlled GitHub issue text became shell execution in CI, poisoned shared cache state, and later enabled an unauthorized npm release through a privileged publish job, according to Canyon Road research. The incident is a release-path failure, not just a prompt-injection story, because runtime authority and workflow trust boundaries were too broad.

Editorial analysis by NHI Mgmt Group, based on content published by Canyon Road: “Untrusted Text, Trusted Shell”.

Key questions

Q: What should security teams do first when an AI workflow can turn untrusted text into shell commands?

A: Start by removing execution authority from the workflow step that reads untrusted content.

Q: Why do CI cache and artifact boundaries matter when AI agents run in pipelines?

A: Because cache and artifact reuse can transfer trust from a low-privilege workflow into a later privileged one.

Q: How should teams separate release authority from CI/CD automation?

A: Treat release authority as privileged access and keep it distinct from build execution and secret retrieval.

Practitioner guidance

• Constrain agent steps to read-only behavior Allow AI triage jobs to inspect issues and write only narrow, non-executable artifacts.
• Split cache domains by trust level Prevent low-trust workflows from writing cache or artifact state that privileged workflows later restore.
• Remove publish credentials from non-publish jobs Keep npm tokens and similar release secrets out of issue-driven and build-only workflows.

Bottom line: The incident shows how prompt injection becomes a supply-chain issue when an AI workflow can turn untrusted input into executable CI actions.

Explore further

View Full Forum →  |  NHI Foundation Course →  |  Our Services →  |  Read the full analysis →