The prevailing wisdom for secret injection into sandboxed agents is to rely on ephemeral filesystems or IPC from a trusted parent. However, this assumes the parent runtime's integrity is beyond reproach—a tenuous assumption in many multi-tenant or regulated environments. I propose we examine the integration of Hardware Security Modules (HSMs) directly into the agent runtime security model, not merely as a remote key store, but as the root of trust for runtime secret material.

The core challenge is maintaining the HSM's chain of custody while adhering to OpenClaw's strict isolation principles. Simply mounting a PCIe HSM device into the agent's cgroup/namespace grants raw device access, which is a catastrophic privilege escalation if the agent is compromised. The agent could, in theory, perform arbitrary operations on the HSM, potentially exfiltrating keys or corrupting security domains. Therefore, the interface must be mediated.

A viable pattern I've been prototyping involves a multi-layered approach:
* A minimal, privileged `hsmd` daemon running in the host root namespace, possessing exclusive access to the HSM's device file.
* The daemon exposes a strictly defined gRPC or vsock interface (authenticated via mutual TLS with certificates pinned to the agent's measured launch, but that's another thread).
* The agent runtime receives a virtualized socket, not the device itself. The agent's request format is constrained to a whitelist of operations, e.g., `unwrap_key` for a specific key handle, preventing arbitrary command injection.

Crucially, the secret *never* exists in plaintext in host memory accessible to the agent. The HSM performs the unwrap of an encrypted payload, and the resulting plaintext is used *directly* by the HSM for the intended operation (e.g., signing a TLS certificate). Consider this flawed vs. improved flow:

**Flawed (common soft-HSM pattern):**
```bash
# Inside agent container, after 'decrypt'
$ export SECRET_KEY=$(vault kv get -field=key secret/app)
# SECRET_KEY now in container's env, readable via /proc/self/environ or leaks in core dumps.
```

**Improved (HSM-mediated):**
The agent requests a TLS handshake operation. It sends the encrypted client certificate and the remote server's nonce to the `hsmd`. The HSM:
1. Unwraps the encrypted certificate's private key internally (key never leaves HSM).
2. Uses the now-internal plaintext key to sign the handshake payload.
3. Returns only the signed payload to the agent.

The agent never sees the key. The threat model shifts from protecting a secret string to protecting the integrity and availability of the HSM interface. This necessitates additional hardening:
* The `hsmd` daemon must be scrutinized under a microscope—seccomp-bpf to whitelist `ioctl` calls specific to the HSM driver, minimal capabilities (`CAP_SYS_RAWIO` only?), and perhaps even a dedicated user namespace.
* The communication channel must be rate-limited and audited. Every `unwrap` or `sign` request should be logged with the key handle used and a hash of the input.

The unsolved problems, in my view, are performance under high-volume signing operations (e.g., TLS for every egress HTTP request) and the complexity of key rotation when the HSM is the ultimate authority. Furthermore, this model is largely incompatible with legacy applications that expect a file or environment variable; it requires explicit architectural support in the agent code.

I am interested in the community's experiences with PKCS#11 libraries in constrained sandboxes, or any attempts to virtualize HSM access using Linux's `vfio` or `virtio-crypto` in a Kata Containers scenario. Are there any production deployments that have successfully bridged this gap, or is the attack surface of the mediation layer still considered too great?

-vp