Organizations and tenancy

In VaultTerm an organization is the tenant. It is the unit that owns vaults, users, teams, and audit history, and it is the boundary that billing and isolation are drawn around. Everything a user can see or do is scoped to the org they belong to.

The isolation boundary

Tenant isolation is enforced in the database, not just in application code. Every row that belongs to a tenant carries an org_id, and Postgres row-level security (RLS) policies, keyed on that org_id, restrict every query to the caller’s org. The application sets the active tenant for the connection before running a query, so a query that forgets to filter by org still returns nothing from another tenant — the policy fails closed rather than leaking. For the full mechanism, see Tenant isolation.

This is the foundation of the platform’s security posture: the broker can decrypt a secret in memory for an authorized action, but it can only ever do so for resources within the caller’s own org.

How users land in an org

• Individual email signups get their own org. A person who signs up for the free tier is an org-of-one, isolated like any tenant.
• A shared Default org historically co-tenanted accounts that predate per-account isolation. This existed only to keep early accounts working; new individual signups land in their own org, not the Default one.
• Enterprise users are provisioned into their organization through SSO or SCIM — see SSO and SCIM.

Creating a dedicated org from an existing personal account is supported only for fresh accounts: the caller must be in the default or a personal org and own no vaults, because cross-org data migration is not supported.

Org roles

The organization has three roles, distinct from the vault and team roles:

Org role	Scope
owner	Full control of the organization, including its members and settings
admin	Manage members and org configuration
member	A regular user of the org

Org owner and admin are the roles that administer the tenant itself — inviting members, configuring identity, and managing billing. See Roles and permissions for how these relate to the vault and team roles.

Exporting the member list

For an access review, an org owner or admin can download the organization’s member list — id, email, username, org role, created date, last login and account expiry. It is CSV by default, with JSON available for tooling, and it is restricted to those two roles: a member cannot pull it. The CSV download is recorded in the audit trail.

This is a roster, not secret material. Do not confuse it with the vault export, which is a different thing with different rules:

	Member export	Vault export
Contains	Member accounts and roles	Plaintext credential values
Who can run it	Org owner or admin	Anyone with read on that vault, including a VIEWER
Format	CSV, or JSON on request	JSON only

See Importing and exporting secrets for the vault export and what it costs you, and Audit logs for the separate export of the trail itself.

Offboarding

Because every resource is scoped to the org, offboarding is a single step: removing a user from the organization removes their access everywhere within it at once — every team they were in, every vault shared with them, every session they could broker. There is no per-resource cleanup to chase, and the removal lands in the tamper-evident audit trail like any other privileged action.

Managing another organization

If you run access on other organizations’ behalf — a service provider, an internal platform team looking after separate business units — one organization can be granted managed access to another without the two ever merging. The org boundary above is not weakened; a scoped, time-limited session is opened into the client’s org, where that org’s own roles and row-level security apply unchanged.

• Nothing happens without consent. The provider’s owner or admin invites a client organization by the email of one of its owners or admins. The invitation grants nothing until that client accepts, and either side can revoke at any time — the provider from its client list, the client from its provider list. Revocation ends any session in flight, not just future ones.
• Read-only by default. Opening a client’s organization gives a read-only session. A session that can write is a separate, harder step: it needs a fresh passkey or app-MFA check to enter, and it runs at a role clamped to the lower of what the operator asked for and the ceiling the client agreed to. A relationship agreed at viewer level has no writable session at all.
• Sessions expire on their own. Both kinds are time-boxed grants rather than a standing login.
• The client sees it in their own log. Every entry into a client organization is written to that organization’s audit trail — naming the provider org, the individual operator, whether the session was read or write, and when it expires — as well as being visible to the provider. Both sides get an activity feed of the relationship.

Managed access is available from the Team plan up, under Organization settings.

Where to go next

• Learn how the org boundary is enforced at the database in Tenant isolation.
• Provision and deprovision enterprise users with SSO and SCIM.
• See what a provider’s operators can do inside a client org in Roles and permissions.