OpenClaw Starts Treating Skill Installs Like a Supply-Chain Artifact, Not a Blind Download

OpenClaw’s latest ClawHub change is the kind of security work that looks unimpressive until the first incident report lands. PR #93283, merged on June 15, does not block malicious skills, solve marketplace trust, or magically make third-party agent extensions safe. It does something more foundational: it records what was installed, what file ended up on disk, and what the registry believed about that artifact at install time.

That sounds like bookkeeping. In an agent platform, bookkeeping is a control surface.

The PR adds durable local provenance metadata for ClawHub skill installs by writing richer data into .clawhub/lock.json. OpenClaw now stores the downloaded artifact’s kind, sha256, and integrity, plus the installed SKILL.md path and SHA256. It also snapshots the ClawHub verification envelope — fields including decision, reasons, card, artifact, provenance, security, and signature. The patch is modest by line count: 295 additions and 12 deletions across src/skills/lifecycle/clawhub.ts and its tests. The implication is not modest.

Agent skills are not normal plugins

A browser extension can be dangerous. A CI plugin can be dangerous. But an OpenClaw skill sits in a uniquely sensitive place: inside the loop where the agent receives prompts, chooses tools, observes results, stops, compacts context, and carries memory forward. The linked issue, #92077, calls this out directly: ClawHub listings and API responses did not expose source code URLs even though skills can execute arbitrary shell through hooks such as UserPromptSubmit, PreToolUse, Stop, and PreCompact.

That is not “theme marketplace” risk. That is supply-chain risk attached to the agent’s nervous system. A compromised skill does not need to wait for a user to click the wrong button; it can live beside the automation path, see what the agent is being asked, influence what tools run, and potentially persist across sessions. If the agent touches local files, credentials, Slack messages, GitHub repos, or customer workflows, a skill install becomes part of the trust boundary.

This is why the distinction OpenClaw is starting to draw matters. Registry metadata, artifact identity, and runtime trust are three separate things. Registry metadata is what ClawHub says about a skill. Artifact identity is the concrete package the user downloaded. Runtime trust is the decision to let that installed code participate in the agent loop. Mature ecosystems treat those as separate layers because they fail in different ways. A registry can be stale. An artifact can be replaced. A verification service can change its mind. A local file can be edited after install.

Before this PR, OpenClaw had less local evidence to connect those layers. After it, an operator has a receipt.

The suspicious proof case is the point

The most interesting detail in the PR proof is not a happy green check. The live install proof used openclaw-find-skills from ClawHub and recorded an artifact hash of 9fb2b8e43f8301560f50a4484742c51e2d02be1f6a437f4d51e345f970addaca plus a SKILL.md hash of 6895c10c93ec17ca64b2b06ff15cbfa4278e7a011cb9464d9fc4b90a029af71b. The verification snapshot returned decision: "fail", reasons: ["security.status_not_clean"], provenance source: "unavailable", and securityStatus: "suspicious".

Good. Not good that the skill was suspicious; good that the suspicious state was captured. Failed verification should not evaporate into terminal scrollback. It should become local deployment evidence.

That is the audit primitive many agent platforms are missing. When something goes wrong six weeks later — a suspicious tool invocation, a leaked token, a strange compaction artifact, a user prompt quietly rewritten — the first question should be boring: what code was installed, from where, with what verification state, and has the local file changed since? Without hashes and recorded verification results, the answer becomes a mix of logs, memory, and hope. Hope is not an incident-response strategy.

There is also a subtle product decision here. The PR deliberately keeps install telemetry “backward-shaped”: richer local audit data is not sent back to ClawHub telemetry. That is the right default. Operators need more local evidence without automatically increasing registry-side data collection. Security metadata is useful, but it can also reveal internal deployment patterns. Local-first audit receipts preserve the operator’s ability to investigate without turning every install into a reporting event.

A lockfile is not a policy

The limitation is important: PR #93283 records provenance; it does not enforce a complete provenance policy. It does not require source URLs. It does not provide pinned install syntax. It does not ship a full audit command. It does not freeze installs against later registry drift. It does not sandbox skills by default. Those are still the harder follow-up pieces.

But this is the right order. You cannot build policy on top of facts you never stored. A future clawhub audit command needs artifact hashes. A frozen-install mode needs lock metadata. A “fail closed on suspicious verification” setting needs durable verification decisions. A source-provenance requirement needs a place to compare claimed source, published artifact, installed file, and current file. The lockfile is not the procurement policy; it is the receipt cabinet.

For practitioners, the immediate move is straightforward: if you run OpenClaw with ClawHub skills, inspect .clawhub/lock.json after installs and upgrades. Treat missing hashes, failed verification snapshots, and unavailable source provenance as deployment signals. They may not all mean “uninstall immediately,” but they absolutely mean “do not pretend this is invisible metadata.” If a skill participates in prompt submission or tool execution, its provenance belongs in the same review conversation as model access, OAuth scopes, and shell permissions.

For platform builders, copy the shape. Every agent marketplace needs to leave behind enough local evidence to answer four questions: what did we install, what did the registry claim, what exact file is active, and what verification state existed at the moment of install? If your platform cannot answer those without querying a live service, it does not have an audit trail. It has a dependency on someone else’s memory.

OpenClaw still has work to do before ClawHub feels like a fully governed supply chain. Source binding, signed artifacts, stricter install modes, sandbox defaults, and operator-friendly audit tooling are the next bar. But PR #93283 is the correct primitive. Agent skill marketplaces are not folders of helpful markdown. They are code distribution systems wired into autonomous workflows. Recording the receipt is not glamorous. It is how grown-up software starts.

Sources: OpenClaw PR #93283, OpenClaw issue #92077, ClawHub, SLSA / OpenSSF provenance background