Members & Access Control

Access to a vlt account — its registries, packages, tokens, and settings — is managed through account membership. Roles and token privileges apply account-wide; on top of that, individual packages carry a visibility level, and teams can be granted access to specific packages.

Roles

Every member has one of three roles:

Role	What it can do
Owner	Everything, including billing, account settings, and member management
Admin	Same capabilities as owner, including billing and account settings
Member	Read and publish packages, and create and revoke their own personal tokens

The account’s creator is its owner. Owners and admins can also create service tokens for CI and trigger upstream package syncs; members can’t.

Inviting members

Owners and admins invite new members from the Members page in the dashboard. Invitations are sent by email, assign either the member or admin role, and expire after 7 days if not accepted.

Owners and admins can also change an existing member’s role between member and admin from the same page. An owner’s role can’t be changed, and no one can change their own role.

How permissions are evaluated

Capabilities are expressed as privileges — for example package:read, package:write, token:create, member:write, billing:read. Each role maps to a set of privileges, and each token carries its own set (see Authentication & Tokens).

A request is allowed only when both the member’s role and the token grant the required privilege. That means a read-only token is safe to hand to CI even if it was created by an owner, and a token can never do more than the person who created it.

Package access

• Members of an account can install from and publish to the account’s main registry.
• People outside the account have no access to its restricted packages.
• Packages published as public are installable by anyone, without a token — see Package visibility for how to set and change the level.
• The account’s npm mirror serves public packages and is readable by any authenticated account member.

Granting a team access to a package

Beyond the account-wide roles, a team can be given access to individual packages:

$ vlt access grant read-only @acme:frontend @acme/utils
$ vlt access revoke @acme:frontend @acme/utils

Permissions are read-only or read-write. Omit the package name to apply the grant to every package in the scope. Run these against your account registry — vlt registry main access grant ... if you have more than one configured.

Two-factor enforcement

By default, package writes (publish, deprecate, unpublish, dist-tag changes) made with a personal token require a one-time password. Owners and admins can toggle this requirement under Settings → General. Service tokens are exempt, so CI publishes are unaffected — see Publishing — Two-factor authentication.