The documentation talks about encrypting guardrail logs at rest, which is table stakes. But their key management section is hand-wavy. In a self-hosted deployment, you're now responsible for the lifecycle of those keys. Doing this wrong means either your logs are useless for incident response (because you lost the key) or they become a liability (because a breach exposes years of unrotated sensitive prompts and responses).

So, what's the actual risk? The logs contain the full prompt/response pairs that triggered guardrails. If encrypted with a static key, a disk compromise gives an attacker everything if they also get the key from your config. Static keys also mean you can't ever revoke access to old logs without re-encrypting everything—which nobody does.

A practical approach needs:
* Separation of duties: The app server that writes logs should not hold the master key.
* Automated rotation without service interruption.
* The ability to decrypt old logs for audits, without keeping all old keys active in your primary config.

My current thinking leans towards a KMS, but that's heavy for some deployments. Alternatives I've evaluated:
* Use a key-encryption-key (KEK) pattern. A local KEK encrypts data keys (DEKs) that are rotated monthly. The KEK is stored offline.
* Use HashiCorp Vault's transit engine or AWS KMS (if cloud-bound) for envelope encryption. The app gets a data key for each batch, uses it, and discards it.
* For bare-metal, a simple cron job that generates a new DEK, re-encrypts the KEK-wrapped old DEK, and stores the new wrapped DEK in a known location. The hard part is the re-encryption of existing logs—often it's better to just start using the new key for new logs and archive old logs under their old key.

The real question is whether NemoClaw's logging library even supports on-the-fly key rotation, or if you need to wrap the entire logging layer yourself.

What are others doing? Specifically:
* How are you injecting the current key into the deployment (env var, mounted file, KMS client sidecar)?
* What's your rotation schedule tied to? Time? Volume of logs?
* How do you handle decrypting logs for analysis when they're encrypted with different historical keys?