Security model

VaultTerm is an audited access broker — not zero-knowledge. We state that plainly because it is the honest description of what the server does, and because the choice shapes everything else about the design. The server decrypts a secret in memory only for a specific authorized, audited action, and that act is always recorded.

The model, stated plainly

• Envelope encryption throughout. Every record is sealed with its own data key, which is itself wrapped by a master key. Keys are never stored beside the data they protect.
• No plaintext at rest. Secrets are only ever decrypted in memory, for the duration of an authorized action, and then discarded.
• Decrypt only for an authorized action. There is no bulk decryption and no standing plaintext — decryption is tied to a specific, permitted operation.
• Everything on a tamper-evident trail. Reads, brokered sessions, and security events land in an append-only audit log backed by a checkpoint chain. See Audit logs.

A strict zero-knowledge design would make the server unable to do the things teams need — broker an SSH session, inject a credential just-in-time, scan command output for a leaked secret. Each of those requires the plaintext, in memory, at the moment of use. We chose the broker, and we made it accountable rather than pretending it is blind.

Multi-tenant isolation

Tenants are isolated at the database using Postgres row-level security. Every tenant table is scoped by org_id, derived from the authenticated context, and the policy is forced even for the table owner — there is no query path that quietly returns another tenant’s rows. See Tenant isolation.

Privacy-first AI

AI features default to staying on your own network. Terminal output and other sensitive material are processed locally by default; sending anything to a cloud model is redaction-gated — it passes through a redaction step first, and cloud egress is an explicit, controlled path rather than the default. The privacy model is described in AI privacy model.

Product-protection layer

For self-hosted deployments, VaultTerm adds protections that bind the software to where it is licensed to run:

• On-prem key binding. The master key’s unlock is derived from the host environment, a hardware root, and the license signature, so a licensed instance cannot simply be cloned to unlicensed hardware. See Cryptography.
• Honeytokens. Decoy credentials and tripwires detect tampering and unauthorized use; their state is surfaced to operators in the admin console.

Related pages

• Cryptography — envelope encryption, key providers, and post-quantum posture.
• Tenant isolation — the row-level-security model.
• Architecture overview — how the system is put together.