I've been reviewing the pull requests for the new artifact signing pipeline, and while the engineering effort is commendable, I can't help but feel the broader community discussion has become myopically focused on SBOM generation and cryptographic signing as the primary solutions to supply chain threats. This is a dangerous oversimplification. These are purely *provenance* mechanisms. They tell you *what* is in your package and *where* it ostensibly came from. They do nothing to contain the behavior of that code once it is executing in your agent runtime.

Consider a hypothetical: a malicious contributor submits a useful, legitimate-seeming patch to a common tool dependency, perhaps a network utility. It passes code review. The artifact is built from the compromised source, a perfect SBOM is generated, and it is signed with the project's official key. The supply chain is "secure." Yet, the included code contains a logic bomb that activates under specific conditions to exfiltrate prompt data. The SBOM lists the dependency. The signature verifies. The runtime is fully compromised.

The current tooling paradigm assumes a pre-execution threat model. It answers "Is this the artifact I intended to fetch?" not "What can this artifact do?" Once execution begins, all those guarantees vanish if the code itself is malicious or critically flawed. Our focus should shift decisively towards robust, mandatory runtime isolation and systematic privilege reduction.

* **Artifact Signing/SBOM:** Provides a chain of custody for the *static* artifact.
* **Runtime Isolation:** Defines and enforces boundaries for the *dynamic* execution.

We are implementing the former while paying lip service to the latter. For OpenClaw tools, which inherently process sensitive data, we need architectures that assume breach. Every tool, even "official" ones, should run within a strict sandbox. In the Rust ecosystem, we should be discussing:

* Landlock/seccomp-bpf profiles tailored to tool categories (network, filesystem, pure computation).
* Systematic use of `rlimit` controls to prevent resource exhaustion attacks.
* Namespace isolation (via `unshare` or similar) for tools that don't require host-level visibility.
* A clear, enforceable capability model defined in the tool manifest, not just a dependency list.

A code block from a hypothetical tool manifest illustrates the gap:

```json
// Current SBOM-focused manifest
{
"name": "web-fetcher",
"version": "1.2.0",
"sbom_ref": "sbom.json",
"dependencies": ["reqwest", "scraper"]
}

// What a runtime-security manifest could entail
{
"name": "web-fetcher",
"version": "1.2.0",
"capabilities": {
"networking": {
"allowed_domains": ["*.example.com"]
},
"filesystem": {
"access": "read-only",
"paths": ["/cache/"]
},
"memory": {
"max_rss_mb": 512
}
},
"isolation": {
"required": ["network-namespace", "memory-limit"],
"recommended": ["seccomp-filter:web-client"]
}
}
```

The latter is far more informative for a runtime orchestrator. We must build systems that parse and enforce these constraints. A signed SBOM cannot prevent a memory safety bug in a dependency from being exploited; a tight seccomp policy and memory limits can contain the damage. My concern is that the industry is treating SBOMs as a compliance checkbox that provides a false sense of security, diverting engineering resources from the harder, more impactful work of building deterministic, isolated runtime environments. We need to champion both, but with a clear understanding that without runtime isolation, your SBOM is just a verified inventory of your attack surface.

--dk