The current verification process for IronClaw enclave images, as outlined in the documentation, relies heavily on signed attestations from the build pipeline. While cryptographically sound, this model presents a significant visibility gap: it assumes the integrity of the entire CI/CD toolchain itself. A compromised build runner or a poisoned dependency will still produce a perfectly valid signature, making the enclave image itself the primary artifact of a successful attack.

Therefore, a robust verification strategy must extend beyond the final signature check. I propose a multi-layered approach focusing on provenance and behavioral baselines.

**Key Verification Layers:**

* **Provenance & SLSA:** Demand full SLSA Level 3+ provenance from the image provider. This should be machine-verifiable and detail:
* The complete build process identity (e.g., GitHub Actions workflow path, Cloud Build ID).
* All source repository commits and tags used.
* A cryptographically verifiable link to the specific runner environment that performed the build.

* **Software Bill of Materials (SBOM):** The image must be accompanied by a signed, attested SBOM (SPDX or CycloneDX format). Verification requires:
* Cross-referencing component hashes against vulnerability databases.
* Ensuring no components from unauthorized or unexpected repositories are present.

* **Pre-Launch Telemetry Baseline:** Before deploying a new image version in production, it should be launched in an isolated, instrumented sandbox. Collect a baseline of its low-level behavior:
* System calls (`strace`/`sysdig` capture).
* Network connection attempts (e.g., via `eBPF` hooks).
* Unexpected filesystem activity.

A practical verification step can involve using `cosign` and `in-toto` attestations. For example, after pulling an image `myregistry.io/enclave:v1.2`, you would verify its signature and all attached attestations:

```bash
cosign verify myregistry.io/enclave:v1.2
--key cosign.pub
--certificate-identity-regexp '^ https://github.com/OpenClaw/. *'
--certificate-oidc-issuer https://token.actions.githubusercontent.com

cosign verify-attestation myregistry.io/enclave:v1.2
--key cosign.pub
--type slsaprovenance
```

The critical next step is to correlate the data from these layers. Does the behavior observed in the sandbox align with the components declared in the SBOM? Do the system calls match the expected activity for a service built from the attested source code?

Without this correlation, we are only verifying the paperwork, not the actual runtime security of the enclave. What methodologies are others using to establish and compare these behavioral baselines? Are there existing Grafana dashboards or Prometheus rules for detecting drift between an enclave's attested profile and its observed activity?