A credential vault your secrets can't leak from
Envelope-encrypted storage, dual-control approval, and workload-scoped leasing for every provider credential your platform depends on — with no readback path, ever.
Envelope encryption
Every secret is sealed with its own Data Encryption Key, wrapped under a root key — nothing is ever stored in plaintext, and there is no readback endpoint anywhere in the API.
Dual control
Production credentials require a checker distinct from the maker who submitted them before they can activate — enforced in application code and reflected in every audit entry.
Append-only audit log
Every submit, test, approve, activate, lease, and revoke is recorded — actor, tenant, credential reference, version, result, reason — never the secret itself.
Team-based access
Applications are owned by teams, not a shared static token. Every developer signs in with their own account and every action is attributed to a real identity.
Workload-scoped leasing
The only endpoint that ever returns plaintext requires a narrowly-scoped, signed lease token bound to one exact tenant/provider/environment/credential-type combination.
Row-level security
Every tenant-owned table enforces Postgres row-level security, scoped per transaction — tested against a real non-superuser database role, not just assumed correct.
How it works
Sign up and create a team
Every application is owned by a team of one or more developers.
Register an application
Get a client secret, shown once — this is what your service authenticates with.
Submit, test, approve
Seal a secret, run a connectivity check, and get it activated under dual control.
Lease at runtime
Mint a workload-scoped token and read the secret only when your workload needs it.
Ready to store your first credential?
Sign up, create a team, and register an application — a client secret is all your service needs to start submitting credentials.