MCP standardized how an agent talks to a server. It did not standardize whether you should trust the server. We scoped that problem to tools and moved on. The Skills Over MCP Working Group’s SEP-2640 is now final, and skills ship over the same channel. So it is worth being precise about what that means.
Let’s start with what a skill is. A skill is a set of instructions that steers how a model reasons and acts: not a tool it calls, but a playbook it follows. Under SEP-2640, your agent discovers skills from an MCP server, fetches them at load time and loads them into context. The server that hands your agent its tools now hands it its instructions, too.
The people who wrote the spec were not careless about this. The security section is real work, and if you are going to form an opinion, you should read it. It requires a SHA-256 digest for every file in a skill. It binds user approval to the content, so any change revokes approval and prompts the user again. It scopes resource reads to the origin, so a skill from one server cannot trigger a read from another. It namespaces skills by origin so a server cannot silently shadow a skill you already trust. It treats skills as untrusted input and insists that the origin stay visible to the model. The working group also published a threat model backed by a runnable adversarial corpus, real malicious skills you can point a host at to see whether it holds. That is a group taking the threat seriously.
Now read the requirement they wrote: hosts MUST NOT treat a digest match as a security boundary. As the spec states, digests are unsigned and come from the same server as the content. If that server is malicious, compromised or simply not who you think it is, it can rewrite the listing and the content together, and every digest will still match. The integrity check confirms that the bytes did not change in transit. It says nothing about whether the source was ever trustworthy.
This is the part worth sitting with. Every control in that security section is downstream of a question none of them answer: Should you trust this server at all? The digests, the approval binding and the origin scoping all assume you are connected to a server worth talking to, then work to contain what that server can do once you are. That is useful. Containment matters. But it is a defense built on top of an unsolved trust root, and the spec is honest enough to say so.
We know what happens to that trust root because we have watched it break. A malicious Postmark MCP server that was not from Postmark, and that BCCed a copy of every email to an address its author controlled, was downloaded 1,643 times before npm pulled it. A cloned Oura server delivered an infostealer. A typosquatted GitHub server ran code at install time. These are not exotic cases. They are the common ones, and they are all the same failure: You trusted an operator you had no way to verify.
Skills do not introduce that failure. They inherit it, and they widen it. The shift is from “Here are my tools” to “Here is how your agent should think.” Same unverified operator, larger surface, and now the surface is the model’s own reasoning.
There is a quieter cost, too, and it is the one I keep coming back to. Think about what a skill was before it shipped over a connection. It was a file. You could pull it, read it, scan it, pin its digest, sign it and decide at admission whether it was allowed into your environment before anything loaded it. The skill was an artifact, and artifacts are things you can hold still and inspect.
Skills over MCP does not deliver a signed artifact. It replaces the artifact with a live stream. There is nothing to pin before the skill enters, nothing to admit by policy, nothing to attest. The per-file digests are a within-session integrity check supplied by the origin, useful only against tampering between the list call and the get call. They are not a build-time attestation by an identity independent of whoever is serving the bytes. Those are different things, and only one of them answers the questions: Where did this come from, and who vouches for it?
That is the good ladder we walk past. Package the skill the way we already package models and datasets. Give it a build-time identity. Sign it. Attach provenance that says who produced it and from what. Pin it by digest so it cannot change under you after you have admitted it. Then make admission a policy decision enforced before the agent ever sees the skill, using a signature that does not depend on the server handing it to you. The impersonator fails that check. The tampered artifact fails that check. The anonymous upload with no provenance fails that check. Most of what is hurting people right now fails that check.
This is what we built ModelKits for. A ModelKit packages an AI artifact, whether a model, a dataset or a skill, as a signed, versioned OCI artifact with attached provenance. It is built once, signed by an identity independent of whoever later serves it, and pinned by digest so it cannot change after you admit it. You can verify where it came from and who vouched for it before it ever reaches the agent. That is the sturdy ladder that was already standing. A skill is just another artifact, and we already know how to sign artifacts.
I want to be careful about what packaging does not do, because the honest version of this argument has a boundary. A signature proves that the bytes came from the authentic publisher. It does not save you from an authentic publisher who has been compromised and signs a poisoned skill with the real key. That case is real, and packaging does not close it. But that is one case. It is not the supply chain. The supply chain is provenance, integrity and admission control, and those are exactly the risks a signed artifact can address but a streamed one cannot.
So here is the whole thing in one line: Skills over MCP standardized the transport and delegated the trust. It tells you which server delivered the bytes. It does not tell you who wrote them or whether you should have let them in.
We had a sturdy way to carry this. We stacked it on a broken one instead, and we are climbing because the view from the top is good.