Your AI context is now a supply-chain attack surface

The keyv npm worm did something new on 4 August. Alongside the usual package route, it wrote hooks into .claude/settings.json and .vscode/tasks.json — so the payload ran the next time anyone opened the repository or started a Claude Code session, with no npm install required. That is the detail worth stopping on, because it means your agent configuration is now an execution path. Your context supply chain is every hop your team's AI instructions travel — from the person who wrote them to the agent that executes them — and most of those hops currently carry unsigned, executable config that nothing reviews and nothing scans.

This post is uncomfortable to write, because the practice under attack is the one our whole category recommends: put your team's standards in a shared repo and pull them into everyone's agent. That advice is still right. The distribution mechanism most teams use to follow it is not.

What actually happened on 4 August

The malicious release went out at 09:35 UTC on 2026-08-04. Within roughly thirty minutes it had reached 444 packages across 1,381 versions, with more than two billion combined monthly installs between them. The Hacker News reported the scale, and Aikido's write-up and Datadog Security Labs' analysis both walk the mechanics.

Two framing notes before the details, because they matter for how much weight to put on what follows. The compromise itself is confirmed and corroborated across multiple independent outlets. Attribution of the campaign to any particular actor is opinion, including the widely repeated framing that this is the sixth Shai-Hulud campaign since September 2025 — the pattern-matching is reasonable and the naming is not established fact. Hold those two apart.

The second execution path is the story

The npm route is well understood by now: a lifecycle script runs on install, the payload executes, credentials leave. Every team that has been through a dependency incident has a runbook for it. Lockfiles, --ignore-scripts, install-time scanning, provenance checks — the industry has spent three years building defences at that hop.

The second path has no equivalent defences, because until this month nobody was defending it.

Agent hooks are commands the agent runs at defined lifecycle points, including session start. This is a real feature and a useful one — teams use hooks to run a formatter before a commit, to inject a linting pass, to block edits to generated files. Because hooks live in a settings file, and settings files live in repositories, a repository can carry commands that execute when a developer starts working in it.

Reporting describes five hidden files placed under .claude and .vscode. The trigger is not an install. It is opening the repo, or starting a session. A developer who cloned the repository to read it — the safest thing you can do with untrusted code — was in scope.

Sit with the threat model for a second. Your dependency defences all assume the dangerous moment is installation. Here the dangerous moment is attention. The engineer doing the responsible thing, reviewing before installing, is the one who fires the payload.

What it took, and what it reached

The harvesting was thorough and aimed squarely at platform engineers. GitHub tokens. ~/.aws/credentials. AWS Secrets Manager and SSM Parameter Store. Kubernetes secrets, searched specifically for npm, GCP, Azure, Stripe, Slack and Twilio keys. Vault contents.

That target list tells you who the intended victim was. This was not built to harvest a hobbyist's session cookie. It was built to run on a machine that holds production credentials — which is to say, the machine of the engineer most likely to be evaluating a shared team-standards repository at their desk on a Tuesday.

And the reach is worse than the file list suggests, because a developer laptop is a credential aggregation point. The tokens sitting in your CLI profiles are not scoped to what you are doing right now. They are scoped to everything you are allowed to do.

There is a second-order problem worth naming, because it changes what containment means. Credentials lifted from a laptop are not merely access — they are access that looks legitimate. A token taken from a CLI profile produces API calls indistinguishable from that engineer's ordinary work, from an IP that has made those calls a thousand times before. Detection that keys on anomalous origin has nothing to key on. That is why the rotation step at the end of this post is not tidy-up hygiene. For this class of compromise, rotation is the containment, because nothing downstream is going to flag the misuse on your behalf.

A shared skills repo is a distribution channel

Here is the part that should change behaviour rather than just raise an eyebrow.

The campaign hit a shared team-skills repository while that repository was on the Hacker News front page. The pitch was exactly the thing our category tells people to build: "Agent skills that bring team coding standards to Claude Code and Codex." It reached 75 points and 38 comments. Two hours into the thread, a commenter warned in plain terms: "DO NOT INSTALL THIS VIA NPX OR OPEN THIS REPO IN VSCODE."

To be clear about the people involved: the maintainers were targeted, not careless. Anyone publishing useful tooling in a popular ecosystem is a target, and being on the front page is what made them one. There is no lesson here about their diligence.

The lesson is about the channel. The moment a team's coding standards ship as a repository you clone and load into an agent, the standards and the executable config travel together in the same artefact, through the same hop, with the same review — which is usually none. Nobody diffs a settings file. Nobody has an opinion about a hooks block. The reviewing instinct that fires on a dependency bump does not fire on a rules file, because rules files feel like documentation.

They are not documentation. They are, in the current distribution model, unsigned executable config from an arbitrary third party, auto-loaded at session start, scanned by nothing. Say that sentence out loud about any other part of your stack and you would have a ticket open before lunch.

Why this is a context problem, not just a security problem

It would be easy to file this under dependency hygiene and move on. That would miss what is structurally new.

We have written before about why per-developer context files fail as a team grows — the CLAUDE.md problem is the architectural version of that argument, and the comparison of AGENTS.md, CLAUDE.md and SKILL.md works through which layer should hold what. Both of those posts are about consistency and drift. Neither anticipated that the distribution mechanism for team context would become an execution primitive.

That is the shift. Team context used to be a correctness concern: is the standard current, does everyone have it, who owns it. It is now also a trust boundary. The question is no longer only "is this instruction right" but "what is allowed to arrive with this instruction, and who checked".

Two properties of the current model create the exposure, and both are fixable independently of any product:

Content and capability are fused. A standards update and a command registration ride in the same file, in the same commit, under the same review. There is no way to accept one and refuse the other, because the format does not distinguish them.

Load is implicit. Session-start execution means the act of beginning work is the act of accepting whatever the repository currently specifies. There is no confirmation step, no diff surface, and no record of what ran.

What a governed layer changes — and what it does not

I am not going to tell you Contextium would have stopped this. It would not have, and any vendor claiming their product would have prevented a specific zero-day is telling you something about their marketing rather than their architecture.

What a governed context layer changes is the class of exposure, and that is a narrower and more honest claim.

If a team's standards are distributed as content only — prompts, conventions, decision records, retrieved on demand rather than executed at startup — then a compromised upstream can give you a bad instruction. It cannot give you a command that runs before you have read anything. The worst case degrades from remote code execution to a wrong opinion, which your review process is already built to catch.

If every change to a standard is a versioned diff with an author, the reviewing instinct fires, because the artefact looks like the things people already review. Pinning to a reviewed revision rather than a moving branch is the same discipline the ecosystem learned for dependencies, applied one hop later.

And if retrieval is audited per item, you can answer the question every incident review asks: what did this agent actually read, and when. That is the property we had to build for ourselves before we could claim it — our own audit surface was request-level before it was item-level, and request-level logging cannot answer that question. The five tests for whether you control your AI context cover why that distinction decides an incident review. Our access model and log surface are documented on the security page.

Statelessness helps here too, for a reason that is easy to miss: because MCP servers assemble context per call rather than accumulating it in a session, there is no long-lived local store quietly acquiring instructions nobody approved. Each retrieval is a fresh, inspectable request against a source you control.

None of this makes agents better at their jobs. There is no evidence that governed shared context improves accuracy and we do not claim it. What it buys is that context is cheaper to distribute than N copies, consistent across every tool, and auditable — and auditable is the one that matters this week.

What to do this week

Four things, in order of how quickly they pay off. None requires buying anything.

Make agent config review-required. Add .claude/settings.json, .vscode/tasks.json and any .mcp.json to CODEOWNERS. If a rules file can execute, it deserves the review a CI config gets.

Pin external context sources to a commit you have read. Not a branch. Read the hooks and the MCP server definitions specifically — that is where capability hides. A skills repo you track by branch is a standing grant of code execution to whoever holds the write bit.

Separate content from executable config. Keep standards, conventions and prompts in an artefact that cannot register a command. Then an update to how your team writes tests can never be an update to what runs at session start.

Rotate what a session-start payload would have reached. Cloud CLI profiles, CI tokens, anything in a local secrets store, anything a Kubernetes context can read. If you cloned anything from an untrusted source in early August and opened it in an editor, assume attention was enough.

The advice to write your standards down for your team's AI is still correct. It was correct last week and this incident does not change it. What changed is that the pipe those standards travel through turned out to be a pipe for other things too — and it is the only part of a modern toolchain nobody had thought to review. That is a fixable oversight, and mostly it is fixable with the review discipline your team already applies one layer down. The mechanics of running context as governed content rather than executable config are worth an afternoon.