Safes and safe members
The container every privileged credential lives in, the fifteen CyberArk-style permissions a member can hold, the default safe, and how safe membership decides who sees, uses or approves an account.
A Safe is the container every credential, policy and approval attaches to — not a folder for organising the vault, but the actual boundary of who may see, use, retrieve or approve access to an account. Every credential lives in exactly one safe. Manage safes at Privileged → Safes, /pam/safes.
The default safe, and where existing credentials landed
Every organisation has exactly one default safe. If your vault already held credentials before Safes existed, they were moved into a safe called Default automatically — nothing was left unassigned. Store a new credential without naming a safe explicitly and it lands in the default safe too. There is at most one default safe per organisation.
A safe cannot be deleted while it holds any accounts — the delete confirmation says so plainly ("must hold no accounts to be deleted"), and there is no undo once it goes through.
The fifteen safe permissions
A safe member — a user, an IAM group or an IAM role — holds some subset of fifteen permissions on that safe. Nothing is granted by default; you choose the checkboxes when adding a member.
| Permission | What it governs |
|---|---|
| List accounts | See which credentials exist in this safe (names and metadata, not the secret itself). |
| Retrieve | Reveal a credential's secret — see Revealing a secret with reason and ticket. |
| Use | Start a privileged session with a credential in this safe, without seeing the secret itself. |
| Update properties | Edit a credential's metadata (name, description, target binding). |
| Update secret | Change a credential's stored secret, including onboarding a new one into this safe. |
| Initiate rotation | Kick off a rotation run on demand. |
| Rename | Rename a credential. |
| Delete | Delete a credential from this safe. |
| Unlock | Release a lock condition on a credential. |
| Manage safe | Edit the safe itself — name, description, retention — and configure dual-control workflows bound to it. |
| Manage members | Add, edit or remove this safe's members. |
| View audit | See this safe's own audit trail. |
| View members | See who else is a member of this safe and what they hold. |
| Access without confirmation | Retrieve a secret without needing a pre-approved access-request grant first — the one permission built specifically to bypass the dual-control step. |
| Authorize requests | Approve or reject another member's access request against this safe. |
Two ways a permission check passes
- Administrator override. Anyone holding the platform's
pam:credentials.deletepermission (the one action every PAM permission tier has agreed is admin-only) acts as a PAM administrator across every safe in the organisation, with no membership row required. This is what lets an org admin see and manage everything without being added to every safe by hand. - Safe membership. Everyone else needs an actual
pam_safe_membersrow — held directly on their user, through an IAM group they belong to, or through an IAM role they hold — naming the specific permission the action requires.
The practical effect: the credential list itself is safe-scoped. An administrator sees every credential in the organisation, same as before Safes existed; anyone else sees only the credentials in a safe they hold at least one permission on.
Adding a member
Open a safe's Members panel, choose the principal type — User, Group or Role — and search by name. Member principals are resolved through a real name-search picker as of this release, not typed in as raw ids; switching the principal type clears whatever you had picked, since a group id and a user id are different spaces and carrying one across would silently submit the wrong principal. Pick which of the fifteen permissions to grant, then add. The member table itself also resolves each stored principal to a real name rather than the raw kind:id pair — a principal that no longer exists is shown as "No longer exists" rather than a bare id, and one that could not be checked shows "Could not be checked" so you know the difference between a deleted account and a lookup failure.
Policies can be scoped to a safe
A PAM access policy can target a safe directly, in addition to the older credential-, target- or organisation-wide scopes. When more than one policy could apply to a credential, the most specific one wins: credential, then target, then safe, then organisation. See PAM access policies for the general model, and Master Policy and its exceptions for the org-wide controls (require a reason, require a ticket, exclusive access, and so on) that layer on top of ordinary policy scoping.
What to read next
- Dual-control approval workflows — configuring who has to approve an access request before it activates, per safe.
- Revealing a secret with reason and ticket — what the Retrieve and Access without confirmation permissions actually unlock.
- The credential vault — adding and verifying a credential itself.