A while ago I wrote the MCP server supply-chain question and got a fair amount of mail telling me I was being paranoid about a problem nobody had actually demonstrated. May 2026 demonstrated it. I am not going to take a victory lap, because the details are more boring, and more damning, than the version I worried about.
What actually shipped as a breach
The May CVE wave, as reported by DarkReading and eSecurity Planet, is not a set of clever model attacks. It is a list of ordinary security failures: four CrewAI CVEs turning prompt injection into remote code execution, an Azure SRE Agent endpoint left unauthenticated, a command-injectable tool parameter in Google Antigravity, NVIDIA’s red team walking a poisoned AGENTS.md into code execution on Codex, and over a thousand malicious skills on a single registry. Read that list with the word “agent” removed and it is indistinguishable from any other bad supply-chain year: unauthenticated endpoints, injectable parameters, an untrusted config file, a package registry with no provenance.
The poisoned AGENTS.md is the one I keep coming back to, because it is the least dramatic and the most instructive. Nobody broke the model. Someone changed a Markdown file the agent reads on startup, and the agent — working exactly as designed — carried those instructions out with the developer’s own credentials and tool access. There was no exploit in the usual sense. The config file was the exploit, because the agent treats config as a command and the supply chain delivering that config had no provenance check on it at all.
We spent the year guarding the wrong door
For two years the security conversation around coding agents has been about the model — jailbreaks, prompt injection as exotic research, the alignment of the thing in the middle. Meanwhile the actual breaches walked in through the config. An AGENTS.md is executable influence over an agent that holds your credentials. A skill is a program. An MCP server is, functionally, an RPC daemon, and a lot of people apparently ran one with no authentication on a reachable interface. We were threat-modeling the engine and leaving the doors unlocked, and the May disclosures are simply someone walking through the doors.
This is the same delegation the 60% claim measured from the other end. When an organization announces that the majority of its code is now agent-written, the unasked question is not how much the agent produced — it is how much of that code’s supply chain nobody reviewed, because “the agent wrote it” and “the agent pulled it in from somewhere” feel like the same sentence and are not.
Portable skills cut both ways
This is the uncomfortable part, because I argued the other side recently. In writing portable skills I made the case that a SKILL.md you can run on Claude Code, Codex, Cursor, and several community tools is a feature — less lock-in, write once, run anywhere. All of that is still true, and it is exactly why the supply chain is now the problem. A portable skill is portable blast radius. The same property that lets a useful skill propagate across every agent in your org lets a malicious one do the same, faster, because “it already works everywhere” is precisely the review that portability tempts you to skip. A thousand-plus malicious skills on one registry is what “write once, run anywhere” looks like from the attacker’s side. I do not retract the portability argument. I am saying it has a bill attached that I under-priced when I made it.
The honest counter-argument
The strongest steelman is that this is not an indictment of agents, it is an ecosystem growing up. Every package ecosystem went through exactly this — npm, PyPI, and browser extensions all had their malicious-registry and unauthenticated-daemon era, and came out the other side with signing, provenance, and pinning. On that view the May wave is not a crisis; it is the predictable adolescence of a new package manager, and the fixes are already known: pin versions, ship an SBOM, require auth and TLS, do not auto-pull from registries you cannot verify. I find this mostly convincing. The mitigations genuinely are boring and known. What the analogy elides is that npm reached maturity after years of incidents, and the artifact being pulled here is not a leftpad — it is instructions executed with your credentials by something built to act on its own.
Where I have landed
One rule, and it is not exotic. Treat AGENTS.md, CLAUDE.md, every skill file, and every MCP server config as untrusted code, because that is what they are: code that runs with your access, written in Markdown and YAML so that it does not feel like code. They go through pull-request review like any other executable change, they get pinned, and nothing auto-installs from a registry without provenance. The entire hardening checklist is downstream of that one reclassification. The failure across the whole May list is the same category error repeated: someone treated a config file as configuration instead of as a program, and the program had a shell.
Concretely, that reclassification has teeth: a pull request that only touches AGENTS.md or adds a skill gets the same reviewer, the same scrutiny, and the same “what can this do with our credentials” question as a pull request that touches authentication code — because in capability terms it is the same pull request. The teams that get burned over the next year will be the ones who kept config in the “docs” mental bucket while it was quietly in the “executes with prod access” bucket the whole time.
There is a second bill coming due from the same direction, and it is not a security bill — it is the literal invoice. Every one of these agents is making model calls that someone is paying for, mostly at a loss, to acquire you, and the vendors being honest about that are rarer than the researchers being honest about the security. That is the last thing in this arc worth looking at squarely: the honest token bill.
