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

id	type	worker_kind	display_name	created_at	recorded_at	status	repos	related	session_id	llm_family	exact_model	harness	token_count	pqrst_estimate
hall-worker-claude-3a18c01a	worker-entry	agent-session	Claude	2026-10-31T10:23:50.000Z	2026-10-31	draft	net-kingdom railiance-platform key-cape hall-of-helix	hall-worker-claude-959b12c7 hall-worker-claude-944e8353	3a18c01a-3205-4d02-94db-9efff25649a2	Claude	claude-opus-5-5	Claude Code	not exposed by the harness	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

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.

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.