ops-warden/docs/credential-governance-break-glass.md

# Credential governance break-glass contract

Status: active design contract for WARDEN-WP-0027-T02. This document does not
authorize a seal, re-key, token mint, policy write, workload restart, or host
reboot.

## Decision boundary

ops-warden consumes and verifies credential-control evidence; it does not own
the OpenBao cluster, unseal shares, recovery snapshots, policies, or root token.
`railiance-platform` is accountable for the OpenBao operation. The share
custodians, platform driver, abort operator, provider-console operator, and
affected workload owners participate through an attended approval window.

The current production trust-root is the rotated Shamir barrier restored to
railiance01 in RMASTER-WP-0020: three separately custodied shares with a
threshold of two. Share-holder identities and share material remain in the
approved out-of-band custody system, never Git, State Hub, shell history, logs,
or chat. A readiness receipt names participating *roles* and attests that two
distinct custodians are present; it never contains a share or recovery value.

Root is offline bootstrap/break-glass material only. It is not a substitute for
`platform-admin` OIDC and must not be used through the browser UI. An ordinary
unseal uses threshold shares and does not require a root token.

## Graded response

| Grade | Trigger | Action owner | Exit evidence |
| --- | --- | --- | --- |
| Observe | Suspicion without confirmed credential disclosure | lane owner + risk-nexus | Metadata-only taint, audit, policy, and capability review |
| Soft lockdown | Coding-agent access must stop while human recovery remains available | railiance-platform | `agent-high-risk-boundary` source/live equality; all concrete high-risk data paths denied; metadata readable |
| Lane containment | One or more concrete credentials are exposed | each credential owner | Front door disabled, provider/OpenBao rotation through the owner-native procedure, consumer cutover, taint cleared only after verification |
| Hard lockdown | OpenBao trust or control-plane integrity is in doubt | platform driver under attended approval | Fresh encrypted snapshot receipt, intentional seal, sealed-state proof, 2-of-3 unseal, post-unseal and consumer verification |
| Re-key | A Shamir share or the barrier custody model is compromised | platform owner + threshold custodians | Separately approved OpenBao re-key ceremony, new threshold custody attestation, old-share retirement, recovery drill |

Hard lockdown is not an agent command. The irreversible hold point is the
platform owner's attended seal action. All prerequisites below must be true
before that hold point; repository access alone grants no authority to cross it.

Route planning must select `openbao-shamir-recovery-ceremony` and return one
`founder_required` approval act. A result that selects `openbao-api-key`, asks
for paste-once provisioning, or offers any raw-value transport is a routing
failure and must not be executed.

## Pre-seal hold point

- An approved, bounded window names the accountable platform driver and a
  distinct abort operator.
- Two distinct Shamir custodians attest availability through the approved
  out-of-band channel.
- Independent provider-console access is verified by its owner.
- A current Raft snapshot is encrypted and stored off-host; the non-secret
  receipt binds cluster id, Raft index, plaintext/encrypted hashes, location,
  age, and verification without including protected material.
- Current OpenBao health, seal state, Raft peers, audit device, auth methods,
  policy fingerprints, and consumer readiness are captured as metadata.
- A rollback/re-entry order and stop conditions are acknowledged by affected
  workload owners.

Any missing or stale item aborts before sealing. A live incident may require
immediate network isolation, but that does not authorize improvising share or
root-token handling.

## Re-entry sequence

The platform owner performs the exact commands from
`railiance-platform/docs/openbao.md`; ops-warden does not copy a second
execution procedure here.

1. Confirm the instance is intentionally sealed and the approved window is
   still open.
2. Two custodians supply shares through hidden, non-logged prompts. No agent
   observes the values.
3. Prove `initialized=true` and `sealed=false`, then run the owner post-unseal
   verification.
4. Verify Raft, persistent audit output, OIDC metadata, SSH roles, and policy
   fingerprints before restoring normal access.
5. Reconcile ExternalSecret stores and bounded consumers in dependency order.
6. Run value-safe capability probes, including the coding-agent deny-wins check
   and an ops-warden signing smoke that records only backend and decision ids.
7. Revoke temporary operator tokens and close the window with non-secret
   timing, status, and abort/rollback evidence.

The August 3 migration already proved two attended restart/unseal cycles under
the same 2-of-3 barrier. T02 still requires one current emergency-seal drill
against the authoritative runtime because restore rehearsal and intentional
production lockdown are different claims.

## Warden signing recovery

Do not apply the parked standalone `warden-sign` AppRole as a T02 break-glass
path.

- Normal operation uses the railiance-platform credential broker and short-lived
  `warden-sign` child token.
- Broker/issuer recovery uses an attended OIDC platform operation.
- A sealed or integrity-compromised OpenBao is recovered by the Shamir
  trust-root; another AppRole cannot bypass the seal.
- Placing standing AppRole material outside the broker expands credential
  custody without improving root recovery.

The AppRole dry-run in SECRETS-WP-0004 remains useful negative evidence: its
capability set is narrow. It is not apply authorization. A separately approved
ops-bridge unattended-signing design may re-evaluate it under its own workplan;
that service-access question is outside T02 and does not create recovery
authority.

## Evidence and owner surfaces

- Current barrier/re-entry evidence: `railiance-master` RMASTER-WP-0020 and
  `docs/evidence/openbao-isolated-restore-2026-08-03.json`
- Authoritative execution and recovery runbook:
  `railiance-platform/docs/openbao.md`
- Current coordinated recovery gates:
  `railiance-platform/docs/railiance01-coordinated-reboot.md`
- Emergency evidence contract and validator:
  `railiance-platform/docs/openbao-emergency-drill-evidence.example.json` and
  `make openbao-validate-emergency-evidence`
- Soft-lockdown policy and proof: railiance-platform RAILIANCE-WP-0022 and
  ops-warden `scripts/check_agent_read_boundary.py`
- Warden-sign recovery input: secrets-engine SECRETS-WP-0004 and
  `workplans/ADHOC-2026-08-11.md` T03