The Engineer

What Happened

The Shai-Hulud/Miasma campaign has compromised 90+ packages under the @redhat-cloud-services npm scope — widely used in OpenShift console plugins and Red Hat Insights integrations. Unlike previous supply chain incidents (event-stream, ua-parser-js), this is a self-propagating worm, not a static payload. It exfiltrates npm tokens, GitHub PATs, AWS credentials, and SSH keys, then uses stolen publish tokens to propagate into other packages the compromised maintainer controls.

A CI/CD pipeline that installed any of these with credentials in scope is now compromised, and the worm may have pushed into other packages under the same maintainer.

The AI Agent Amplification

The codexui-android variant reveals the modern twist: the malicious loader chunk-PUR7OUAG.js ships only in the npm tarball, not in the public GitHub repo. This defeats "check the source" heuristics. Exfil goes to sentry.anyclawstore, which reads as Sentry telemetry to any allowlist-by-pattern egress rule. The publisher, BrutalStrike, ships legitimate apps with 5M downloads — reputation laundering is part of the kill chain.

AI coding agents generating npm install commands or adding dependencies sit directly on this surface. They cannot distinguish a compromised package from a legitimate one. The agent adds the dependency, the postinstall script runs with CI credentials, game over.

The Defensive Stack That Actually Works

npm 11.16.0 ships allowScripts in advisory mode. Advisory means it logs and continues — flip it to deny in CI immediately. This is one config line that prevents postinstall scripts from executing on packages not on your allowlist. Pair with:

• Provenance attestation: npm publish --provenance signs against the GH Actions workflow. Verify on install with --expect-provenance.
• Pin by digest, not version: npm pack --dry-run to diff tarball contents against GitHub source.
• Workload identity federation: Replace static AWS_SECRET_ACCESS_KEY in CI with 15-minute scoped role assumptions.

Cross-Source Convergence

Five independent sources flagged this attack in the same cycle. The convergence is itself signal: this is not one analyst's opinion. The attack is confirmed, documented, and being actively exploited. Microsoft Security Intelligence, Rapid7, and the npm security team have all issued advisories. The window between compromise and detection is hours. Act accordingly.

The Pattern

Five incidents this week, one architecture: an AI agent holds privileged credentials, accepts untrusted input, and has no deterministic authorization boundary between the two. The prompt injection is not the vulnerability. The vulnerability is that the tool surface includes "push to main," "transfer account ownership," and "execute SQL" while the input surface includes "any string a user typed."

If your refusal logic and your attack vector are the same string, the attacker only has to be more persuasive than the system prompt. They were.

The Five Incidents, Dissected

Why This Keeps Happening

The confused deputy problem, restated for 2026 tooling. The agent gets a tool like reset_account. The tool checks that the caller is "the support bot." It does not check that the bot is acting on behalf of the verified account holder, because that identity is a string in the prompt. Strings in prompts are whatever the last message said they were.

The Fix Is Architectural, Not Prompt-Level

1. User identity as non-prompt argument: every tool call takes end-user identity from the authenticated session. Not from conversation context.
2. MCP transport hardening: move off stdio (spawned subprocess, no auth) to HTTP/SSE with explicit authentication. Treat every MCP server as an untrusted microservice endpoint, because that is what it is.
3. Deterministic authorization gates: high-severity actions require out-of-band confirmation the model cannot speak on. Signed tokens, rate limits, human approvers above a threshold.
4. Policy enforcement at the tool boundary: Prempti (Apache 2.0, Falco ecosystem) intercepts tool calls against YAML rules covering .env, ~/.ssh/, ~/.aws/ access. Early but usable.

The Uncomfortable Truth

None of these attacks needed a zero-day. They needed reading the docs and noticing which credentials the agent had been handed. The METR/Anthropic RCT finding that experienced developers are 19% slower with AI on familiar codebases reads differently in this light. The speed gain comes out of security review depth. Agents ship faster than the permission model around them. That was not a hard prediction. It is the one that keeps being right.

The Phase Transition

GitHub is running infrastructure designed for human-speed usage at machine speed. Commits grew roughly 14x in eighteen months:

• Commits: 1B in all of 2025, then 275M per week in April 2026 (14B annualized)
• Actions compute: 500M to 1B minutes/week in two years
• Coding agent growth: 1400% in 2026 alone

The revealing detail is 'MySQL One', GitHub's internal name for the primary database that still houses the permissions layer. Every authorization check for every git push, every API call, every Actions invocation hits this system. Kyle Daigle names it as the primary source of availability problems.

The authorization layer becomes the bottleneck at scale, and by the time it does, it is too late for a quick fix. Vitess is not the lesson. The coupling is.

Anthropic's 1000-Agent Answer

Dynamic Workflows orchestrates up to 1,000 subagents with a 16-concurrent-agent ceiling. The Bun port (Zig to Rust, 750K LOC, 11 days, 99.8% test pass) shows the pattern works when the problem decomposes cleanly. The scheduling layer is doing the work, not the model:

• Per-symbol locks prevent circular refactors. 40 lines of Python.
• Agents that fail twice get demoted to smaller scope.
• 0.2% failure at 750K LOC is roughly 1,500 lines that need manual cleanup

Kent Beck's trust debt framing is the counterweight. AI shortens time to write. It does not shorten time to understand. Ship 1,000-agent-generated patches without proportional review investment and the obligation surfaces later as a regression nobody can localize. The METR/Anthropic RCT confirms it. Experienced devs are 19% slower with AI on familiar codebases because correction overhead exceeds generation savings.

Capacity Planning Implications

GitHub needs CPUs, not GPUs. Inference happens upstream. What GitHub sees is the downstream multiplier: each agent user generates 5-15x the CI/CD compute. Their fix is hybrid burst architecture, Azure Dev Compute for fast VM spin-up.

The Micro-Skills Pattern

GitHub moved from 'mega-skills' to atomic, single-purpose operations. This matches what works in MCP tool design: thin tools + rich context > fat tools + limited context. Small tools with clear I/O contracts compose. Swiss-army-knife integrations do not.

The honest read: if the authorization service is coupled to a single data store, model the behavior at 10x current request rate. If CI/CD compute is budgeted for human-speed usage, multiply by 10 and check whether the number still fits. Those are the two systems that break first under agent load.