Skip to main content
The enterprise question this answers: “can we keep the signing key in our own HSM / KMS / Vault, so AlgoVoi never holds it — without changing how the evidence verifies?” Yes. Key custody is pluggable, exactly like the storage backend. You pass a Signer; AlgoVoi calls it to sign each receipt and never touches the raw private key. And it is additive: the signed envelope is byte-for-byte the same shape regardless of where the key lives, so the free verifier, the conformance vectors, and your existing receipts all keep verifying with zero changes. Custody changes where the key sits, never the evidence format.
Included with Records Vault — BYO-key custody (HSM / KMS / Vault) ships in the bundle, no separate purchase. And the whole stack — engine, the KMS/HSM/Vault adapters, and every dependency — installs entirely from the AlgoVoi private index with no PyPI, so air-gapped deployments are first-class: one licence token, zero external network.

Custody modes

Most enterprises use KMS-wrapped: the Falcon-1024 key is stored encrypted by a key-encryption-key (KEK) that lives in your KMS/HSM and never leaves it. At sign time the key is unwrapped into memory, the receipt is signed, and the buffer is zeroized — the plaintext key is never persisted. This works with any provider right now because the KMS only performs a classical unwrap, not the post-quantum signing operation.

The interface

A Signer is four methods:
You hand a Signer to the archive, and it threads automatically through every Records Vault evidence stream (access log, timestamps, legal hold, and the rest):

Local custody (default)

KMS-wrapped custody

WrappedKeySigner holds only the wrapped key and an unwrap callable that asks your KMS/HSM/Vault to decrypt it. The KEK never leaves your provider.
To set up, wrap your Falcon private key once with your provider’s KEK and store the wrapped blob; the plaintext key never has to live on disk.

Encryption keys too

The same pattern covers the ML-KEM decryption key that protects your documents at rest. Encryption needs only the public key (no custody concern); decryption unwraps the secret key through your KMS, decapsulates, then zeroizes. WrappedKeyEncryptor is the encryption counterpart of WrappedKeySigner and produces the identical blob format, so archives stay interchangeable.
With both a WrappedKeySigner and a WrappedKeyEncryptor, the keys behind archive notarisation, document encryption/decryption, and every evidence-stream entry stay in your custody — AlgoVoi holds them only as the transient, zeroized in-memory unwrap at the moment of signing or decryption, never persisted in the clear.
Scope of wrapped custody. A Signer / Encryptor covers notarisation, document encryption/decryption, and the signing of every evidence-stream entry (timestamps, access log, legal hold, consent, custody, keyring, ACL, redaction). A few standalone ceremonies still take a key you supply directly rather than through the wrapped-custody path — the migration-manifest signature (RecordsVault.sign_manifest), key-rotation proofs, custodian counter-signatures, and recovery-share splitting — because each proves control of a specific key and accepts that key as input. For those steps, unwrap from your KMS/HSM in your own code at the point of use. Routing them through a Signer as well is on the roadmap.

Verification is unchanged

A receipt signed through any custody mode verifies identically — same algorithm, same envelope, same public key. Your auditors and counterparties use the same free verifier, and your key and its custody model are published in the Product Key Registry.

Availability

Bring-your-own-key custody is an Enterprise capability. The provider adapters (algovoi-doc-archive-kms, -vault, -pkcs11) are licensed packages that ship with Records Vault — available perpetual (one-time) or annual subscription from the suite store; local custody is built in. Talk to us about a pilot: [email protected].