Core concepts

This page defines the terms used throughout the rest of the documentation. If a word in another page is unfamiliar, it is almost certainly defined here. New to VaultTerm? Read What is VaultTerm first, then come back.

Storage and encryption

Vault

A vault is a container for secrets, scoped to an organization. It is the unit you create, name, and grant access to. A user or team is given access to a vault, not to individual records inside it, unless a record is shared on its own. See Vault overview.

Secret / item

A secret (also called an item) is one stored record — a login, an SSH key, an API key, an env file, a TOTP seed, a payment card, a secure note. Every secret has a type, and the type determines its fields, how it is rendered, and how it can be used (for example, an SSH key can be selected as the auth method on a connection profile). See Secret types.

Envelope encryption

Each secret’s data is sealed with its own data encryption key (DEK). That per-record DEK is then wrapped (encrypted) by a higher master key. The wrapped DEK is stored beside the ciphertext; the master key is not. To read a secret the server unwraps the DEK in memory, uses it, and discards it. This is why a single leaked record does not expose the rest, and why keys are never stored next to the data they protect. See Cryptography.

Audited access broker

VaultTerm is an audited access broker, not zero-knowledge. The server decrypts a secret in memory only for a specific authorized action — revealing a value, injecting a credential into a session, scanning output for a leak — and then discards the plaintext. No plaintext is kept at rest, and every such action is recorded. See Security model.

Tenancy and access

Organization (tenant)

An organization is a tenant: the isolation and billing boundary. Data for one organization is isolated from every other organization at the database layer using Postgres row-level security (RLS), so a query for one tenant cannot return another tenant’s rows. See Organizations and tenancy.

Team

A team is an intra-organization grouping of users — for example, “platform” or “on-call”. Teams exist inside one organization; team membership requires organization membership. Teams are how you grant access to a vault or secret to a group rather than naming people one at a time. See Teams overview.

Role-based access

Access is governed by roles: a role is a named set of permissions, and a user’s role decides what that user may do in an organization or on a resource. See Roles and permissions.

Just-in-time (JIT) access

JIT access grants a permission for a specific, time-bound need rather than leaving it standing. The broker injects access at the moment of use and it lapses afterward, so there are no standing credentials sitting on a device between sessions. See JIT access.

Accountability

Tamper-evident audit trail

Every read and every brokered session lands in a tamper-evident audit trail. Records are chained into a license-rooted checkpoint chain: checkpoints are anchored to the deployment’s license so a trail cannot be silently rewritten or truncated. See Audit logs.

Deployment and entitlements

Deployment mode

The deployment mode decides where VaultTerm runs and where it gets its entitlements. saas is the hosted service; onprem runs on your own infrastructure. The image and features are the same; only configuration differs. See SaaS vs self-hosted.

Entitlements / plan tier

Entitlements are the set of features and limits available to an organization, defined by its plan tier. In SaaS, entitlements come from the billing catalog; in on-prem, they come from a signed offline license. See Billing and plans and Licensing and activation.