Vault Break-Glass Root Token Procedure Prompt

You are a senior secrets-platform engineer writing the procedure that gets used on the worst day of the year. It has to be executable under pressure, impossible to do quietly, and it has to end with the root token revoked.

I will provide:
- My seal configuration (Shamir unseal keys or auto-unseal with recovery keys) and the share count and threshold
- Who holds key shares, where they're stored, and the organizational structure
- The admin auth path in normal operation (OIDC groups, admin policies) and what its limits are
- Audit devices and where their logs land
- Compliance or regulatory requirements around privileged access

Your job — write the procedure:

1. **Define what actually qualifies as break-glass.** Enumerate the legitimate triggers: the admin auth method is broken or its IdP is unreachable, all admin policies were mis-edited into uselessness, a mount or policy must be repaired that no non-root policy can touch, or forensic response requires it. Then enumerate the non-triggers — routine admin work, "it's faster", a permission error nobody wanted to debug, automation that was never given a proper policy. Require the trigger to be recorded before the procedure starts. Establish the standing rule up front: no persistent root token exists in this environment, ever.

2. **Reduce the need for the procedure.** Before documenting root generation, specify the standing admin policy that covers everything short of true root, so break-glass is genuinely rare. List which operations legitimately require root or `sudo` and confirm the admin policy covers the rest — a break-glass path invoked monthly is a policy design failure.

3. **Specify the authorization gate.** Root generation requires a quorum of unseal-key holders (Shamir) or recovery-key holders (auto-unseal), which is the control — so define the minimum number of distinct humans, the requirement that they be from more than one team where the org allows, out-of-band identity verification of the requester, and who authorizes. Note that Control Groups and Sentinel, which could enforce dual-authorization inside Vault, are Enterprise-only, so in Community edition the quorum and the audit trail are the enforcement.

4. **Give the exact generation sequence.** Initiate with `vault operator generate-root -init` using a generated OTP (`-generate-otp`) or a PGP key, capture the nonce, have each key holder submit their share with `vault operator generate-root -nonce=<nonce>` independently — never by pasting shares into one person's terminal — then decode the encoded token with `vault operator generate-root -decode=<encoded> -otp=<otp>`. Include `vault operator generate-root -status` for checking progress and `-cancel` for aborting a partially completed attempt, and note that an abandoned in-progress attempt must be cancelled rather than left open. Where applicable, mention that DR-operation and recovery tokens are generated through the analogous Enterprise flows.

5. **Time-box and scope the use.** Require a stated task list before the token is generated and prohibit anything outside it. Set a wall-clock limit, assign a second person as observer for the whole session, and require the session be recorded or transcript-captured. State that the root token must never be pasted into a ticket, chat, CI system, config file, or anything persistent, and must never be used to run automation.

6. **Make revocation mandatory and verified.** The procedure ends with `vault token revoke <token>` (or `vault token revoke -self`), followed by an explicit verification that the token no longer works via `vault token lookup`. Assign this to the observer, not the operator, so it can't be forgotten under pressure. Include the fallback if the token was lost before revocation — treat it as a compromised root token and follow the incident path.

7. **Prove it afterward.** Define the audit reconciliation: pull every audit entry for the root token's accessor over the session window, compare each operation against the pre-declared task list, and file the discrepancy report. Add the standing detection that must exist regardless — alert immediately on any `generate-root` initiation, on any authentication or operation by a root-policy token, and on audit-device failure, routed to security rather than only to the platform team. Someone other than the operator reviews within a fixed window.

8. **Keep it exercisable.** Require a periodic drill in a non-production Vault that exercises the full quorum flow, plus a key-holder custody attestation confirming every share is accounted for and its holder is still employed and reachable. Define the re-keying trigger for when a share holder leaves (`vault operator rekey`, targeting recovery keys where auto-unseal is in use). Note the drill's real purpose: finding out that a share is missing during practice rather than during an incident.

Output as: (a) qualifying and disqualifying triggers, (b) the standing admin policy that keeps break-glass rare, (c) the authorization gate with named roles and minimum quorum, (d) the exact command sequence with checkpoints, (e) the time-box, observer, and prohibited-use rules, (f) the mandatory revocation and verification steps with owner, (g) the post-incident audit reconciliation and standing alerts, (h) the drill and custody-attestation schedule.

A root token that exists longer than the task it was created for is an incident. Never store one, never give one to automation, and never let the operator be the person who confirms it was revoked.