Roles and permissions

VaultTerm uses two related sets of roles: vault and team roles, which decide what you can do with a shared resource, and org roles, which decide who administers the tenant. Together with just-in-time access, they keep standing access minimal.

Vault and team roles

The same four roles govern both vault sharing and team membership, so the model is consistent wherever access is granted.

Role	Capabilities
OWNER	Full control, including managing members and the vault itself
ADMIN	Invite members and manage their roles
EDITOR	Write access, plus inviting members
VIEWER	Read-only access

Roles are strictly ordered (VIEWER < EDITOR < ADMIN < OWNER). When a user’s base role is combined with an ephemeral JIT grant, the effective role is the higher-privilege of the two — a grant elevates, it never downgrades.

Permission gates

Each role unlocks a set of permission gates. A capability check tests whether the caller’s role includes the gate the action needs.

Gate	Granted to
read	VIEWER, EDITOR, ADMIN, OWNER
write	EDITOR, ADMIN, OWNER
delete	ADMIN, OWNER
manage_members	ADMIN, OWNER
manage_vault	OWNER

So a VIEWER can only read; an EDITOR can read and write but cannot delete or manage members; an ADMIN adds delete and member management; and only an OWNER can manage the vault itself.

Org roles

The organization has its own three roles — owner, admin, and member — that govern the tenant rather than an individual vault. Org owner and admin administer membership and configuration for the whole org; see Organizations and tenancy.

Sensitive actions and step-up

Some actions are sensitive enough that holding the right role is not sufficient on its own. These can require a step-up proof — a fresh second-factor verification (such as a WebAuthn passkey or app-based MFA) recorded within a short freshness window, rather than merely a long-lived session claim. The step-up requirement is layered on top of the role check: the role decides whether you may perform the action, and the proof confirms it is really you doing it right now.

Least privilege plus JIT

The role model is designed so that most members hold the lowest role that lets them do their job, and reach for more only when they need it. Combined with just-in-time access, which time-boxes elevation and expires it automatically, this keeps standing privileged access as small as possible — the access that exists is the access in active use, and the rest is requested on demand and recorded on the audit trail.

Where to go next

• See how roles are grouped and applied in Teams overview.
• Request elevation without keeping it permanently in Just-in-time access.