Vault overview

The vault is where every secret lives: a typed, envelope-encrypted store that holds passwords, keys, tokens, cards and more. It is the foundation the SSH broker draws on, and it is built on the same honest premise as the rest of VaultTerm — an audited access broker, not zero-knowledge.

How the vault protects secrets

Every record is sealed under envelope encryption: a per-record data key encrypts the secret, and that data key is itself wrapped by a higher key. Keys are never stored beside the data they protect.

• No plaintext at rest. A stored secret is always ciphertext on disk.
• Decryption in memory only. The server unseals a secret in memory for one specific authorized action — a reveal, a brokered injection — then discards it.
• Typed, not free-form. Secrets are stored against a type (see Secret types), so each field is structured rather than dumped into a single note.

This is a deliberate trade. A zero-knowledge store could not broker an SSH session or inject a credential just-in-time, because those need the plaintext at the moment of use. VaultTerm keeps the plaintext reachable for authorized use and makes every such use accountable.

Multi-vault organisation

Secrets are grouped into vaults, and an org can run more than one. Use separate vaults to mirror how your team is structured — for example a vault per environment, per project, or per sensitivity tier — so that sharing and access can be scoped at the vault boundary rather than secret by secret.

Sharing and roles

A secret can be shared at the level of the org or a team, and access is governed by a role hierarchy:

Role	Capabilities
OWNER	Full control, including deletion and re-sharing of the resource
ADMIN	Manage membership and shares; manage secrets
EDITOR	Create and edit secrets
VIEWER	Read and reveal secrets only

Roles cascade in order: OWNER > ADMIN > EDITOR > VIEWER. A higher role includes the capabilities of the roles below it. See Sharing and rotation for how shares are issued and revoked.

Revealing a secret

A reveal — exposing the plaintext of a stored secret — is the most sensitive action in the vault, so it is gated and recorded:

• Every reveal is audited. Each reveal lands in the tamper-evident audit trail with who, what and when.
• Step-up for social-login sessions. A session authenticated via social login must complete a step-up proof before a reveal is permitted; the standing session token is not enough on its own.
• Device-posture enforcement. A device-posture policy can block reveals from non-compliant devices, so a secret is not exposed to a machine that fails the org’s posture requirements.

Where to go next

• See the full catalogue of supported types in Secret types.
• Learn how shares and rotation work in Sharing and rotation.
• Keep your stored secrets strong with Credential health.