Vercel's Skills API Turns Agent Skills Into Infrastructure

Vercel opened the skills.sh API on June 5, 2026. Any project holding a Vercel OIDC token can query more than 600,000 agent skills, with search, metadata, content hashes and audit records, at 600 requests per minute. Skill distribution is now programmable, which turns skill verification from a browsing habit into a platform control.

Updated September 2026: the API and its OIDC auth model are unchanged. skills.sh still publishes a public leaderboard and an audits section, and vercel-labs/skills remains the reference client behind npx skills add.

The announcement is short and worth quoting in full:

The skills.sh API is now available. Authenticate with your project’s Vercel OIDC token and start querying more than 600,000 skills from across the open-source ecosystem.

— Vercel changelog, June 5, 2026

That is a real ecosystem milestone. Skills move from a website you browse manually to an index that agents, dashboards, installers, and internal developer platforms can query automatically. It is also why the launch deserves security attention: the security discussion around skills.sh has been running for months, and in a Vercel Community thread from February, users asked for integrated behavioral scanning because skills carry the same supply-chain risk as other project dependencies.

Key Figures

Figure	What it measures	Source
600,000+	Skills queryable through the skills.sh API	Vercel changelog, June 5, 2026
600 req/min	Rate limit, per team and per project	Vercel changelog
SHA-256	Hash type returned for a skill snapshot’s file contents	Vercel changelog / skills.sh API docs
5	Named partner audit providers exposed by the audit endpoint	Vercel changelog
3,984	Skills in the first large-scale independent audit	Snyk ToxicSkills, February 2026
36.82%	Audited skills with at least one security flaw (1,467 skills)	Snyk ToxicSkills
534	Audited skills with a critical-severity finding	Snyk ToxicSkills
76	Audited skills carrying active malware	Snyk ToxicSkills
1,184	Malicious skills counted in the ClawHavoc campaign	ClawHavoc post-mortem
39,884	MCP server repositories audited by VIPER-MCP, for comparison	VIPER-MCP, May 2026

Two of those rows sit badly together. The API can hand a machine 600,000 install targets; the only audit of the corpus at comparable scale found a security flaw in better than one in three skills it looked at. That ratio is the argument for treating registry output as an input to policy rather than as an answer.

Why This Launch Matters

The API documentation describes a catalog, leaderboard, search endpoint, curated first-party skill set, skill detail endpoint, and audit endpoint. Authentication uses Vercel OIDC, with short-lived project-scoped tokens rather than long-lived API keys, and the API is rate-limited per team and project.

Those are sensible platform choices. Short-lived OIDC credentials reduce secret leakage. Project scoping gives Vercel a way to attribute usage. Rate limits make large-scale polling predictable.

The more interesting part is the data model. The skill detail endpoint can return the skill’s file tree, a SHA-256 hash of file contents when a snapshot exists, install counts, source identity, and install URL. The audit endpoint can return partner audit results from providers such as Gen Agent Trust Hub, Socket, Snyk, Runlayer, and ZeroLeaks. That install URL is what a client hands to npx skills add, which resolves it and writes the files into every agent directory it finds on the machine.

That turns skills into something closer to packages:

• They have stable IDs.
• They have sources.
• They have install URLs.
• They have content hashes.
• They have audit records.
• They have popularity and trend signals.

For developers, this makes discovery easier. For security teams, it creates a control point. A company can now ask: which skills are installed, which exact source do they point to, which hash did we approve, which scanners reviewed them, and which skills have no audit yet?

That is the right shape. It is also only the beginning.

The Registry Signal Is Now A Dependency

When humans browse a skill registry, bad metadata is annoying. When tooling consumes that directory automatically, bad metadata becomes a dependency risk.

An installer might choose the highest-ranked matching skill for a project. A dev portal might display “approved” status based on an audit endpoint. A repository bootstrap script might fetch a skill by stable ID and write it into .claude/skills/, .cursor/skills/, or another agent directory. An agent might search the catalog as part of an on-demand workflow.

In each case, the registry is no longer just a discovery site. It is part of the decision path that changes agent behavior.

That matters because skills are not passive documentation. A skill can instruct an agent to read files, invoke tools, write code, run scripts, call APIs, or route work through MCP servers and connectors. We covered that broader threat model in Claude Code skill security and the ToxicSkills audit: skills define intent for agents that may already have meaningful local and cloud permissions.

At 600,000-plus indexed skills, manual review is not the primary safety model. The ecosystem needs machine-readable trust signals. The API provides some of those signals. The hard part is making sure consumers treat them as inputs to policy, not as decorative badges.

The Git-Backed Distribution Problem

The biggest open question for any Git-backed skill directory is provenance.

A paper presented as Context Matters: Repository-Aware Security Analysis of the Agent Skill Ecosystem studied agent skill marketplaces and called out a specific problem: skills.sh indexes skills from external Git repositories. That model scales well, but it inherits GitHub identity and mutability risks. The researchers identified repository-hijacking risk across abandoned repositories referenced by skill indexes, and the companion r/netsec discussion focused on the practical consequence: if a marketplace points to a mutable external repository, the user may not be getting the same artifact they thought was reviewed.

Figure: Every hop between a registry query and a loaded skill is a place where the artifact can differ from the one that was audited. Only a content hash checked at install time closes the gap.

This is not unique to skills.sh. MCP server registries, package ecosystems, plugin directories, and prompt marketplaces all run into the same tension:

• Link-out distribution scales quickly.
• Direct hosting gives the registry stronger control.
• Branch heads are mutable.
• Tags can be moved.
• Repository ownership can change.
• Usernames can be recycled.
• Install URLs can keep working while the trust relationship behind them changes.

Hashes help, but only if clients check them against the artifact they actually install. Audit results help, but only if they are tied to the exact content version, not just the repository name or latest branch state.

The useful security question is not “does this skill have an audit?” It is “does this exact file tree match the version that was audited, and is that still the version my agent is about to load?”

Audits Need Context

The audit endpoint is valuable because it makes security review consumable by tools. But the public discussion around skill scanners points to another issue: scanners do not always agree. The repository-aware study reported large variance between scanner verdicts across agent-skill marketplaces, and that is operationally awkward. One scanner may flag a skill, another may pass it, and neither result alone explains whether the skill is malicious, risky, incomplete, or merely unusual.

That does not mean audits are useless. It means audit results need context:

• Which exact files were scanned?
• Which commit, hash, or snapshot was scanned?
• Which scanner produced the result?
• What categories did it detect?
• Was the finding about prompt injection, credential handling, executable code, network egress, dependency risk, or source provenance?
• Has the skill changed since the audit?

Agent skills need a richer policy model than a single green check. A skill that includes shell scripts may be perfectly legitimate for deployment automation and unacceptable for documentation writing. A skill that reads .env files may be expected for a secrets-auditing workflow and dangerous for a generic code-review helper. A skill that fetches remote content may be harmless in a docs lookup workflow and risky if the fetched content is passed back into an agent with deployment permissions.

The same artifact can be safe or unsafe depending on where it runs, what tools sit beside it, and which permissions the agent has. The same argument applies one layer down, to the MCP servers a skill can route work through: VIPER-MCP confirmed 106 zero-days across 39,884 MCP server repositories, so “this tool is popular” is not a verdict either. Our MCP security guide covers that side.

What API Consumers Should Do

If you build on the skills.sh API, treat it like a dependency source, not a search box.

Store the whole record together. Keep the stable skill ID, source, install URL, content hash, audit result, and approval decision in one row. If the hash changes, require re-review. If the source changes, require re-review. If the audit provider moves from pass to warn or fail, stop automated install and surface a human decision.

Pin by content, not just by name. Names and repository paths are useful for discovery, but they are not enough for repeatable installs. The approved unit should be the exact skill file tree or a cryptographic hash of it.

Figure: The same registry record, consumed two ways. Only the hash-pinned path can tell that the bytes changed after the audit.

Separate recommendation from installation. It is fine for an agent or internal portal to suggest skills based on project context. Installing those skills into an agent with filesystem, shell, GitHub, cloud, Slack, or MCP access should still pass through policy.

Use audit data as one input. A pass from one provider is not a permanent trust grant. Combine scanner output with source reputation, publisher identity, content hash, install count, update recency, dependency review, and local permission boundaries.

Build allowlists for high-impact environments. Developer laptops, CI runners, production deployment agents, incident-response agents, and customer-data agents should not all draw from the same open catalog with the same install policy.

Log the full chain. When an agent loads a skill, record which catalog result led to it, which hash was installed, which audit record was consulted, which user or policy approved it, and which tool permissions were available in that session.

Where SkillSafe Fits

The skills.sh API validates the direction the whole ecosystem is moving: skills are becoming reusable agent infrastructure. That is good. Reusable skills let teams encode hard-won operational knowledge, framework-specific patterns, review checklists, deployment workflows, and incident procedures.

But reusable infrastructure needs verification.

SkillSafe’s approach is built around that boundary. A skill can be saved privately with low friction, but sharing requires a scan report. The registry stores the scan result and content hash. On install, the consumer re-scans and compares what arrived with what was reviewed. That dual-side verification model is designed for the exact problem programmable skill distribution creates: trust should attach to the artifact, not just the listing.

This is also why source and runtime permission context matter. A clean scan is not a reason to give every skill every tool. It is a reason to proceed to the next layer: least privilege, human approval for dangerous actions, runtime logging, drift detection, and re-review after changes.

Frequently Asked Questions

Is it safe to install skills from a public agent skill registry?

Not by default. Snyk’s February 2026 audit of 3,984 skills found 36.82% with at least one security flaw, 534 with a critical finding, and 76 carrying active malware. A registry listing is a discovery signal, not a verdict. Install from a pinned content hash, read the skill file, and scope the agent’s permissions before the first run.

What does npx skills add actually put on my machine?

It writes a skill’s files, usually a SKILL.md plus any scripts and reference files, into your agent’s skills directory, such as .claude/skills/. Those files become agent instructions the moment the agent loads them. Because most registries resolve a name to a Git repository, the bytes you get are whatever that repository serves at install time.

Does a security audit on a skill registry mean the skill is safe?

It means one scanner reviewed one snapshot. Audit verdicts vary between providers, and the skills.sh audit endpoint exposes results from five partners precisely because no single scanner is authoritative. Treat an audit as evidence tied to a specific content hash, and re-check whenever the hash, the source repository, or the publisher changes.

How do I detect when an installed skill changes after approval?

Store the SHA-256 of the approved file tree, then re-hash on every install and every scheduled sweep. A mismatch means the artifact is not the one that was reviewed, regardless of what the listing says. That comparison is the whole idea behind dual-side verification, and it is the only check that survives a repository changing hands.

Are agent skills a supply-chain risk like npm packages?

Yes, with one difference: a skill does not need executable code to be dangerous, because its text is instructions to an agent that already holds credentials. Treat skills, plugins, and MCP servers as one dependency class, and read the rest of our supply-chain coverage for the incident record.

If agents can install, retrieve, rank, or recommend skills automatically, then skill security has to be automatic too. Not invisible. Not optional. Automatic.