Skip to main content

The trivy supply chain attack compromised LiteLLM, KICS and dozens of npm packages. Here’s what stops an agent from being the next vector.

On March 19, threat actors compromised Aqua Security’s trivy-action by force-pushing 76 of 77 version tags to malicious commits. The payload is a credential stealer targeting CI/CD secrets, cloud credentials, SSH keys and Kubernetes tokens. The initial foothold came from hackerbot-claw, an autonomous bot that exploited a pull_request_target misconfiguration in Trivy’s own GitHub Actions to steal a Personal Access Token in late February. Incomplete credential rotation after the first incident gave the attackers residual access.

The attack is still expanding. On March 23, TeamPCP compromised Checkmarx’s KICS GitHub Action using the same infrastructure. On March 24, the stolen credentials cascaded further: LiteLLM’s CI/CD pipeline ran Trivy as part of its build process, the compromised action exfiltrated the PyPI publish token, and TeamPCP used it to push credential-stealing versions of litellm (1.82.7 and 1.82.8) directly to PyPI. LiteLLM is downloaded roughly 3.4 million times per day and is a transitive dependency for a growing number of AI agent frameworks and MCP servers. The malicious version was discovered when a Cursor MCP plugin pulled it in automatically.

The campaign has also spread to npm via a self-propagating worm (CanisterWorm) and malicious Docker Hub images. Wiz, CrowdStrike, Socket, Snyk and Aqua have all published research. This is the largest CI/CD supply chain attack in recent memory and it is accelerating.

The immediate remediation advice is consistent across every advisory: pin GitHub Actions to immutable commit SHAs, not version tags. Rotate any secrets that ran through an affected pipeline. Audit your workflows.

That last step is the one worth examining. Because in a growing number of CI pipelines, the thing doing the work is not a shell script. It is an AI agent.

Why workflow files are the critical control point

The trivy attack worked because the compromised action ran inside CI pipelines with broad permissions. In the LiteLLM case, that access was enough to exfiltrate the PyPI publish token. But the attack surface extends beyond stolen tokens.

A compromised action or a well-crafted issue can instruct an AI agent to modify workflow files directly: swap an action reference to a malicious fork, add a step that exfiltrates secrets, or escalate the permissions block. If the agent has write access to .github/workflows/ and no policy boundary, it will comply. The change persists in the repository and runs on every subsequent trigger.

This is the vector Vectimus closes.

vectimus-fileint-001: Block writes to GitHub Actions workflow files.

Any agent governed by Vectimus cannot modify files under .github/workflows/. The policy evaluates before the write executes. The deny is deterministic, not probabilistic. A signed receipt proves the evaluation happened.

We tested this against our own Sentinel pipeline. When a Claude Code agent attempted to write corrected workflow files, Vectimus blocked it immediately. Receipt vtms-bf2e10e9. No file modified.

When the agent tried writing vectimus init commands into a script file:

vectimus-destruct-006: Block agents from running vectimus CLI commands.

Content inspection caught the string. Receipt vtms-4e6d6a6c. Blocked.

When the agent attempted to modify governance configuration files:

vectimus-fileint-004: Block writes to governance config files.

Three rules, three blocks, three receipts. The governance layer cannot be modified by the agents it governs. If an attacker compromises an upstream dependency and uses it to instruct the agent to rewrite its own workflow files, the write never lands. The agent cannot be the vector.

The fixes were applied manually by a human developer outside the agent’s execution context. That is where workflow changes belong.

Why this matters for CI pipelines running AI agents

The trivy attack worked because mutable version tags are a trust mechanism with no integrity guarantee. A tag like @v1 is a pointer the maintainer can move at any time. A compromised account or a forced tag update replaces the action code for every downstream consumer silently. The malicious trivy-action commits looked identical to the originals in Git history.

AI agents in CI make this exposure worse. An agent processing untrusted input from issue bodies, PR descriptions and comments while holding write tokens is functionally equivalent to a shell with no access controls reading attacker-supplied instructions. The attack does not need to compromise a dependency or a maintainer account. It needs a well-crafted issue.

The kubernetes-el attack demonstrated this independently. A threat actor exploited pull_request_target with untrusted input and write tokens to push malicious code to a repository’s default branch. The pattern is reliable and repeatable. hackerbot-claw automates it at scale.

Without a policy layer evaluating every tool call before execution, the only control is the developer’s judgment at configuration time. That is a one-time decision protecting against a continuous threat surface.

What we found in our own pipeline

When we audited our Sentinel pipeline in response to the Wiz disclosure, we found the same patterns the advisories describe. We were running aquasecurity/trivy-action@master, unpinned and exposed for the duration of the compromise window. Two other actions used mutable version tags. Several workflows inherited broad default token permissions instead of declaring explicit minimal permissions: blocks. A committed config file leaked a local filesystem path.

None of this was unusual. These are the defaults teams end up with when CI pipelines grow organically. The point is that a manual audit triggered by an external disclosure is a reactive control. A policy layer evaluating every tool call is a continuous one.

Setting it up

Vectimus 0.19.1 ships vectimus init --ci, which installs governance hooks in CI pipelines. Claude Code agents running in GitHub Actions are governed by the same Cedar policies as local development.

pip install vectimus>=0.19.1
vectimus init --ci

This configures the PreToolUse hook in the CI environment, loads your project’s Cedar policy set and ensures every tool call the agent makes is evaluated against your policies before execution. Deny decisions produce signed receipts that persist as workflow artifacts.

The key policies for CI pipeline security:

  • vectimus-fileint-001 blocks agents from modifying workflow files. Changes to .github/workflows/ require human review.
  • vectimus-fileint-004 blocks agents from modifying governance config. Policy changes go through pull requests, not agent edits.
  • vectimus-destruct-006 blocks agents from running governance CLI commands. An agent cannot disable or reconfigure the system governing it.

Sources