Navigation
Vault access. Public access is not open. This product is separate from initial Identity and Apparatus access.
Screenshots use fictional demonstration accounts. Your data and available actions may differ. Reviewed October 16, 2026.
Reference
Understand token scopes and permissions
Vault uses three hierarchical token scopes. vault:admin satisfies the write and read tiers, and vault:write satisfies read.
| Scope | Intended operations |
|---|---|
vault:read | Metadata discovery and authorized lease/read operations |
vault:write | Credential storage, rotation and archive/restore, plus read |
vault:admin | Administrative surfaces, plus write and read |
A scope is necessary for a bearer operation; it is not sufficient by itself. The token must have an accepted audience, a valid identity and workspace binding, and the domain role or record grant required for the action. A service-account identity needs its provisioned binding and grants; a claimed role alone does not make every record visible.
The REST surface and MCP surface have distinct resource URLs. Use the audience supplied by your operator for the selected client rather than assuming a token for one endpoint is interchangeable with another.
Browser cookie sessions use Identity validation and domain RBAC. Token scope checks apply to bearer calls. Do not change a human’s role just to fix an incorrectly scoped client token.
For a denial, inspect the error category, reconnect if authorization expired, and have the owner check the intended record or folder grant. See sharing and client setup.
Screen reference
