Yes, let employees use public agent skills. Behind a gate. The gate is five steps: know where skills can load, vet each one against a written checklist, approve and pin specific versions, deploy with organization-level controls, and monitor for drift. That is the whole playbook, and the rest of this article is the evidence and the working details. It joins our Security and Governance topic, where the adjacent pieces on approval binding and audit logging live.
I run skills in my own agent setup every day, and I also read the security research on them every week. Both things are true at once: skills are a genuinely useful packaging format, and the public supply of them is an unreviewed attack surface. Your employees are already in that supply.
Why is this urgent now?
Agent skills, the SKILL.md format popularized by Anthropic, spread fast through 2026. Snyk measured daily skill submissions jumping from under 50 in mid-January 2026 to over 500 by early February, a 10x increase in weeks. Akamai’s threat researchers published a ten-category threat model for the skills layer in March 2026. An October 2025 arXiv study showed that skills enable a new class of realistic and, in the authors’ words, trivially simple prompt injections.
Enterprises are reacting in both directions at once. In October 2026, The Information reported that Meta and Microsoft were steering employees away from Claude toward in-house tools. That is the ban instinct, and it does not hold: blocking the official channel moves usage to personal accounts and unreviewed repos, where you lose visibility entirely. The same week, a sysadmin thread made the counterpoint plainly: your employees are already using these tools, so set the rules before something sensitive gets pasted in. A parallel r/cybersecurity discussion asked whether agent permission prompts are enough to protect developer machines. The consensus: they are not.
The demand signal is clear. People want a policy that permits, not a policy that pretends.
What is the actual risk of a public skill?
A skill is not code running in a sandbox. It is prose that goes straight into the reasoning of an agent that can already read your files, call your APIs, and run your shell, as Sprayberry Labs put it in their July 2026 supply-chain audit. Three properties make that dangerous in combination:
Skills inherit full agent authority. Akamai’s top-10 threats list catalogs the failure modes: indirect prompt injection through skill text, descriptions crafted to hijack skill selection, helper scripts executing unexpected code, and skills persisting changes through agent memory. Their post also documents the incident that made this concrete: the most downloaded skill on one open marketplace was malware designed to exfiltrate SSH keys, crypto wallets, and browser cookies, then open a reverse shell.
The ecosystem numbers are not comforting. Snyk’s ToxicSkills study scanned 3,984 skills from ClawHub and skills.sh as of February 5, 2026. 13.4% contained at least one critical-level security issue, and 36.82% (1,467 skills) had at least one flaw of any severity. The researchers confirmed 76 actively malicious payloads built for credential theft, backdoors, and data exfiltration. Eight of those were still publicly downloadable at publication.
The attack does not need a marketplace. Datadog Security Labs documented Clawsights in May 2026, a fake Claude Code leaderboard whose skill harvested the user’s GitHub token with gh auth token and curled it to an external endpoint. Their more important finding is structural: coding agents load skills from enterprise policy, personal directories, project .claude/skills/ folders, plugins, nested project folders, and added directories. A cloned repository can carry a skill into a trusted session without anyone installing anything. If that skill uses a dynamic context command, the shell command runs before the model ever sees the skill text, so model-level injection defenses never get a vote.
How bad is it really? We scanned 1,137 skills
Here is the counterweight, because the honest picture is not “everything is malware.” Sprayberry Labs scanned 2,019 skills from the official Claude Code marketplace plus nine community marketplaces, fetched at pinned commits, and found zero poisoned skills after human review of every flag. Their August 2026 update extended the work to 66,541 skills on ClawHub and then to a standing watch.
On November 1, 2026 I ran my own check, applying the risk indicators from Anthropic’s enterprise vetting checklist to 1,137 public skills: the 20 official Anthropic skills plus three community collections (15 from obra/superpowers, 185 from wshobson/agents, 917 from davila7/claude-code-templates, all at that day’s HEAD):
| Indicator (from Anthropic’s checklist) | Official (n=20) | Community (n=1,117) |
|---|---|---|
| Ships executable scripts | 55.0% | 19.0% |
| Live network-call code (curl, fetch, requests) | 10.0% | 18.5% |
| Credential or secret patterns | 20.0% | 27.9% |
| Sensitive filesystem paths (.ssh, .env, $HOME, /etc) | 10.0% | 15.8% |
| Instruction-override patterns | 5.0% | 0.5% |
Zero of the 1,137 were malicious. I read every instruction-override hit by hand: all seven matches (six community, one official) were benign, including a peanut-allergy skill that matched on “dan dan noodles” and two security-education skills quoting attack strings to teach defense. That is the second lesson Sprayberry’s audit also landed on: a scanner that cries wolf is useless, so pattern matches are leads for a human, never verdicts.
Read the table the right way. The risk is not that most skills are poisoned. It is that the capabilities which make skills useful, code execution, network access, credential handling, are exactly the capabilities an attacker needs, and one in five community skills ships them. Provenance matters more than prevalence: curated marketplaces scanned clean, while the open ClawHub registry is where Snyk and Akamai found live malware.
The five-step policy
What you will have at the end: a written allowlist of pinned, reviewed skills, a vetting checklist your team actually uses, and a monitoring loop that catches drift.
Prerequisites: admin access to your agent platform’s organization or managed settings, a list of the agent harnesses your teams run, and one person who owns the checklist and runs the scanner (a day of setup, then about an hour a week).
Step 1: Inventory where skills can load
You cannot govern what loads invisibly. Enumerate every load path before writing any rule. For Claude Code that means managed enterprise settings, each user’s personal skills directory, project .claude/skills/ directories including nested ones, plugin-provided skills, and .claude/skills/ inside any directory added for extra context. Datadog’s post walks each path. Do the same enumeration for every other agent in your fleet, because each harness has its own equivalent list. Expect the result to be a short document listing load paths, who controls each one, and which are currently unmonitored.
Step 2: Vet against a written risk checklist
Anthropic publishes a risk-tier checklist for enterprise skill review. It flags code execution, instruction manipulation, Model Context Protocol (MCP) server references, network access patterns, hardcoded credentials, and filesystem scope, and pairs them with an eight-step review process. Adopt it verbatim as your starting point. Two additions from the research above: treat skills fetched from open registries as higher-risk than curated marketplaces by default, and route every automated scan hit through a human who reads the actual text, because my scan and Sprayberry’s both show the false-positive rate will otherwise train your team to ignore the tool.
Step 3: Approve, pin, allowlist
Approval means a specific version, not a skill name. Sprayberry’s audit method is the model: fetch at a pinned commit and treat the result as a fact about those bytes, because a skill you vetted last week can be silently updated underneath you. Keep the allowlist small and reviewable: skill name, pinned version or commit hash, who approved it, when, and what it is allowed to touch. An employee who wants a new skill files a one-paragraph request against the checklist. If your process takes longer than a day, people will route around it.
Step 4: Deploy with organization controls
Three concrete controls, all from vendor documentation. Turn on Claude’s organization skill and plugin security scanning, which blocks skills that fail its checks for members of a Claude Enterprise organization, while remembering it does not cover skills uploaded through the Skills API. Set disableSkillShellExecution in managed settings so skill shell commands cannot run before the model sees the content, per Datadog’s recommendation. And scope the credentials: an agent running approved skills should hold the minimum tokens its tasks require, and a bad skill finds nothing worth taking. This is the same least-privilege discipline as permission-aware retrieval, applied to the agent’s own toolbox.
Step 5: Monitor, re-scan, revoke
Skills drift, marketplaces change, and yesterday’s clean pin is not evidence about today. Log which skills load in which sessions and review it on a schedule, the way you would review any other agent audit log. Re-run your scanner when a pin moves or a marketplace announces changes. When an employee leaves or a project ends, revoke the credentials the agent held, not just the person’s accounts. And test the binding between approval and execution the way you would test any human approval gate: if a skill can change after approval and still run, the approval no longer binds anything.
What goes wrong in practice
The scanner floods and people mute it. Pattern matching lights up on good documentation, because honest setup guides talk about the same tokens and paths attackers want. Sprayberry’s first pass flagged 19 of 29 healthy skills on one developer machine. Fix by severity tiering: block only on true instruction-override and exfiltration shapes, surface bare mentions as advisories.
Shadow installs bypass the allowlist. If your policy only watches the marketplace, it misses the project skill committed to a cloned repo. Require code review for .claude/ directory changes and monitor agent sessions for unexpected processes and network connections, as Datadog advises.
Approval becomes rubber-stamping. A one-click approve with no pinned version and no re-check degrades within weeks. Keep the request cost low, the checklist short, and the re-vet trigger automatic.
What to do next
Start with step 1 this week: write down where skills can load in your environment. Most teams find at least one path they did not know about. Then adopt Anthropic’s checklist as your vetting baseline and approve your first pinned allowlist. If you want a second pair of eyes on the risk model, Akamai’s ten threat categories translate directly into review questions.
Further reading
- Human-in-the-Loop AI Approval That Actually Binds: make the approval of a skill version mean something at execution time.
- AI Agent Audit Log: the monitoring layer for step 5, with tamper detection.
- MCP Server Architecture: the adjacent tool supply chain, where the same vetting discipline applies.
Sources and limits
The ecosystem statistics come from Snyk (3,984 skills, February 2026) and Sprayberry Labs (2,019 skills, July 2026, with an August 2026 update covering 66,541 ClawHub skills). Their corpora differ, so their headline numbers are not directly comparable. My own scan covered 1,137 skills from four public GitHub collections on November 1, 2026, using pattern indicators modeled on Anthropic’s checklist. It is a one-day sample of public collections, not a census of any marketplace, and every flagged instruction-override pattern was verified benign by hand. The Clawsights case and the skill load-path analysis are from Datadog Security Labs. The Meta and Microsoft policy moves are The Information’s reporting, not company statements.