NK-WP-0055-T13: king-path drill passed; post-event review record

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 4515@bnt-lap001
Assistant-Session: 0bf96127-6e04-41be-bfda-d11717c3f354

docs/evidence/2026-10-28-king-path-drill.md

@@ -0,0 +1,49 @@
+# King-path drill — post-event review record (NK-WP-0055-T13)
+
+Value-free record. No token, share, key or OTP appears here or in any linked receipt.
+
+| | |
+|---|---|
+| When | 2026-10-27/28 (UTC), founder workstation |
+| Who | Founder (operator and authorizer); claude-code prepared commands and verified receipts |
+| Why | Drill: prove that the final authority can act with SSO, KeyCape and OpenBao logins unavailable |
+| Production touched | Only by the separate, earlier rollout of the loopback `generate-root` listener (RAPP-OPENBAO-WP-0003-T02). The drill itself ran on an isolated, networkless restore. |
+
+## Part 1: break-glass material from Storage Share
+
+`kingpath-offsite.py --verify` fetched `net-kingdom-kingpath-20261027T223050Z-8c9d48421f1b.tar.age`
+from the Storage Share `Backup` account. ETag, size and digest matched the upload receipt. An unrelated
+key was refused, and the content decrypted in memory only. `admin-kubeconfig` (kubeconfig shape) and
+`tunnel-ssh-key` (SSH private key header) were intact. The custody helper refused the custodian age key
+until the `railiance-backup` key was entered, as designed. Crisis list item 1 was then split so the two
+keys cannot be confused again.
+
+## Part 2: OpenBao break-glass on an isolated restore (RPF-WP-0064-T10)
+
+- **Run:** attempt `RPF-WP-0064-T10-20261027-01`, admission `sha256:741fa571…ce7a`, adapter `3727f8b`,
+  snapshot `openbao-raft-snapshot-rpf-wp-0015-t03-reboot-20261014-01-20261014t181053z.snap.age`
+  (plaintext `a6312444…590b`).
+- **Result:** `drilled` (`break_glass_drill_complete`) in 101 s. The receipt
+  `sha256:e4591346e99b23e405f1cb69f6f5158dbdb7b5d69b2d1d7709c563a74cc18397` stays outside Git and was
+  independently verified (`PASS`) from a clean clone.
+- **Held initial root token:** valid as of the snapshot. It carries `root` policy, no TTL, no expiry,
+  and is an orphan token.
+- **Fresh `generate-root`:** the shares were re-entered and the OTP decode worked. The generated token
+  carried `root`, the read-only `sys/auth` action succeeded, `revoke-self` returned 204, and the
+  follow-up lookup returned 403.
+- **Cancel:** a started attempt was cancelled cleanly.
+- **Teardown:** the container was removed and verified absent, no volumes were created, the memfds were
+  closed, and the readback credential was revoked.
+
+## Findings and follow-ups
+
+1. **A standing, non-expiring root token very likely exists on production.** It was valid at the
+   2026-10-14 snapshot and has not been revoked since. The architecture asks that the initial root token
+   be revoked, or escrowed as break-glass material. The `generate-root` path now works on production and
+   is drilled, so it can replace that token. Founder decision needed: revoke it on production, or keep it
+   escrowed and record why.
+2. **Production read-only SSO-down walk:** still to run (RPF-WP-0064-T10 runbook).
+3. **Admission signing key:** it is `~/.ssh/gexec_approver_ed25519`. It needs a copy in the password safe
+   under the kingpath entry (crisis list item 5).
+4. **Not drilled:** using the restored kubeconfig and SSH key against the cluster. Provider console
+   access is not drilled either.