Analysis · DiggingBeagle record
A prompt is not a release, and a signed release is not necessarily safe
Reconstructing where untrusted instructions, executable Git configuration, CI caches and legitimate provenance enter separate attack paths.
- Published
- Nov 13, 2026
Overview
A repository can cross into execution through an ordinary Git option, an instruction read by a coding agent, or a workflow that later publishes a package. These routes share a carrier, but they do not share the same interpreter, prerequisites or evidence of harm. Conflating them makes both incident counts and proposed mitigations unreliable.
Four routes from lower-trust material to privileged execution
| Entry and case | Where authority changed | What the record establishes | What it does not establish |
|---|---|---|---|
| Repository-local Git configuration | A read-only MCP status or diff tool invoked executable Git helpers | The affected implementation executed repository-supplied helper programs; an independent test reported seven working sinks on the older build and none of those seven on the patched build | An ordinary fresh clone importing an attacker's .git/config, or a confirmed external victim |
| Public issue text shown to a Codex labeler | Agent tool execution exposed runner process memory, then a less-trusted Actions cache was consumed by a more privileged workflow | Researchers described a controlled chain reaching the release pipeline despite environment-variable scrubbing | A malicious public npm package being distributed to users |
| Miasma-family repository modifications | Forged agent instructions, session-start hooks and package lifecycle scripts offered distinct paths to code execution | Investigators identified poisoned third-party repositories and executable setup material | That every repository's agent obeyed the instructions, or every hook ran |
| wfx-loot workflow modifications | Compromised GitHub identities modified CI workflows and attempted to use runner credentials | Researchers counted malicious edits and a smaller, separately reported set of executed jobs | That every modified repository suffered credential exfiltration, or that an AI agent directed the worm |
The bee-js release compromise adds a distribution lesson. Legitimate publishing credentials and provenance can attest that an authorized pipeline produced an artifact even when that pipeline has been compromised. It is conventional supply-chain evidence, not proof of model-driven attack execution.
A correct-looking artifact is not an execution receipt
For the Miasma incident, a forged AGENTS.md-style instruction can influence the assistant, while a session-start or npm hook may run before the assistant makes any meaningful decision. Those are separate control planes. The presence of an instruction file alone cannot prove the assistant read it; the presence of a startup hook alone cannot prove it executed; and a successfully installed malicious dependency does not prove secrets were sent outside the host.
The same discipline applies to wfx-loot. Aikido and SafeDep used overlapping but different measurements of probing accounts, pull requests and changed repositories, while executed CI jobs and observed uploads form narrower populations. Their totals cannot be added or used interchangeably. A legitimate signature, a merged pull request or a green CI badge describes a stage of the workflow, not its authorized end-to-end behavior.
The defensible incident chain keeps six kinds of evidence distinct: original lower-trust content, the interpreter that read it, the resulting tool or process invocation, the effective principal at that moment, a committed file or network effect, and any subsequent publication or installation. When one receipt is absent, the correct conclusion is a bounded finding. It is not a license to fill in the rest of an attack from a plausible diagram. For related mechanism-level analysis, see agent plugin integrity and indirect prompt injection.