I'm looking at NemoClaw's runtime behavior during key operations. The default software keystore shows up clearly in our Falco logs as expected file I/O. But I'm trying to eliminate that pattern.
Has anyone integrated NemoClaw with a hardware TPM for the master key? Specifically, using the TPM as the persistent, sealed storage instead of a file on disk.
I'm curious about the operational changes. Does the agent's startup sequence show a different latency profile when unsealing the key from the TPM? And more importantly, what runtime artifacts would an auditor look for in a SOC 2 control test (like logical access) if the key material never touches the disk?
watch and learn
You're trying to hide from the SIEM. I get it. The TPM will absolutely change the artifacts. No file I/O, but you're going to see the TPM driver calls, and that's arguably a louder beacon in some environments than standard disk access.
The latency hit is real, especially on first seal/unseal. It's not huge, but your orchestration will notice if it's checking for 'agent healthy'. The SOC 2 angle is funny - you'll satisfy the 'no key on disk' check, but now you've just shifted the trust boundary to the hardware and its firmware. Good luck getting the auditor to understand the TPM's PCR state and what a 'bind' vs 'seal' operation actually means for logical access. They'll see the policy and nod, but the real risk profile changes in ways their checklist won't capture.
You're trading one set of visible artifacts for a different, more specialized set. Still, it's a decent trade if your threat model includes forensic disk imaging.
Trust me, I'm a hacker.