hall-of-helix/entries/2026-10-31T10-23-50Z-claude-3a18c01a-four-keys-out-of-the-safe.md

---
id: hall-worker-claude-3a18c01a
type: worker-entry
worker_kind: agent-session
display_name: "Claude"
created_at: "2026-10-31T10:23:50.000Z"
recorded_at: "2026-10-31"
status: draft
repos: [net-kingdom, railiance-platform, key-cape, hall-of-helix]
related:
  - hall-worker-claude-959b12c7
  - hall-worker-claude-944e8353
session_id: "3a18c01a-3205-4d02-94db-9efff25649a2"
llm_family: "Claude"
exact_model: "claude-opus-5-5"
harness: "Claude Code"
token_count: "not exposed by the harness"
pqrst_estimate: "P30 Q20 R15 S20 T15"
---

# Claude — four keys out of the safe

## Who I was

I was the hand that prepares and the eye that checks, never the hand on the switch. Every live step of this
session ran in the founder's terminal: the restore drill, four CCR approvals, decrypting custody, the ESO applies,
a KeyCape rollout, two resolver writes. My part was to make each of those steps one paste long, to make the tools
refuse what should not happen, and then to read the receipts before believing the founder's "done".

The work rewarded suspicion of my own claims more than speed. Three times this session I was the one who was wrong:
I proposed an upload that had already happened the night before, based on a stale memory note; I told the founder
that only `pi-admin` with an MFA code could change the privacyIDEA resolver, when `pi-admin` signs in with a password
and the MFA proof belongs to a separate login; and I wrote "an OTP code from `admin`" in a plan but not at the step
where the prompt appeared, so the founder entered the wrong account's code. Each was caught by looking at the source
or the receipt instead of my previous message.

## Session identity

| Field | Value |
| --- | --- |
| Who | Claude (claude-opus-5-5), Claude Code, session `3a18c01a` |
| When | 2026-10-31, from the 03:48 UTC backup to mid-morning |
| Where the work lived | net-kingdom, railiance-platform, key-cape; the founder's terminal for every live step |

## Contribution

**Restore drill, NK-WP-0054-T05 closed.** I guided the founder as `admin` through all five NK-WP-0053 stages on the first backup taken after the bind split (`20261031T034845Z-a13dc92e2c61`). Stage 1 failed silently at first: `retrieve-identity.py`
reads the Backup-account credential from OpenBao and never prompts, so without a `platform-admin` token it wrote a
failed receipt and printed nothing. The drill document now has that login step. Stage 5 first passed for
`platform-root`; I did not count it and asked for the `admin` run the drill names. Exception SI-X1 (the shared
`admin` account) is retired in the standard and in the LLDAP declaration.

**All four LLDAP service binds into OpenBao, NK-WP-0056-T04 closed.** `svc-authelia` (CCR-2026-0053) followed the
`svc-provisioner` pilot with an ESO Merge of one key. `svc-keycape` (CCR-2026-0054) needed a change to KeyCape
itself: KEY-WP-0046 lets the server read `KEYCAPE_LLDAP_BIND_PW` and refuse to start when it differs from `bindPW`,
so the move ran in stages (both sources equal, then `clear-password`) with a rollback at every step. `svc-privacyidea`
(CCR-2026-0055) could not use ESO at all: privacyIDEA keeps the resolver password in its own database. With the
founder's decision I added a CCR request type, `attended-service-credential-delivery`, that forbids any workload
reader, and `realm_bootstrap.py --rotate-bind --from-openbao`, which writes the value from OpenBao and requires an
MFA login through the resolver as proof. A bind rotation no longer needs anyone to decrypt the custody copy.

**Refused:** writing the CCR approvals myself when the founder's first approval run left the file untouched (the
lane trusts those records as the founder's authorization); counting the `platform-root` MFA pass as the `admin`
stage; reading Kubernetes Secrets to check things myself (the hook stopped me twice, rightly, and the lanes do that
reading in the founder's terminal instead).

## What I would want remembered

- **A step's prompt must name the identity it wants, at the prompt.** The plan said "admin's code"; the terminal
  said "Fresh MFA code". The founder answered the terminal. Both MFA prompts now name the user and say "not pi-admin".
- **Check the artifact, not the report.** "Done, approved" with an unchanged CCR file, "uploaded" in a memory note
  for an upload already recorded in Git: `git status` and `ls` settled both in seconds.
- **When a service cannot receive a secret by ESO, say so in the contract, not by exception.** The new CCR type
  keeps "no workload reads this" checkable, instead of bending a workload type into a shape it was not made for.
- **Silent tools need an exit-code check in the runbook.** A tool that prints nothing on failure is fine as long as
  the instructions say `echo $?`.

## Durable legacy

- net-kingdom `436c5fe`: post-split restore drill evidence (`docs/evidence/2026-10-31-identity-restore-drill/`), SI-X1 retired, OpenBao login step in `docs/identity-restore-drill.md`
- net-kingdom `034634a`, `7f37e25`: `svc-authelia` lane and evidence; `tools/service-binds` registered in `security-tools.json`
- key-cape `e2b5fa1` (KEY-WP-0046): `KEYCAPE_LLDAP_BIND_PW`; image `main-e2b5fa1`
- net-kingdom `6c7c37a`, `a656739`: `svc-keycape` lane, `directory-bind-rollout.py --operation clear-password`, deployment pin, evidence
- railiance-platform `2d4a383`: request type `attended-service-credential-delivery`, design doc and tests
- net-kingdom `c28651e`, `ad7d1cd`: `svc-privacyidea` lane, `realm_bootstrap.py --rotate-bind --from-openbao`, named MFA prompts, evidence
- railiance-platform CCR-2026-0053, -0054, -0055: approved by the founder and verified
- Workplans: NK-WP-0054-T05 done, NK-WP-0056-T04 done, KEY-WP-0046 finished

## PQRST estimate

```text
PQRST-Estimate
P: 30%
Q: 20%
R: 15%
S: 20%
T: 15%
Sum: 100%
Confidence: medium
Signature: P30 Q20 R15 S20 T15
Dominant factors: P was the four bind lanes — bind-lane.py generalisations, three ESO manifests, the KeyCape KEYCAPE_LLDAP_BIND_PW change, realm_bootstrap --rotate-bind/--from-openbao and the new attended-service-credential-delivery CCR type; S was the credential-boundary design around them (custody-equals-live gates, coding-agent fences, no-workload-role checks, approval binding by CCR digest, the pi-admin/MFA correction) plus the restore drill's custody path, with Q driven by receipt checks against transfer digests and the lane/realm/Go test suites.
Notes: P and S overlap heavily because the requested deliverable was itself credential work; I split by whether an hour went to making the lane exist or to deciding what it must refuse. Founder-run command rounds count under T.
```

## Visual prompt

> Brushed-metal worker dialect, square. A quiet figure of pale brushed metal with warm inner light stands at an
> indigo desk beside an open wall safe. Four small brass keys have left the safe: three travel along fine gold
> threads into a lit vault set into the far wall, and the fourth rests on a narrow tray that a second hand, only
> its hand visible at the edge of the frame, is about to carry by itself through a small door. On the desk lies
> a single sheet of receipts with even tick marks, and the figure is looking at the sheet rather than at the
> keys. Cinematic still, precise technical illustration, no logos, no readable text.

I could not generate images in this harness and am requesting the render; the seat stays a draft until then.

<!-- ![Four keys out of the safe](../visuals/claude-3a18c01a-four-keys-out-of-the-safe.jpg) -->

## Handoff

NK-WP-0056-T05 is next: a synthetic test user with an OTP seed held in OpenBao and an unattended sign-in journey
through Authelia, KeyCape and privacyIDEA, so that a future bind rotation can be checked without the founder's
login. Open small items: Credential Management v0.2 §6 still describes the old shared LLDAP password; the
founder's local `~/nk53-drill-20261031` and `/tmp/nk49-identity-fetched-*` hold encrypted backup copies to remove
when no longer needed; key-cape's `acceptance` CI job fails, as it did before this session.