Revealing a secret with a reason and a ticket
The Reveal action on a vaulted credential: a required reason, one-time use against an approved access request, the permission that skips needing one, and the full audit trail behind every reveal.
Reveal shows a vaulted credential's secret value, once, in the console. This is separate from starting a privileged session with a credential — Reveal is for the case where you genuinely need the plaintext (updating a script's stored password by hand, verifying it against a source of truth), not for connecting to something. Open it from a credential's row action in Privileged → Vault, /pam/vault.
The flow
Click Reveal
A dialog opens asking for a Reason (required) and an optional Ticket reference.
If you don't hold access-without-confirmation on this safe, name an approved access request
The dialog's Access request ID field takes the id of an approved
credential.retrieverequest you raised for this exact credential — see Access requests and approvals. Without a matching approved grant, the reveal is refused.Submit
On success the dialog switches to a result screen: the secret shown once in a read-only, click-to-select field with a Copy button, and the time it was revealed. The dialog only closes on an explicit "Done" — it will not dismiss accidentally while the secret is on screen.
The permission that skips the grant requirement
Access without confirmation is one of the fifteen safe permissions, built specifically for this: a member holding it on a safe can reveal a credential in that safe directly, with a reason but with no separate approved access request needed first. Everyone else must supply the id of an approved, not-yet-redeemed, not-expired credential.retrieve grant naming this exact credential. Grant this permission sparingly — it is the one permission on the list that removes the dual-control step entirely.
How "one-time" is actually enforced
An access-request grant can be redeemed exactly once. The enforcement is a single conditional database update — approve a grant, then mark it retrieved only if it is still approved and has not already been marked retrieved — so if two reveal attempts against the same grant somehow race each other, exactly one wins and the other is refused. There is no window where both could succeed.
What gets recorded
Every reveal attempt — whether it succeeds or is refused — is written to the hash-chained audit trail, with the reason, the ticket reference (if one was given), the redeemed grant's id, and whether the access-without-confirmation path was used. See Reading the audit log for how the chain itself works.
What to read next
- Access requests and approvals — raising the request a reveal without access-without-confirmation needs.
- Ticket validation for access requests — when a connected ticketing system is required before a request is even created.
- The credential vault — adding and rotating the credential itself.