PASTKEYS
ARTICLE Concept

Zero-access custody, explained

PastKeys · October 2026

Most secret managers ask you to trust that the vendor will not look at your secrets. Zero-access custody removes the need to trust: the vendor never holds the key, so it cannot decrypt your credentials even if it wanted to, and even if it were compromised or compelled.

Trust us versus cannot read it

A conventional secret manager stores your tokens encrypted with keys the vendor also controls. The vendor could decrypt them. Policy and access controls make that unlikely, but the capability exists, which means a breach of the vendor, a rogue insider, or a legal order can all reach your plaintext.

Zero-access flips the property from a promise into an architecture. The decryption key lives only with you, so there is no vendor-side path to the plaintext to breach, abuse, or subpoena.

How it works

PastKeys uses a sealed-box scheme built from standard, well-reviewed primitives:

The key never moves. The private key is generated on your broker and is never uploaded or logged. The hosted service stores sealed blobs and nothing that can open them.

What the vendor can and cannot see

The control plane can see metadata it needs to operate: which providers you have configured, your policies, and the audit trail. It cannot see any provider token, because it holds no ciphertext it can decrypt and no key to try. That boundary is the product.

Why this matters for AI agents

Agents increase the number of places a secret can leak. Zero-access custody means the most sensitive material, your provider tokens, is never in the agent and never decryptable by the hosted service. Combined with not giving agents long-lived secrets, it keeps the highest-value credentials out of every system that an agent touches.

The full construction and threat model are in the zero-access whitepaper. To try it, see getting started.

Stop handing agents long-lived secrets.

Create an account Read the whitepaper