Zero-access security model

Most secret managers ask you to trust that the vendor will not look. PastKeys is designed so it cannot: provider tokens are sealed to a key that only your broker holds, and the control plane stores ciphertext with no key that opens it.

The guarantee

• Your broker generates its custody keypair. The private key never leaves your host.
• Tokens are sealed to the broker's public key before they are stored. We hold the public key, which can seal but never open.
• A breach of PastKeys, a rogue insider or a legal demand reaches only ciphertext.

Cryptography

Sealing is a hybrid key exchange (X25519 plus ML-KEM-768, NIST FIPS 203) whose two shared secrets are combined with HKDF-SHA256, followed by AES-256-GCM. Stored blobs stay confidential if either primitive holds, which defends against recording ciphertext today to break it with a future quantum computer. Audit records can be signed with Ed25519 by a key only the broker holds.

What we do see

To run the service the control plane holds your policies, agent IDs, the list of configured providers, broker public keys, issuer settings and audit records. None of these contain a credential.

Self-hosted and managed

Self-hosting keeps the guarantee absolute: the broker runs in your environment and we never hold your key. A managed broker is also available as an early pilot. PastKeys runs the broker, and its custody key is wrapped in a KMS and unwrapped only by an audited grant, so no usable key sits on disk. The promise is stated precisely: we run it, so the key is encrypted at rest and unwrapped only by that grant. That is weaker than self-hosting, where we never hold the key, and it uses the key in memory while the broker runs. Customer held keys, where the key stays in your own KMS and you revoke our access, are the next step. Customers who need the absolute guarantee keep running their own broker.

Every algorithm is listed in Cryptography. Read the full design in the whitepaper.