Third-party skill installation in the sandbox — patterns, gotchas, and a question about approved skills

[masterworrall]

Context

We got a third-party OpenClaw skill (Solid Agent Storage — gives agents WebID identity and Pod storage) running inside a NemoClaw sandbox within hours of the GTC announcement. It works identically to vanilla OpenClaw once installed. But the installation path required some workarounds that might be useful to share, and raised a broader question.

What we found

No ClawHub CLI inside the sandbox

The clawhub CLI is not available inside the sandbox, and npm registry access is binary-restricted. Skills cannot be installed the normal way (clawhub install <skill>).

What worked: Build the skill on a development machine, then upload via openshell sandbox upload to /sandbox/.openclaw/workspace/skills/<skill-name>/. Register in openclaw.json under skills.entries as {"skill-name": {"enabled": true}}. Restart the gateway.

Static binaries for dependencies

No apt-get, no sudo inside the sandbox. If your skill depends on a system tool (ours needs jq), you need to upload a static binary manually and put it somewhere on PATH (we used /sandbox/bin/).

Network policy additions for external servers

The deny-all proxy means any skill that talks to an external service needs that domain added to the sandbox network policy. Our skill talks to a Solid server (crawlout.io) — we had to add it via openshell policy set. This is expected and makes sense for the security model.

We also found the default policy has clawhub.com instead of clawhub.ai (raised as issue #507) and that node needs to be in the per-binary allowlist alongside openclaw for skill-related domains, since OpenClaw skills run on Node.js.

skills.entries format

• Must be an object, not an array: {"skill-name": {"enabled": true}}
• No path key — OpenClaw discovers skills from the workspace directory automatically

The broader question

The sandbox is designed to be secure, and rightly so. Allowing arbitrary access to ClawHub from inside the sandbox would undermine that. But third-party skills are a big part of the OpenClaw ecosystem.

Is there a planned path for skill installation in the sandbox? For example:

• An NVIDIA-approved skill registry (curated subset of ClawHub)?
• A nemoclaw skill install command that verifies and uploads skills from outside the sandbox?
• A blueprint mechanism for declaring required skills that get pre-installed into the container image?

Would be interested to hear how the team envisions this working as the ecosystem grows.

---

Paul Worrall, Interition — Solid Agent Storage on ClawHub

[ljefford2-cmyk]

The workarounds you documented here are really useful — thanks for writing them up. The skill installation path question is the one I think has the most architectural implications.
Of the three options you proposed, a nemoclaw skill install command that verifies and uploads from outside the sandbox seems like the strongest near-term path — it preserves the sandbox's deny-all security posture while moving the trust decision to the operator. A curated registry helps but doesn't scale with the ecosystem, and baking skills into the container image works for known configurations but breaks down the moment someone needs something unanticipated (which is exactly what you ran into).
The deeper issue is that the current policy model is binary — allow or deny, with no middle ground for "this component has been verified but hasn't earned full autonomous access yet." What you're describing with the manual upload/register/restart cycle is essentially a manual trust escalation process. Formalizing that into something the sandbox understands natively would make third-party skills practical without compromising the security model.
I've been working on governance patterns that address this kind of graduated trust problem — filed as #442 if you're interested in the broader framing.

[masterworrall]

Thanks for the thoughtful response — and for pointing to #442. The graduated trust framing makes sense to us.

We agree the binary allow/deny model is the core limitation. The nemoclaw skill install path you described — operator-controlled verification outside the sandbox — is the pragmatic near-term answer. It's essentially what we ended up doing manually: fetch the skill, verify it, upload it, register it, restart. Formalising that into a CLI command would remove a lot of friction.

On the governance side: our focus is on standards-based approaches to inter-agent interoperability — identity, access control, and coordination across agent boundaries (W3C Solid Protocol). We don't have deep experience with runtime behavioural governance of the kind you're describing in #442. What we can say from running OpenClaw agents in production is that some form of runtime control is clearly needed — our API costs soared when agents had unconstrained autonomy, and that was just the cost dimension. We can imagine there are operational and safety dimensions we haven't hit yet that would make a WAL-type system valuable, but we don't have enough experience to speak to what those controls should look like in practice.

Appreciate the pointer to your reference architecture. We'll follow the conversation.

[ljefford2-cmyk]

Thanks — this is helpful context.The Solid Protocol work and what we’re describing with WAL aren’t overlapping concerns. Solid handles identity and access across agent boundaries — who talks to whom, with what credentials. WAL governs behavior within the boundary — what the agent is allowed to do once it has access, and how it earns more latitude. They’re complementary layers. The API cost experience you described is worth calling out. Unconstrained autonomy creating runaway costs is exactly the class of failure that graduated trust is designed to catch early. Cost is usually the first signal. Operational and safety dimensions tend to surface later, and they’re harder to unwind retroactively. Starting at WAL-0 (recommend only) means the system proves itself before it spends. Appreciate the honest framing on runtime governance. We’ll keep following the Solid work on your end.

[Balghanimi]

Great discussion — the graduated trust framing from @ljefford2-cmyk resonates strongly.
I'd like to add a perspective from control theory. The binary allow/deny model you're describing is essentially a relay controller — it has no memory of how the agent has been behaving, no sense of trajectory, and no proportional response. It works, but it's the crudest possible safety mechanism.
The API cost runaway that @masterworrall described is a perfect example. By the time a threshold triggers a block, the damage is already done. What you actually want is a system that can detect the agent drifting toward a violation boundary and intervene proportionally — throttle before you block, modify before you deny.
In the control systems world, this is a well-studied problem. Sliding Mode Control (SMC) does exactly this: it defines a surface that represents the boundary between safe and unsafe behavior, measures how far the system is from that surface, and applies corrections proportional to the deviation. The math guarantees convergence back to the safe region — it's not a heuristic, it's a formal proof.
The interesting challenge with NemoClaw is bridging continuous-time control math to discrete agent steps. An agent doesn't act in continuous time — it proposes discrete actions. So you need a normalization layer that maps the continuous sliding surface value to a discrete decision space (pass / modify / block).
I've been working on exactly this — a formal SMC-based safety filter designed for agent deployments. The theory is in review at a controls journal, and I have a working implementation. Would be happy to share more when the paper is public.
The broader point: the NemoClaw security model is excellent for infrastructure-level isolation (sandbox, network policy, binary allowlists). But behavioral safety — is the agent acting within acceptable bounds over time? — is a different layer that needs different math. The two are complementary, not competing.

[ljefford2-cmyk]

@Balghanimi Really appreciate this perspective. The relay controller analogy is a clean way to describe exactly what the architecture is trying to avoid.

The WAL model was designed to be graduated rather than binary — four levels, proportional demotion based on failure severity, and as of the v5.2 update this week, trust scores that decay over inactivity and weight recent performance more heavily than historical volume. So we're moving in the direction you're describing, but doing it with heuristics rather than formal math.

Your point about the gap between that and provable convergence is well taken. The normalization layer you describe — mapping continuous safety measurement to discrete agent decisions — is the piece I haven't solved. I'd be very interested in your paper when it's public.

The canonical architecture is at local-first-ai-orchestration — WAL governance is in Section 4 and the Execution Safety Layer (infrastructure-level isolation) is in Section 5, if you want to see how the two layers complement each other.

[Balghanimi]

@ljefford2-cmyk Thanks for the pointer to your architecture — I've bookmarked Sections 4-5 and will review the WAL governance model this week.

Quick update: the paper is now formally under review at IEEE Control Systems Letters (L-CSS). I'll share it as soon as the review process allows. The normalization layer — mapping continuous sliding surface values to discrete pass/modify/block decisions — is covered in detail there.

In the meantime, I think the natural integration point is clear: WAL provides the trust level framework (when to escalate/demote), SMC provides the formal math for proportional intervention within each level. Happy to discuss offline if that's useful.

[masterworrall]

oh cool — really interesting stuff both of you. the control theory angle and the trust decay model are things we haven't gone deep on. we're mostly focused on the interoperability and identity side — making sure agents from different platforms can actually identify each other, share data, and have enforceable access controls between them (we use W3C Solid for that). but what goes on inside the agent runtime is a different problem and clearly needs addressing. will keep an eye on this thread.