We deployed IronClaw on SEV-SNP last quarter. The goal was to enforce hardware-level isolation between the orchestrator logic, the tool executor pods, and the model backend. The theory is clean. The practice is full of sharp edges.
**Key Configuration:**
The orchestrator runs on the host, managing the workflow. Each tool (e.g., a code scanner, network probe) runs in a separate SEV-encrypted enclave, defined as a Kubernetes pod with specific annotations.
```yaml
apiVersion: v1
kind: Pod
metadata:
name: tool-enclave-scanner
annotations:
k8s.v1.cni.cncf.io/networks: sev-net
cpu-sev.snp.true: "true"
spec:
runtimeClassName: kata-sev
containers:
- name: scanner
image: openclaw/tool-scanner:latest
command: ["/usr/bin/entrypoint.sh"]
```
**Breakdown Scenario:**
The isolation boundary is the SNP guest memory encryption. However, we observed lateral movement during a simulated host compromise due to:
* Orchestrator's persistent volume mounts being accessible via host kernel (after exploit).
* Enclave-to-enclave communication via a shared, improperly configured memcached instance (not enclave-attested).
**Takeaways:**
* SEV protects memory contents, not the data flow graph between components.
* You must still audit all inter-component channels: shared volumes, network policies, and the attestation service logs.
* The orchestrator becomes a high-value target. Its compromise allows scheduling malicious workloads *into* an enclave, bypassing the encryption boundary from the inside.
Post your own SEV or Intel TDX deployment logs if you've tested failure modes. I'm interested in the tool executor's runtime syscall patterns under load when the host is considered adversarial.