tl;dr
An Agent Skill used to be a folder on a machine. SEP-2640, an extension to the Model Context Protocol (MCP, the standard way an AI agent connects to outside servers for tools and data) that was finalized in September 2026, now lets a server serve a skill to an agent over MCP, alongside the tools it already gives it. The specification is strict about the danger and puts most of the defence on the client, the agent app itself. But the clients have not caught up: as of late October 2026 almost no mainstream agent loads a served skill at all. So the extension itself is not the live risk today. The live risk is the two routes that already place skills on your machines, which no part of the specification governs.
- An MCP server can now hand your agent a skill. Under SEP-2640, a server serves a
SKILL.md, its files, and a script to any agent that connects to it, alongside its tools. - Almost no agent loads them yet. Claude Code, Claude Desktop, Cursor, and VS Code Copilot don’t support served skills, so blocking them today costs you nothing.
- SEP-2640’s “verified” is not “safe.” The integrity checks the extension defines prove a skill matches what the server advertised, not that it is trustworthy. The protections that matter are the client’s, and most clients have not built them.
- The live risk skips the protocol entirely. A program already on the machine can write a skill into the folder your agent trusts and runs, or the agent can be talked into saving one itself. Watch those folders now.
The live risk today
An Agent Skill is a bundle of instructions, often with a script, that an agent loads and follows when a task calls for it. Today a skill lives as a folder on the machine, and every major agent, Claude Code, Cursor, Codex and the rest, trusts the skills in a few fixed folders and runs them without a second look.
That trust is the exposure. Anyone who can write to those folders, or talk an agent into writing to them, can plant a skill the agent will follow, scripts included. Two routes do this today, and neither touches a protocol or a safeguard. The first is a program already on the machine: a local MCP server, for example, runs as a program on the person’s own computer with their permissions, not as a remote service reached over the network, and nothing stops it writing where the agent looks for skills. The second is the agent itself: a tool result (the output an agent gets back when it calls a tool), or a server’s instructions, can talk the agent into saving a skill with its own file-writing tool.
A planted skill is trusted like anything the person put there. This is not theoretical. Our own scan of a skills marketplace found skills built to do real harm. The control that covers both routes is knowing which AI agents your staff have installed, and what skills those agents load.
Where SEP-2640 comes in
So why is there a new specification to read about? Because the MCP ecosystem is standardizing the very thing those two routes abuse: how a server hands an agent a skill.
Until now, a server that wanted to give an agent a skill did it in its own ad-hoc way, with no standard and no signal to the user. SEP-2640, which reached Final status on 13 September 2026, gives one defined way. A server declares the io.modelcontextprotocol/skills capability (it announces it can serve skills), and a connected agent can list its skills and fetch each one as skill:// resources (the SKILL.md, its files, and any script), each carrying a SHA-256 digest so the client can check it got what the listing (what the server advertises it has) promised, served alongside the server’s own tools.
It is worth being clear about what that helps with. SEP-2640 fixes distribution: a standard, checkable way to serve a skill, with a set of rules for the client to follow. It does not fix trust. A standard, checkable way to deliver a skill is not a safe skill, because the content still comes from whoever the user connected to, and a skill is not passive: it hands the model a block of instructions to follow and can tell it to run code. The specification says so plainly, calling a served skill “a higher-risk surface than remote tool invocation”. So the SEP-2640 route is a third way a skill can reach your agent, alongside the two already described.
The figure ranks all three by how much risk each carries today. The two high-risk routes are the ad-hoc ones above; the third is the SEP-2640 route, low risk today only because almost nothing loads it yet. The list below the figure explains each one in the same order.
Ranked from highest to lowest live risk. One, a local server writes the folder, high risk: a local MCP server runs as the user and can write a skill into the agent's skills directory, where it is trusted like any local skill and no part of the specification applies. Two, the agent is talked into saving it, high risk: a tool result or server instruction persuades the agent to save a skill with its own file-writing tool, which also needs no protocol. Three, served over MCP under SEP-2640, low risk today: the specification's route, which carries real safeguards, but almost no client loads these skills yet.
- 1 · High risk A local server writes the folder A local MCP server runs with the user's rights and can write a skill folder into the agent's skills directory, where it is trusted like any local skill. No part of SEP-2640 applies.
- 2 · High risk The agent is talked into saving it A tool result or server instruction persuades the agent to save a skill with its own file-writing tool. This also needs no protocol, so the specification's safeguards never run.
- 3 · Low risk today Served over MCP under SEP-2640 The specification's route. It carries real safeguards, but almost no mainstream client loads a served skill yet.
What the spec puts on the client
SEP-2640 is unusual in how much of the defence it writes down, and in where it puts it. Almost every rule is an obligation on the client, the host application the person runs, rather than on the server. The specification states these as requirements the client must meet; grouped here as a checklist, they are the behaviours that decide whether a served skill is handled safely:
- Treat the content as untrusted, and show where it came from. A connected server does not make its skill authoritative. The client must apply the same prompt-injection caution it applies to any server text, and must tag the skill with its origin where it enters the model’s context, so a served skill is never shown as if it were a local one.
- Ignore tool-permission requests unless a person approves them. A skill’s front matter (the settings block at the top of its
SKILL.md) can listallowed-toolsto widen what the agent may do. For a skill that arrived over MCP, the client must ignore that list unless the user has approved it for that skill, and must gate any code the skill points at behind the same approval. - Verify the digests, but do not trust them. The client must check each file against its digest and refuse a mismatch. The specification is explicit that this proves consistency only: “Digests are not a security boundary.” They are unsigned and come from the same server as the content.
- Bind approval to the content. If a skill’s file set changes after a person approved it, the approval is revoked and the client must ask again. A server cannot swap in new instructions under an old yes.
- Never let a served skill quietly take a local skill’s name. Names collide, and a server can publish a skill under the name of a popular local one. The client must keep origins separate and must not let a served skill shadow or replace a same-named local skill.
- A dynamically generated skill carries no integrity. Such a skill is marked as dynamic, cannot be content-bound, and the client may refuse to load it.
The pattern is the point. These are protections the client has to build. Where a client has not built them, connecting to a server that serves skills gives that server a direct line to the model, with none of these checks in the way.
Expect the major clients to get this right. The teams behind the agents your staff already use have the people, the scrutiny, and the reason to implement the full set before they ship skills support. The risk sits in the long tail: the smaller, newer, or in-house agents that add skills over MCP because it is easy and leave out the approval prompt, the origin tag, or the re-approval when content changes. Those are also the agents an IT team is least likely to know its staff have installed.
What verification proves
To show what a conforming client’s checks do and do not catch, we built a small test server and a client of our own. The server offers a skill; the client fetches it and runs exactly the checks SEP-2640 requires (the byte size, the SHA-256 digest, and a field-by-field comparison of the skill’s front matter against what the server advertised), then reports the skill as verified if the checks pass or rejected if they do not. It uses no outside dependencies, runs only on our own machine, and executes nothing it is sent.
We ran it four times. Between runs we changed one thing about what the server sent; the table shows what we changed, what the client did, and whether verifying it left you protected.
| Run | What the server sent | What the client did | Protected you? |
|---|---|---|---|
| Honest | A skill whose files, sizes, and front matter all match what it advertised | Verified it | ✓ |
| Tampered bytes | A SKILL.md whose bytes differ from the size and digest it advertised |
Rejected it (the size check catches it before the digest does) | ✓ |
| Tampered front matter | A SKILL.md whose description differs from the advertised one, every digest still matching |
Rejected it (the front-matter comparison catches it) | ✓ |
| Injected | A self-consistent skill, every file matching what it advertised, but whose SKILL.md tells the agent to do something and asks for broad tools |
Verified it | ✗ |
That last run is the finding. A skill can be fully verified and still be hostile. The digests are unsigned and come from the same server that serves the skill, so a match proves only that what the server advertised and what it sent agree, nothing more. Whether that injected skill is harmless then rests entirely on the client behaviours in the section above: showing the origin, ignoring the tool request until a person approves it, and gating anything the skill tells the model to run. Those are the protections the checks cannot provide.
To recreate this, you do not need our rig. Write a short MCP server that declares the skills capability and serves a SKILL.md with matching digests, or point the MCP Inspector, a developer testing tool, at an existing one with its --verify command: it runs the same size, digest, and front-matter checks and sets a pass or fail exit code. The useful exercise is to confirm what “verified” means for the client you are testing, and then to check, separately, whether that client shows the skill’s origin, holds back the tool request, and gates execution.
Who supports it yet
The short answer: almost nobody your staff would recognise. For a served skill to reach an agent, three pieces all have to support the extension, and today the one that matters is the gap.
This is where each piece stood in late October 2026. It is moving, so read it as a snapshot.
| Piece | Where it stands, late October 2026 |
|---|---|
| The toolkits developers build with (SDKs) | Starting to add it. The main TypeScript toolkit added support in October 2026; the Python one has the pieces but no released version yet; others are in progress. These are what clients and servers are built with, not something your staff run. |
| The servers that offer skills | A few do, including Hugging Face’s. A survey in October 2026 found only four public servers serving skills to the standard, out of more than a thousand checked. |
| The agent apps your staff run | The piece that matters, and the gap. Claude Code, Claude Desktop, Cursor, and VS Code Copilot do not load served skills. By the extension’s own client tracker, only ChatGPT, the fast-agent framework, and the MCP Inspector support them, and only partly. |
So the surface is real and worth understanding before it arrives, but it is not live in your environment today. The first mainstream agent to add support is the one to test before you let it connect to servers you do not control.
Summary
The risk that is live today is close to home and needs no new protocol. A skill is a bundle of instructions your agents trust and run, and anyone who can write to the folders they read from, or talk an agent into writing there, can plant one. Watch those folders, and keep an inventory of the AI agents your staff install and the skills those agents load. That inventory and check is what Supply Chain, a module of Signals Corps Control Plane, is built to give an IT or security team.
SEP-2640 is the standard the MCP world is building for serving skills, and it is worth reading before it reaches the agents your organisation uses. It fixes how skills are distributed and writes real rules for the client, but it does not make a served skill safe, and almost no mainstream agent loads one yet. When a client you deploy does add support, ask the questions the specification answers: does it show a skill’s origin, hold back its tool requests until a person approves them, gate any code the skill runs, and re-approve when the content changes. Treat a “verified” label as proof of consistency, never of safety.