Vault Roles & Access Roles
The two roles every organization member holds — a vault role for vault-wide management, and an access role for project access.
Every member of an organization vault holds two roles, and they answer two different questions:
- A vault role decides what a member can do across the vault: manage machines, read the audit log, configure alerts, invite people, manage billing. It carries no project or secret access.
- An access role decides which applications and projects a member can reach, and what they can do inside each: manage secrets, attach machines, write access policies.
The two are independent. A member with a powerful vault role but no access role can manage vault-wide surfaces yet cannot open a single project. A member with a broad access role but the lowest vault role can work in every project yet cannot invite a colleague. Most members need a sensible pairing of both.
The vault owner always holds everything in both axes. Roles apply only to invited members.
Vault roles
A vault role is the management plane. It governs the vault-wide pages in the dashboard sidebar and the actions on them. Every member holds exactly one vault role.
The four built-in roles
| Role | What it is for |
|---|---|
| Owner | The vault owner. Holds every capability unconditionally. Not assignable. |
| Admin | Runs the vault day to day: machines, AI agents, enrollment, alerts, IP allowlist, integrations, members, all trash, the full audit log, support. Cannot touch billing or author access roles. |
| Developer | Builds and operates: machines, AI agents, enrollment tokens, integrations, and their own trashed secrets. Sees the member roster and their own audit trail. |
| Collaborator | The minimal default. Sees the overview and their own audit trail, nothing else, until you raise their role. |
A new member starts as a Collaborator until you change it, so an unconfigured member can never over-reach.
What a vault role can gate
The full management vocabulary, by category. View and manage are paired, and manage implies view.
| Category | View | Manage |
|---|---|---|
| Overview | See the vault overview | (view only) |
| Machines | See machines and status | Bootstrap, approve, disable, revoke |
| AI agents | See agents and their scopes | Provision, scope, revoke agents |
| Enrollment tokens | See tokens | Create and revoke tokens |
| Audit log | See your own actions | Expand to every actor (view_others) |
| Alerts | See alert and webhook config | Configure email alerts and webhooks |
| IP allowlist | See the allowlist | Enable it, add and remove entries |
| Integrations | See connected integrations | Install and configure integrations |
| Trash | Your own trashed secrets | Every member's trashed secrets |
| Members | See the roster | Invite, suspend, remove, assign roles below your own |
| Access roles | See access roles | Create and edit access roles |
| Support | See tickets | Open, reply to, close tickets |
| Billing | See billing state | Manage the subscription and payment methods |
Custom roles
On enterprise plans you can author custom vault roles instead of the four built-ins. A custom role is a named set of these capabilities, scoped to your vault, that you assign like any built-in role.
Custom roles obey one rule: you can only grant what you already hold. You cannot put a capability into a custom role that your own role lacks, and you can only assign a built-in tier strictly below your own. This never-grant-above-yourself guard makes privilege escalation through role authoring impossible.
Access roles
An access role is the project plane. It decides which applications and projects a member reaches, and what they can do inside each. Every member holds at most one access role. A member with none reaches no projects at all, which is the safe default.
View is implicit
A project being in scope means the member can open it and see its three pages: Secrets, Machines, and Policies. The capability toggles gate the manage actions on those pages, not visibility. A project brought into scope with every toggle off is a clean read-only auditor view of that project.
When you bring a project into scope, every capability is granted by default. You opt out of the ones you do not want rather than opting in to each.
What an access role grants
Per project in scope:
Secrets, one toggle per secret kind, so you can let someone manage normal secrets without touching canaries:
| Capability | Grants |
|---|---|
| Normal | Manage normal secrets |
| Structured | Manage structured secrets |
| Managed | Manage managed (externally-synced) secrets |
| Canary | Manage canary trip-wire secrets |
| TTL | Create and manage temporary, one-time, human-recipient shares |
Machines, managing the project's machine attachments:
| Capability | Grants |
|---|---|
| Add | Attach machines to the project |
| Remove | Detach machines from the project |
| Configure grants | Change which secrets a machine in the project may read |
Policies, the access-constraint layer:
| Capability | Grants |
|---|---|
| Add and remove | Create and delete access policies, bind and unbind secrets |
| Configure, per axis | Each axis (time window, IP allowlist, rate cap, co-sign, TTL) is its own toggle, so you can let someone set a time window without letting them loosen the IP allowlist |
How a project gets into scope
You can scope an access role three ways, from broad to precise:
- A broad domain. Every application and project, or every application, or every standalone project, current and future. The full capability set applies across the whole domain. This is the shortcut for a trusted role that should reach everything of a kind.
- Whole applications. Pick specific applications. The role reaches all of each application's projects (its Prod, Staging, and Dev environments), which inherit the application's capability set. You can override a single environment with its own capabilities, or exclude one entirely.
- Standalone projects. Pick individual standalone projects, each with its own capability set.
You can mix these: an access role might grant a whole application, exclude its Prod environment, and add one standalone project on the side.
Assigning roles to members
Both roles are set from Organization → Members.
- At invite time you choose the new member's vault role. You can leave it at the Collaborator default.
- After they join you assign their access role, and you can adjust either role at any time from the member's row with Change vault role and Change access role.
A member's roles resolve fresh on every request, so a change is live by their next page load. You can only assign a vault role below your own, and you can only build an access role out of access you hold yourself.
Coming from templates
Earlier, member permissions were a single template that bundled capabilities with a project scope. Templates have been replaced by this two-role model: the management half of a template is now a vault role, and the project-scope half is now an access role. Splitting them lets you reuse one management tier across people who need very different project access, and reuse one project scope across people who need very different management rights.