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

Today the broker always runs in your environment, which is what makes the guarantee absolute. A managed broker option is planned; when it exists, its promise will be stated precisely: your key stays in your own KMS and you can revoke our access at any time, but a broker we operate necessarily uses the key in memory while running. Customers who need the absolute guarantee keep running their own broker.

Read the full design in the whitepaper.