Are OpenClaw Skills Safe?

Short answer: the bundled skills are as trustworthy as OpenClaw itself; ClawHub skills come with a real automated audit whose result you can read before installing; and neither of those replaces reading the file. OpenClaw's own documentation is unusually direct about the last point:

Treat third-party skills as untrusted code. Read them before enabling. Prefer sandboxed runs for untrusted inputs and risky tools.

What makes this worth a page rather than a paragraph is that OpenClaw has more moving parts here than any other agent covered on this site — a registry with a published audit stack, path containment rules, an operator install policy, and one control that looks like a security boundary and explicitly isn't.

Why a skill is a security question at all

A skill is a document the agent reads and then acts on, plus optional files that may be executed. There's no sandbox between "the agent read this instruction" and "the agent did what it said." That makes the risk surface instruction-shaped rather than code-shaped: prompt injection, over-broad triggers, credentials requested for reasons that don't match the skill's job, a scripts/ directory doing something the SKILL.md never mentions.

ClawHub frames its own risk analysis around exactly this, using the OWASP Agentic Skills Top 10 as a lens for "prompt injection, tool misuse, credential exposure, unsafe execution, memory or context poisoning, and excessive agency." That list is a reasonable summary of what can go wrong.

What ClawHub checks before you install

ClawHub is open by default — "anyone can upload, but publishing requires a GitHub account old enough to pass the upload gate." That's a spam gate, not a review. The real screening is automated and its results are public on each listing, at /<owner>/skills/<slug>/security-audit.

The audit combines three things: SkillSpector, VirusTotal, and risk analysis.

Audit status and risk level are different questions

The distinction the documentation draws is the useful part, and it's routinely collapsed elsewhere:

Risk level asks: "How much power is here?" Audit status asks: "What should I do with this result?"

So a skill that publishes content on your behalf can legitimately sit at Review / Medium — the documentation gives exactly that example. It isn't a warning that something is wrong; it's a statement that the skill can act with real authority and you should decide whether you want that.

Findings are labelled Info through Critical. Low-confidence findings are hidden from the public rollup, which keeps the page readable and also means you're seeing a filtered view.

What the audit is actually looking at

Per the docs, ClawHub audits "skill instructions or plugin metadata, declared environment variables and permissions, install instructions and package metadata, included files and file manifests, compatibility and capability metadata."

The organising question is coherence — "do the name, summary, metadata, requested authority, and actual content line up with what users would reasonably expect?" And the framing is deliberately not capability-phobic: "Powerful behavior is not automatically bad… The audit checks whether that power is expected, disclosed, and proportionate."

VirusTotal is telemetry, not a verdict

ClawHub summarises vendor engine counts in plain language — "62/62 vendors flagged this skill as clean" — and is explicit about the limits: "VirusTotal remains telemetry. It does not replace ClawHub's own artifact-aware risk analysis."

That's the right framing to carry into your own reading. Antivirus engines are good at known-malicious binaries. A malicious skill is frequently just prose — a paragraph telling an agent to read a credential file and post it somewhere — and there is no engine signature for a convincing sentence.

Verifying from the command line

openclaw skills verify @owner/skill-name
openclaw skills verify @owner/skill-name --card

verify requests the skill's clawhub.skill.verify.v1 trust envelope and "exits non-zero when ClawHub marks verification as failed," which makes it usable in a script. Installed ClawHub skills verify against the version and registry recorded in .clawhub/origin.json.

Publishers can request a re-scan after a false positive with clawhub skill rescan @owner/<slug>.

The honest limit, stated by ClawHub itself

Audits are strong safety signals, but they are not a guarantee that a release is risk-free. Always use judgment before granting sensitive access.

What independent research found

In February 2026, Snyk published ToxicSkills, an audit of the agent-skills ecosystem. The figures are worth stating precisely, because the version circulating in secondary coverage is wrong in both halves.

The study scanned 3,984 skills from ClawHub and skills.sh, as of 5 February 2026, using the mcp-scan engine with eight custom security policies plus human review.

Secondary write-ups have compressed this into "prompt injection in 36%, 1,467 malicious payloads." Both numbers are misapplied: 36.82% is any-severity flaws, not prompt injection; 1,467 is that same any-severity count, not payloads. Confirmed malicious payloads numbered 76.

Read carefully, the study says something more useful than either version: the large number is a code-hygiene problem, the small number is the adversarial one, and prompt injection is overwhelmingly concentrated in the deliberately malicious tail rather than spread across the registry.

Other third-party reports exist with different populations, methods, and headline numbers. We're citing one study we could read in full rather than blending several into a single figure that belongs to none of them.

The controls OpenClaw gives you

Path containment

Workspace, project-agent, and extra-dir discovery "only accepts skill roots whose resolved realpath stays inside the configured root, unless skills.load.allowSymlinkTargets explicitly trusts a target root." Managed and personal roots may contain symlinked skill folders, but "every SKILL.md realpath must still stay inside its resolved skill directory."

In short: a skill can't escape its root via a symlink unless you've said it may. If you do use allowSymlinkTargets, note that Skill Workshop only writes through those trusted targets when skills.workshop.allowSymlinkTargetWrites is also enabled — two separate opt-ins.

Operator install policy

security.installPolicy runs "a trusted local policy command before skill installs continue." It applies across ClawHub, uploaded, Git, local, update, and dependency-installer paths, and "fails closed when the command cannot return a valid decision."

This is the control to reach for in a team or managed environment: a hook that can allow, warn, or block before anything lands on disk, and that errs toward blocking when it can't decide.

Secret injection is host-only

skills.entries.*.env and skills.entries.*.apiKey inject secrets "into the host process for that agent turn only — not into the sandbox," and the original environment is restored after the run.

Two consequences. Blast radius is bounded to a single agent turn rather than the process lifetime. And if you run agents sandboxed expecting the sandbox to receive those secrets, it won't — that's a functional gotcha as much as a security one.

Skill Workshop, for agent-authored skills

OpenClaw's agent can propose skills rather than write them. Skill Workshop is "a proposal queue between the agent and your active skill files" — proposals are drafted, then inspected, evaluated, and applied by you. If you're letting an agent evolve its own skill library, this is the gate that keeps a review step in the loop. See how to create an OpenClaw skill.

The control that is explicitly not a boundary

Agent allowlists (agents.defaults.skills, agents.entries.*.skills) restrict which skills an agent can see. It's tempting to read that as sandboxing. The documentation says otherwise, in terms worth quoting rather than summarising:

This is not a host shell authorization boundary. If the same agent can use exec, constrain that shell separately with sandboxing, OS-user isolation, exec deny/allowlists, and per-resource credentials.

An allowlist manages what the agent knows about. It does not manage what the agent can do. An agent with skills: [] and an unrestricted exec tool can still run anything a skill would have told it to run.

For actual containment, OpenClaw's broader security guidance points at sandbox modes and workspace access levels under agents.*.sandbox, tool deny lists, and openclaw security audit --deep to find agents whose tool policies are more permissive than intended.

One further detail that trips people up: requires.bins gating is checked on the host at load time. A sandboxed agent needs the binary inside the container too, or the skill will appear eligible and then fail.

A workable default

Nothing here is a recommendation we've tested; it's the conservative reading of the documented controls.

1. Prefer bundled skills, then ClawHub skills marked Official, then anything else.
2. Run openclaw skills verify before installing something you haven't read, and read the audit findings rather than just the status.
3. Read the SKILL.md in full, and every file in scripts/. This is the only step that catches a well-written malicious instruction.
4. Check that declared credentials and requires.env match what the skill plausibly needs to do its job.
5. Install into the workspace rather than --global until you trust it — narrower blast radius.
6. For anything untrusted, or anything processing untrusted input, run the agent sandboxed with a tool deny list. The allowlist is not that.
7. In a team, set security.installPolicy so the decision isn't made per-person.

Caveats

• We have not installed or run OpenClaw, submitted anything to ClawHub, or audited any skill. Everything about OpenClaw and ClawHub behavior here is documented behavior, quoted where precision matters.
• We have not evaluated SkillSpector, ClawScan, or the audit pipeline's accuracy. "Automated audit" is ClawHub's description of its own process.
• Snyk's figures describe a 5 February 2026 snapshot of ClawHub and skills.sh combined, using their methodology. They are not our findings and do not describe ClawHub alone.
• The OWASP Agentic Skills Top 10 is cited because ClawHub says it uses it as a lens; we have not reviewed the project's contents.
• Controls, config keys, and audit statuses are documented as of August 2026, and OpenClaw is under very active development.

Sources

• ClawHub — Security Audits (official docs) — audit status, risk level, findings, VirusTotal framing, ClawScan
• OpenClaw — Skills, Security section (official docs) — untrusted-code warning, path containment, install policy, secret injection scope, the allowlist caveat
• OpenClaw — ClawHub (official docs) — publishing gate, moderation, scan holds
• ClawHub — Security (official docs) — disclosure policy, and where to report third-party skill issues
• Snyk — ToxicSkills — independent scan of 3,984 skills, February 2026
• OWASP Agentic Skills Top 10 — the risk taxonomy ClawHub's risk analysis uses