Isolation model

Vault is a multi-tenant system where each organization operates as a separate tenant. Tenants share the underlying infrastructure (compute, networking, storage) but share no application-level state. A request authenticated for Tenant A cannot read, list, query, or reference any resource belonging to Tenant B.

This isolation is enforced at multiple layers: authentication, authorization, encryption, and data access.

Authentication boundary

Every API request includes a tenant identifier, either embedded in the authentication token or provided as a request header. The authentication layer resolves the tenant before any business logic executes. If the token does not belong to the claimed tenant, the request is rejected with a 403.

Tokens are scoped to a single tenant at creation time. There is no mechanism to create a cross-tenant token. Administrative operations that span tenants (such as platform-level monitoring) use a separate, isolated control plane.

Cryptographic boundary

Each tenant has its own Key Encryption Key (KEK) derived from the root key using the tenant’s unique identifier as input to HKDF. This means:

• Tenant A’s KEK cannot decrypt Tenant B’s wrapped DEKs.
• Compromising Tenant A’s KEK does not expose Tenant B’s credentials.
• Deleting Tenant A’s KEK makes all of Tenant A’s credentials permanently unrecoverable, without affecting Tenant B.

See Encryption Envelope for the full key hierarchy.

Data access boundary

All database queries include the tenant ID as a filter condition. This is enforced at the data access layer, not at the application layer, so it cannot be bypassed by application-level bugs. The query pattern looks like:

SELECT * FROM credentials
WHERE tenant_id = $1 AND name = $2;

There are no queries in Vault’s codebase that read credentials without a tenant ID filter. This invariant is enforced by code review and automated tests that scan for unscoped queries.

Policy boundary

Access control policies (who can access which credentials, with what TTLs) are scoped to a tenant. A role defined in Tenant A has no meaning in Tenant B. When a new tenant is created, it starts with a default set of policies that can be customized independently.

Tenant lifecycle

Creation — When a new organization signs up, Vault provisions a new tenant. This includes deriving a new KEK, creating default policies, and initializing an empty credential store.

Operation — During normal operation, all requests are scoped to the authenticated tenant. Credential CRUD, leasing, policy management, and audit log queries all operate within the tenant boundary.

Deletion — When a tenant is deleted, their KEK is destroyed, all credential ciphertext is deleted, and all audit log entries are marked for retention per the compliance retention schedule. The deletion process is irreversible.

Shared infrastructure, separate state

Vault uses shared compute and storage infrastructure across tenants for operational efficiency. The isolation guarantees are logical, not physical, but they are enforced at every layer where tenant data could cross boundaries. For organizations that require physical isolation, Vault offers dedicated deployment options where the entire Vault instance runs in the customer’s infrastructure.

For more on access controls within a tenant, see Team Sharing and ACLs.