Prompt injection became release abuse through CI cache poisoning

At a glance

What this is: This is an analysis of how prompt injection in a GitHub issue escalated into shell execution, cache poisoning, and an unauthorized npm publish.

Why it matters: It matters because IAM and DevSecOps teams need to treat AI-driven workflow steps as execution boundaries, not just content filters, when release pipelines are in scope.

Context

The core problem is not prompt injection alone, but an execution boundary failure: attacker-controlled text reached a workflow step that could turn instructions into shell commands inside CI. In identity terms, the issue is whether a non-human workflow actor is allowed to move from reading untrusted input to making real system changes.

GitHub Actions cache reuse across workflows creates a trust bridge when a low-trust job can influence artifacts or state that a later privileged job restores. That makes the release path vulnerable even when the first workflow does not hold the final secret.

The article shows a familiar pattern for machine identities and AI-assisted automation: the agent or workflow is not the threat by itself, but the authority it inherits from the pipeline around it. When that authority is too broad, attacker input can ride it into release operations.

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. If the job can reach a shell, package manager, or arbitrary network destination, it has already crossed the boundary that prompt filtering cannot protect. Make the first step read-only, then add explicit approval or a separate privileged job for any state-changing action.

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. If an untrusted job can write state that a publish or deployment job restores, the pipeline has created an implicit privilege bridge. That bridge can carry poisoned files, altered manifests, or malicious instructions across trust levels.

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. Automation should not inherit broad publish rights by default, and build identities should not be able to use the same secrets that authorise package release. That separation limits how far a single compromise can travel.

Q: What happens when workflow permissions are broader than the task actually needs?

A: The workflow inherits ambient authority, which lets a small compromise become a pipeline compromise. A triage job that can write to release-adjacent paths, reach package tooling, or use publish credentials can turn prompt injection into code execution and then into supply-chain impact. Least privilege only works if it is enforced at job scope.

Technical breakdown

How untrusted issue text became shell execution

The first failure was not the model making a bad judgment, but the workflow allowing model output to become executable action. In CI, an agent that can call Bash or spawn child processes has crossed from interpretation into execution. Once attacker-controlled issue text can influence command construction, the agent is no longer just triaging content. It is participating in a code path that can change files, run installers, and shape later build state. That is the central mechanism behind prompt injection becoming operational compromise. See the Prompt Injection Guide.

Practical implication: restrict issue-driven agent steps to read-only actions unless the workflow can prove the input is trusted.

Why cache poisoning turned a low-trust job into a release problem

Shared CI cache state becomes dangerous when a lower-trust workflow can write artifacts that a more privileged workflow later restores. The cache is effectively a cross-workflow memory channel, so poisoned state can survive beyond the initial job and influence publish steps that never saw the attacker input. In this case, the bridge mattered more than the prompt because it carried the attacker’s influence from triage into release. The architectural flaw is not merely persistence, but trust transfer without clear boundary enforcement.

Practical implication: isolate caches and artifacts by trust level so untrusted jobs cannot affect release workflows.

Why unauthorized npm release is a privilege boundary failure

An npm publish job is a privileged identity action, not just another build step. When publish credentials or token-derived authority are available in a workflow that has already been influenced by untrusted input, the pipeline has collapsed two different trust domains into one execution path. The article’s modified package.json and postinstall behavior show how release-time authority can be turned into downstream code execution for consumers as well. This is why package publishing must be treated as a privileged operation with narrow issuance, not a routine CI convenience. See the Privileged Access Management Guide.

Practical implication: separate publish authority from triage and build authority, and scope release credentials to the smallest possible workflow.

Threat narrative

Attacker objective: The attacker’s objective was to move from issue text to code execution and then into a malicious package release that could reach downstream users.

1. Entry began when an attacker placed untrusted text into a GitHub issue that a workflow could process.
2. Credential or execution access followed when the AI triage workflow turned that input into shell execution inside CI.
3. Escalation occurred as the runner poisoned shared cache state that a later privileged publish job restored.
4. Impact followed when the publish job completed an unauthorized npm release with a modified package manifest.

Breaches seen in the wild

• Gemini CLI prompt injection flaw 2025: Tracebit showed a poisoned README could make Gemini CLI run hidden commands and exfiltrate developer secrets; Google fixed it in 0.1.14.
• TrapDoor supply chain campaign 2026: TrapDoor's 34+ malicious npm, PyPI and Crates.io packages stole developer credentials and hid instructions for AI coding assistants. No victims known.

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

Runtime authority, not prompt quality, is the real control plane: This incident shows that the security question is not whether the model understood the issue correctly, but whether the workflow let untrusted text become real process, file, and network activity. Once that happens, prompt injection is no longer just an LLM problem. It becomes a release governance problem because the AI step inherits the authority of the CI job around it. Practitioners should treat the execution envelope as the control boundary, not the prompt itself.

Shared cache state creates identity leakage across workflows: GitHub Actions cache reuse let a lower-trust workflow influence a later privileged one, which means the trust boundary was drawn too broadly. That is a governance failure in privileged access management terms because the job that wrote state and the job that consumed it did not share the same trust profile. The implication is that workflow identity must be segmented by trust domain, not just by repository.

Agentic workflows inherit the privileges of the surrounding pipeline unless those privileges are explicitly stripped: The issue-triage step did not need full publish authority, but the surrounding environment made that authority reachable. That is the exact pattern that turns automation into compromise: the system confers ambient authority and then assumes the model will not abuse it. The practical conclusion is that AI agents in CI must be governed as non-human identities with sharply bounded delegated access.

Execution-layer security is the missing concept here: The article is really about the point where machine-generated instructions cross into system execution. That boundary deserves its own governance model because input filtering alone cannot stop a workflow that can spawn shells, mutate cache state, and inherit release tokens. Teams that only harden prompts will still miss the path from model output to supply-chain impact.

Read next: Prompt Injection Guide

What this signals

Execution-layer security: Prompt injection becomes materially more dangerous when the affected workflow can spawn shells, write files, or influence later publish jobs. The control point moves from prompt content to runtime authority, which means teams need boundaries around what an agent can execute, mutate, and export from the first place.

CI/CD programmes should expect AI-assisted triage and build steps to behave like non-human identities with delegated authority. That pushes governance toward task-scoped execution, cache isolation, and explicit release segregation rather than broad pipeline trust. The practical question is not whether the agent is clever enough, but whether the environment is narrow enough to contain it.

Release pipelines are now part of the identity problem. If untrusted input can reach a workflow with publish-adjacent privileges, the organisation has created a governance gap between content processing and code release. Teams should watch for any automation path where review, build, and publish share state or credentials.

For practitioners

• Constrain agent steps to read-only behavior Allow AI triage jobs to inspect issues and write only narrow, non-executable artifacts. Deny shell spawning, package installation, and arbitrary subprocess execution in the agent context.
• Split cache domains by trust level Prevent low-trust workflows from writing cache or artifact state that privileged workflows later restore. Treat shared cache as a cross-boundary control surface, not a convenience feature.
• Remove publish credentials from non-publish jobs Keep npm tokens and similar release secrets out of issue-driven and build-only workflows. Issue authority only inside the dedicated publish step that actually needs it.
• Review workflow permissions by task, not by repository Map each GitHub Actions job to the minimum file, network, and token access required for that task. Default the triage path to deny for anything that can influence release state.

Key takeaways

• The incident shows how prompt injection becomes a supply-chain issue when an AI workflow can turn untrusted input into executable CI actions.
• Shared cache state and overbroad workflow authority allowed a low-trust job to influence a later privileged publish step.
• The control that matters most is execution-boundary enforcement, because prompt filtering alone does not stop process, file, or release abuse.

Related NHI Mgmt Group resources: Prompt Injection Guide · Agentic AI Security Guide · AI Agent Authorisation Guide · Privileged Access Management Guide

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.
• Execution boundary: The point at which an authorised task turns into a real system change, such as writing data, deleting records, spending money, or invoking a downstream tool. In AI governance, controlling the execution boundary matters more than simply approving access, because harm occurs when actions are allowed to complete unchecked.
• Cache Poisoning: Cache Poisoning is an attack that inserts malicious or incorrect data into a cache so later users receive the wrong content. In identity and web systems, attackers target DNS, web, and application caches to redirect traffic, bypass controls, or serve crafted responses, so defenders must validate cache keys and inputs.
• Ambient authority: Access that exists because the surrounding environment already has permissions, rather than because the actor was explicitly granted them. In swarm systems, ambient authority hides who is truly acting and makes revocation, attribution, and containment much harder.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.