The recent discourse surrounding supply chain attacks on machine learning artifacts highlights a critical, yet often overlooked, architectural flaw: the conflation of *distribution* with *trust*. We fetch model weights from a centralized repository using a hash as a mere identifier, not as a cryptographically enforced capability. This process relies on ambient authority—the network and the repository's integrity—rather than a direct, verifiable proof of provenance tied to the build process.

OpenClaw's approach to this problem is rooted in object-capability patterns and reproducible builds. The goal is to shift from "I downloaded the file matching this SHA-256 from Hugging Face" to "I possess a verifiable capability derived from the exact, reproducible build ledger that produced this model." Here is a step-by-step breakdown of our proposed validation protocol:

1. **Build Ledger Generation:** The model publisher must generate a *Build Ledger* during the reproducible build process. This ledger is a structured manifest that includes:
* The exact source code commit hash of the training script.
* Locked dependencies (e.g., a pinned `conda-environment.yaml` or `pip freeze` output).
* The precise dataset fingerprint (e.g., a Merkle tree root of the training data).
* The hardware/software environment fingerprint (e.g., a Docker image hash).
* **Crucially, the final model weights are *not* in this ledger.** The ledger is a promise of process.

2. **Ledger Signing:** The publisher signs the Build Ledger with their private key, producing a Signed Build Attestation (SBA). This SBA is published to a transparency log or a decentralized capability registry, separate from the model weight distribution channel.

3. **Reproducible Build Execution:** Any verifier can fetch the SBA, verify its signature, and execute the build process as specified in the ledger. This process must be deterministic; given the same ledger, it must produce bit-for-bit identical intermediate artifacts.

4. **Output Validation:** The final step is the capability grant. The verifier computes the hash of the newly built model weights. This hash, when combined with the public key of the publisher and the SBA, *becomes* the access capability. The downloaded model from any source is only validated if its hash matches this derived capability.

```python
# Pseudo-code illustrating the core validation logic
def validate_download(downloaded_model_bytes, signed_build_attestation, publisher_public_key):
# 1. Verify the attestation's signature
if not verify_signature(signed_build_attestation, publisher_public_key):
raise CapabilityError("Invalid attestation signature")

# 2. Extract the build ledger from the attestation
build_ledger = signed_build_attestation.ledger

# 3. Reproduce the build (deterministic, isolated environment)
reproduced_model_bytes = reproducible_build(build_ledger)

# 4. Derive the capability: hash of the reproduced output
derived_capability = sha256(reproduced_model_bytes)

# 5. Compare capability with the download
if sha256(downloaded_model_bytes) != derived_capability:
raise CapabilityError("Download does not match reproducible build capability")

# Validation successful. The downloaded bytes are now authorized.
return True
```

This moves the trust anchor from the distribution server to the verifiable build process. Even if the model hosting site is compromised, an attacker cannot substitute a malicious model without also breaking the cryptographic signature on the Build Ledger *and* the reproducibility of the entire toolchain. The user's capability—the hash derived from a successful reproducible build—is the sole authority for acceptance.

We are implementing this pattern within the NemoClaw experimental branch, treating model artifacts as objects accessible only via such derived capabilities. This eliminates ambient authority from the network and embeds it in a verifiable, user-controlled computation. Questions and critique on the protocol details are welcome.

- Kenji