Nobody Owns the Skill Layer

When a browser extension turns malicious, there is someone to call. Google can pull the listing, revoke the signature, and push the removal out to every machine that installed it. Unglamorous machinery, and it works. Ask the same three questions about the skills your agents loaded this morning and the room goes quiet. Who reviews them? Who signs them? Who can pull one back? I have not found an answer, and this week made the gap harder to look away from. Start with the fact that OWASP had to write a new list at all. The existing lists cover the model, and the protocol an agent uses to reach its tools. Neither covers the packaged behaviour that decides what those tools get used for. And the format proposed alongside the list reads as a request, field by field, for things that do not exist yet: a publisher identity, a signing key, a hash of the package, a declared permission set, a scan record. You do not draft that manifest for a layer that already has provenance. Then the experiment. In June, Air Security researchers built a skill in under an hour that genuinely did what it promised, generating landing pages for non-technical staff. Its instructions sent the agent to fetch setup documentation from a domain they controlled. Then they collected the two signals people use to judge a skill. Scanner approval came free, because scanners read files and the payload was a link. Stars they borrowed, opening a pull request into a plugin marketplace repository with roughly 36,000 stars and a welcoming contribution policy: "after a few anxious days, it got merged." They ran an Instagram ad, swapped the documentation, and victim emails started arriving. Twenty-six thousand agents, including corporate ones. OWASP now cites that work as the real-world evidence behind its risk for untrusted external instructions. Niv Hoffman co-authored the research and is one of eight co-leads on the OWASP project. For scale, dated honestly: when Snyk audited 3,984 published skills in February, more than a third carried a security flaw and 13.4% carried a critical one. The fair objection is that nobody is asleep. Rust's volunteers deleted malicious releases 86 to 107 minutes after being told. ClawHub, a major skill registry, added automated scanning and partnered with VirusTotal. That response is real and fast. It is also reactive, discretionary, and dependent on an outsider noticing first. Nothing stands between publication and installation as a matter of course. The comparison I reached for first is the one I trust least. Extension stores went through this and survived, so the reassuring read is that this layer will too. But a rogue extension is confined to the browser and what the browser can see. A skill runs commands on the machine, with the user's credentials, inside whatever systems that agent can already reach. The governance is a decade behind and the blast radius is on a different scale. Registries, signing, revocation and takedown are not solved anywhere, as this week's two registry attacks show. But elsewhere they are at least owned. So what would owning it look like here? An enterprise registry the organisation actually controls, with an allowlist and a written policy on what may be installed and by whom, instead of a public marketplace run by people who owe you nothing. Continuous monitoring of what skills and MCP servers do once they are running, because a one-time review checks behaviour that is free to change after approval. That is exactly how the Air package worked: it passed every scanner because the payload was a link, and the researchers swapped what sat behind it later. And revocation that reaches everywhere at once, so when a public skill turns, an organisation can suspend it across every machine in one action, the way a browser vendor pushes a removal. I have not found that last capability offered for skills anywhere yet. None of that is exotic. Somebody still has to decide to own it here. Until that job has a name attached, every skill install is a trust decision made by a person with nothing to check.