How we hold
your credentials.
A privileged account password is the most dangerous thing you can hand a vendor. This is what we do with it — and what we refuse to do.
Your credentials are never stored in a readable form, never share a key with another customer, and are never handed to anyone who has not just proved who they are.
The life of one password
The clearest way to explain a vault is to follow a single credential through it, from the moment it is written to the moment someone reads it back.
Its own key, and a root key we cannot extract
Every credential is sealed with its own encryption key — not one key per customer, and not one key for the platform. That key is itself sealed by a root key held in a hardware security module, which cannot be exported, copied, or read by us. It can only be asked to perform an operation, and every request is logged by the platform that holds it. A stolen copy of the database is inert: no passwords, and no key that opens one.
Your ciphertext is bound to you, mathematically
Each sealed credential is cryptographically bound to the organization it belongs to. This is not a filter in a query that a bug could omit — the binding is part of the encryption itself. A credential belonging to one customer, presented under another customer's identity, will not decrypt. Our release checks include an attempt to open one organization's data as another, and that attempt is required to fail.
Access is granted per account, not per tenant
Membership of your organization does not grant access to its credentials. Authority is assigned per privileged account — this person may rotate that one, this person may read this one. The same separation applies to administration: managing the module and reading the secrets inside it are different authorities, so an administrator cannot quietly grant themselves a password.
A second factor, at the moment of the request
Revealing a credential requires proof of identity at that moment — not proof from whenever the browser session began. A stolen session is the realistic way a vault is emptied, and a session alone is not enough here. Repeated incorrect attempts stop the process rather than slowing it, and the block is confined to credential access so it never locks anyone out of the wider product.
A single-use grant with a short life
A request does not return a password. It returns a one-time authorization that is short-lived, usable exactly once, and scoped to a single credential. Permission is checked again when it is redeemed, not only when it is issued, so access revoked in the interval takes effect immediately — and the credential is never written to our caches or persisted by the application that displays it.
Every reveal has a name against it
Each access is recorded with who, which credential, when, and by what route — and the reason they gave, captured before the credential is released rather than reconstructed afterwards. Superseded passwords are retained under the same encryption as current ones, so an investigation is not limited to the present.
What we refuse to do
Some design decisions are best described by what they rule out. Each of these was available, easier, and declined.
Store anything reversible
No credential is held in plaintext at any layer or any point — not in a cache, not in a queue, not in a log line while awaiting processing.
Share a key between customers
There is no shared secret whose compromise would reach more than one organization's data, and no environment default that could quietly become one.
Return a secret you sent us
Integration credentials you configure are write-only. The interface reports whether one is present; it will not read one back, to you or to anyone.
Let a caller widen their own limits
Safety defaults are set by the server. A client may request a stricter constraint; it can never request a looser one.
Infer something this important
How credentials are protected is declared explicitly per environment. Absent configuration stops the service starting — it never resolves to a weaker default.
Accept an unexplained request
A reveal carries a stated reason before it is granted. An audit trail with an empty reason column answers the wrong question.
Why this page has no numbers in it
You will notice we describe how the controls behave without publishing the values behind them — no timeouts, no thresholds, no key identifiers, no internal names.
That is deliberate. Those specifics do nothing for your evaluation and a great deal for someone building against us: an exact expiry window is a window to race, and a published lockout threshold is a budget to stay beneath. Publishing them would be a small marketing gain paid for out of your security.
Your security team can have all of it. Control descriptions, key management design, our testing evidence and independent assessment results are shared in full under NDA, and we will walk your reviewers through the architecture directly.