Skip to content
Ironheights
GuideIronheights

A 10-minute checklist for vetting an OpenClaw skill

Most malicious OpenClaw skills reported in 2026 could have been stopped by a person reading the right part of the file for two minutes. The trouble is knowing which part, and doing it every time, including on a busy day. This is the routine we use: four steps, about ten minutes, written so that a teammate or a client can follow it and leave a record. It does not make a skill safe. It makes the common attacks visible before your agent reads them.

Why ten minutes is worth it

A skill is not a plugin with a narrow API. It is text that your agent treats as instructions, and it inherits whatever the agent can reach: the shell, your files, your email, your keys. Public research shows the marketplace is a real target. Snyk scanned 3,984 skills and confirmed 76 malicious payloads by hand, and found 534 skills (13.4%) with at least one critical issue. Koi reported 341 malicious skills in one audit of ClawHub.

Ten minutes is a small cost next to rotating every credential your agent could read. It also scales: once the routine is a habit, most skills take less time, and the ones that take longer are the ones that deserved it.

Step 1: where it comes from (2 minutes)

Start with the listing, before you open the skill.

  • Find it on its official listing. Use ClawHub or the publisher's own repository, not a link from a chat, a forum post, or a lookalike site. Several campaigns sent people to websites that imitated OpenClaw branding.
  • Check the name letter by letter. Impostor "official CLI" skills and near-miss names are a documented trick. Koi's ClawHavoc report lists ClawHub lookalikes among the lures.
  • Look at the publisher. A brand-new account, or one that publishes dozens of near-identical skills, is a red flag. Bitdefender tied 199 skills to a single publisher.
  • Read the marketplace scan status. ClawHub scans every published skill with VirusTotal and shows the result on the skill page. A warning means stop. A clean result is one data point, not proof of safety: OpenClaw's own maintainers call the integration "not a silver bullet."

Step 2: read the SKILL.md (4 minutes)

This is the step that catches the most. Open the raw file, not the rendered page, and read in this order.

  1. The setup or prerequisites section. Any step that downloads and runs a script, binary, or archive before the skill works is the most common malware pattern in public reports. We took it apart in How malicious skills trick agents.
  2. Every command. Look for remote content piped into a shell, evaluation of fetched text, and encoded strings that get decoded and run. You should be able to read each command in plain text.
  3. Every link. Paste sites, URL shorteners, raw IP addresses and password-protected archives are reasons to stop. Ask whether each host fits the skill's stated job.
  4. Instruction overrides. Phrases that tell the agent to ignore earlier rules, to hide something from the user, or to turn off confirmations are a stop. So is any instruction to edit other skills or agent files.
  5. Hidden content. In the raw file, look for zero-width characters, HTML comments, long encoded blobs, and unusually long runs of padding. A README of several megabytes in a small skill is suspicious on its own: JFrog documented a dropper hidden in a README padded to about 22 MB.

Step 3: what it can reach (2 minutes)

Now compare what the skill asks for with what it claims to do.

  • Credentials. Reads of ~/.ssh, ~/.aws, .env files, browser profiles, or wallet files need a clear reason. Most skills need none. A weather skill that reads the bot's .env file is a documented case in our tracker.
  • Network. Every host the skill talks to should be named and should fit its purpose. A webhook or request-catcher host that nothing explains is an exfiltration channel.
  • Persistence and privilege. Watch for scheduler edits, shell startup files, login items, sudo, and world-writable permissions. A productivity skill has no reason to run at login.
  • Bundled files. Binaries and archives you cannot read are files you cannot vet. If a skill ships an executable, ask why it is not built from source you can see.

If the answers do not fit the job, stop there. You do not need to prove a skill is malicious to decide not to install it.

Step 4: scan and record (2 minutes)

A scanner does not replace reading, but it reads the parts you might skim, including every file in the folder, and it never gets tired. Ironheights reads the files as data and runs nothing:

npx ironheights scan ./path/to/skill

The result is no-findings, review, or block, with a rule id, file, line and evidence for each finding. Each rule has a plain-language page, for example IH-EXEC-001 for remote content piped into an interpreter or IH-CRED-001 for access to a sensitive path. If you would rather not install anything, the browser scanner runs the same content rules in your browser.

Read every finding. A review can be a false positive, such as documentation that mentions sudo, and a no-findings result means the rules did not match, not that the skill is safe.

After you install, record a baseline so you can tell later whether the skill or your agent files changed:

npx ironheights baseline create
npx ironheights verify

Finally, write one line: which skill, which version, who approved it, and why. It takes thirty seconds, and it is the first thing a client or a teammate will ask for after an incident.

Use the interactive version

We built the same routine into a free skill safety checklist. It runs in your browser, keeps progress only in your browser's storage, adds an eight-question risk quiz, and exports a summary you can attach to a ticket or send to a client. Nothing you type is sent anywhere.

What this checklist cannot do

Be clear about the limits, because a checklist can create false confidence.

  • It cannot see what is not in the files. When the dangerous command lives on a linked website or a paste site, you and the scanner only see the link. That is why every unexplained link is a stop.
  • It cannot predict runtime behavior. A skill that fetches new instructions from a remote server on every use can change after you vetted it. Unit 42 documented a financial-advice skill that did exactly this to rotate affiliate links.
  • It cannot catch instructions that look legitimate. A skill that tells the agent to move funds, as in one reported Solana scheme, needs no code, download, or credential path. No current Ironheights rule covers it.
  • It is a point-in-time check. Skills update. Re-vet on every update, and use verify to notice changes you did not make.

Our limitations page lists what Ironheights cannot detect, and the benchmark explains what our own test numbers do and do not mean.

FAQ

How long does it take to vet an OpenClaw skill?

About ten minutes for a typical skill: two for the listing, four for reading SKILL.md, two for what it can reach, and two to scan and record. Skills with many files or bundled binaries take longer, and that extra time is usually warranted.

Is a clean scanner result enough to install a skill?

No. A clean result means no rule matched. Read the setup section and every link yourself, because the most common attacks put the dangerous step on an outside website the scanner does not fetch.

Sources

Scan the next skill before your agent reads it

Ironheights is a free, open-source, local-first scanner and integrity monitor for OpenClaw skills. The CLI has no telemetry, and a scan makes no network calls. It reports what its rules match; it cannot prove a skill is safe.

Get Ironheights