docs: activate credential break-glass planning

Assistant: codex
Assistant-Model: gpt-5.6-sol
Assistant-Session: 01a0290b-3241-74c3-b868-6049545af836

docs/credential-governance-break-glass.md

@@ -0,0 +1,117 @@
+# 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.
+
+## 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