The agent skill supply chain: what you can actually see today

2026-10-20 — skill marketplaces have quietly become the newest package manager. A skill is a folder — instructions in markdown, sometimes helper scripts, sometimes hooks — that your agent follows with the same trust it gives its own system prompt. The difference from a normal dependency: nobody reviews it, there is no lockfile, updates land silently, and it is executed by an agent that already has your file system, your shell, and your credentials in reach.

Why a skill is a supply-chain object

• It is instructions, not just code: a skill steers what your agent does with the permissions it already has. A malicious prompt line needs no exploit.
• It ships unversioned: most installs track a moving branch, so the thing that worked yesterday is not the thing that exists today.
• It composes: skills call tools, tools connect to MCP servers, MCP servers reach the network — a chain of third parties, each trusted by the layer above.
• It updates without asking: upstream pushes, your agent pulls next session, no human in the loop.

What honest visibility means here

Three questions, in order of cost to answer. First: what is installed, and where did it come from — an inventory of skills, plugins and MCP servers per machine. Second: what changed upstream since I installed it — a diff between the pinned state and the repository’s current state. Third: what did my agent actually do after it loaded this skill — the local action record. Notice what is not on the list: a green banner saying “no malware detected.” Scan theater is easy to claim and hard to keep honest; visibility is the part that is actually buildable.

The two observation surfaces we run today

For the upstream question, SkillWatch keeps public watchlists of agent-skill repositories and publishes a daily report of what changed — plus a single-page risk-scan example you can look at without signing up for anything: <a href="https://watch.20131.com/verify">watch.20131.com/verify</a>. It is a read-only watch surface: it reports what it sees and links to the evidence. For the local question, 20131 writes one audit line per observed agent action on your machine — attribution, command shape, the verdict in force at the moment — walked through line by line in <a href="/en/blog/agent-actions-audit-trail/">the audit-trail post</a>. Neither tool blocks anything yet, and both say so on the page. That is a Phase 0 statement, not a disclaimer bolted on afterward.

A checklist you can use without any product

• Read a skill’s SKILL.md before installing it, with the same suspicion you’d give a setup.py.
• Pin what you can: snapshot the commit you installed from, so “what changed” has a left-hand side.
• Watch side effects, not just text: when a new skill goes in, notice which files and endpoints your agent starts touching the next day.
• Keep an inventory per machine — the honest answer to “what is installed” for most teams today is “unknown”.
• Treat skill + MCP + agent as one chain: the risk is the composition, not any single folder.

Where to go from here

The broader frame — what makes an agent action observable at all — is in <a href="/en/blog/what-is-agent-observability/">what is agent observability</a>, and integration depth per agent family (including how skill folders enter the local record) is stated honestly on <a href="/en/supported-agents/">supported agents</a>. If you want the verdict-gated version of the chain, the <a href="/en/early-access/">Early Access waitlist</a> is the shortest path — and supply-chain rules are exactly the kind of policy the rule file will be tuned on.