What zero-knowledge backup means for an AI agent
Understand the keys, metadata, limits, and recovery tradeoffs behind zero-knowledge backup for stateful AI agents.
“Encrypted” can describe very different systems. A service may encrypt data in transit, encrypt disks it controls, or store ciphertext that it cannot decrypt. Only the last model is zero-knowledge in the practical sense relevant to an AI agent backup.
That distinction matters because an agent’s state can include personal memory, conversation history, working preferences, scheduled automations, configuration, and credentials. A backup provider should not need access to any of it.
The key boundary
In a zero-knowledge design, encryption happens before upload. The private decryption key is created and retained on the user’s machine. The storage service receives an opaque ciphertext object and enough metadata to operate the service.
HermesBackup uses an asymmetric age key pair. The public key encrypts scheduled backups; it cannot decrypt them. The private key is used only for restore. That is stronger than putting a passphrase into a cron configuration, where the scheduled job and any attacker who reads the file receive the ability to decrypt historical backups.
What the service can still see
Zero-knowledge does not mean zero metadata. A functioning storage service can see an account identifier, device identifiers, encrypted object sizes, ciphertext digests, user-provided labels, and timestamps. Infrastructure providers may retain request-level operational logs according to their policies.
Honest security documentation should list this metadata directly. It should also say what is not collected: plaintext archives, private keys, and passphrases.
What zero-knowledge does not solve
- A compromised endpoint: malware that can read the local private key or plaintext agent state may bypass cloud encryption.
- Key loss: the provider cannot recover a key it never held.
- Bad snapshots: encrypting an inconsistent database preserves the inconsistency perfectly.
- Untested restores: ciphertext durability is not proof that an application can import the decrypted archive.
How integrity checks fit
Encryption protects confidentiality. A digest protects integrity by detecting changed bytes. HermesBackup calculates a SHA-256 digest of ciphertext on the client, checks object size at completion, and verifies the digest again during restore before decryption and import. Smaller objects can also be stream-verified by the Worker; very large objects avoid that server-side CPU path and remain end-to-end verified by the client.
The recovery-key tradeoff
There is no support override in a genuine zero-knowledge design. If you lose the protected machine and every saved copy of the private key, the backups become permanently unreadable. That is not a bug hidden in the terms; it is the consequence of preventing the provider from decrypting customer data.
Store the recovery kit in a password manager or another secure off-machine location. A restore drill should confirm both that the key is available and that it decrypts a current archive.
Frequently asked questions
Can HermesBackup decrypt my backups?
No. The private age identity is generated locally and never uploaded. The service stores ciphertext and operational metadata.
Does zero-knowledge hide all metadata?
No. The service can see ciphertext sizes, digests, labels, timestamps, account and device identifiers, and request-level operational data.
Can support recover a lost private key?
No. A private key that was never uploaded cannot be recovered by the service. Save the recovery kit off-machine.
Does encryption prove the backup is restorable?
No. Integrity checks and clean restore drills are still required to prove the encrypted archive can recover the agent.