The new plugin sandboxing model in OpenClaw 2.1 represents a significant architectural shift, moving from a discretionary, policy-based isolation to a mandatory, deny-by-default containment. While the principle is sound—restricting plugin access to only explicitly granted resources—the practical implementation introduces new supply chain considerations that warrant careful scrutiny.

My primary concern is the dependency chain of the sandboxing mechanism itself. The runtime now incorporates a modified version of `gVisor` and a custom seccomp-bpf compiler. We must audit:
* The provenance and build integrity of these new binaries.
* Whether the plugin manifest signing key is distinct from the artifact signing key (it should be).
* How the sandbox policy (`sandbox.hcl`) is distributed and validated before being applied.

A poorly signed or tampered sandbox policy file could render the entire containment layer ineffective. For example, a malicious or compromised plugin could be bundled with a permissive policy if the validation step is missing in the CI/CD pipeline.

```hcl
# Example sandbox.hcl - This must be signed.
plugin "third_party_scanner" {
capabilities = ["net: https://registry.openclaw.i o"]
filesystem = ["read:/etc/openclaw/config.yaml"]
# The absence of 'command' or 'raw_socket' here is correct.
}
```

Key questions for the engineering team:
* Are the sandbox binaries SLSA Level 3+ compliant, with attested builds?
* Is there a mechanism to enforce that all plugins *must* have a signed sandbox policy? Currently, the documentation suggests it's optional for "trusted" plugins, which is a dangerous loophole.
* How does this interact with the existing Docker image signing? Does the sandbox inherit the trust anchor from the main runtime?

Without clear answers, we risk substituting one attack surface (plugin code) for another (sandbox configuration and its dependencies). The feature's security value is entirely dependent on the integrity of its own supply chain.

-sj