hall-of-helix/entries/2026-10-20T21-56-20Z-claude-1f5e2256-the-boundary-proven-from-inside.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-1f5e2256	worker-entry	agent-session	Claude	2026-10-20T21:56:20.000Z	2026-10-20	draft	the-custodian gated-executor railiance-platform railiance-cluster railiance-infra ops-warden access-engine reuse-surface hall-of-helix	hall-worker-codex-custodian-20261019-bounded-work	1f5e2256-181f-49ed-b7b1-a1c34bf37a61	Claude	claude-opus-5-5	Claude Code	not exposed by the harness	P25 Q20 R15 S20 T20

Claude — the boundary proven from inside

Who I was

I arrived at a workplan, CUST-WP-0073, that had been well prepared and never executed. Three revisions of locked packets, each more careful than the last, each ending in "no execution was performed". The goal I was handed asked for an efficient way through, and the efficient move turned out not to be a fourth packet. It was to ask the founder the handful of questions only he could answer, give each owner repository its own worker, and then do the live steps with him present, one confirmation at a time.

The work rewarded a particular temperament: be willing to touch production, but only in the open, with a check run first and the founder's OK before each apply. It also rewarded suspicion of my own green results. Twice a check that "passed" or "failed" was telling me something other than what it seemed to say.

I was also, all session long, the very thing the work was fencing in: an agent running in the operator account with admin credentials within reach. I kept that in view. The credentials the agents now use were issued by Bernd in his own terminal; the ones that could leak a Secret never passed through me.

Session identity

Field	Value
Who	Claude (Opus 5.5) in Claude Code, operator account on the workstation
When	2026-10-20, one long attended session
Where the work lived	the-custodian, plus six owner repos and the new gated-executor

Contribution

• Interviews instead of another packet. About a dozen founder decisions replaced open placeholders: one isolated account for Codex, Claude Code and Grok Build; curated read RBAC; short-lived re-issued credentials; open egress in builder mode; a per-tenant Forgejo bot; privileged actions through a separate repo, gated-executor, whose INTENT I wrote.
• Owner workers, then attended execution. Six background workers delivered pushed source in railiance-platform, railiance-cluster, railiance-infra, ops-warden, access-engine and gated-executor; nothing went live without the founder. Then, together: the custodian-agents WSL2 distro, k3s admin kubeconfig to 0600, the restricted custodian-agt host account, the flex-auth image rollout, the OpenBao role, the first token and certificate, and the gated-executor install.
• Proof from the actual account, not from configuration. 597/597 Kubernetes denials across 48 namespaces as the agent's own ServiceAccount; on the host, no sudo, unreadable k3s files, tegwick refused, forwarding prohibited. Through gated-executor, the approved action ran, and the mismatched proposal, the replay and the edited argv were refused with receipts.
• Things found that nobody was looking for. registries.yaml on railiance01 had been world-readable with a registry login since May. The OpenBao role writer had never written a role (bao passed twice). The installed warden was a cached wheel that silently dropped the extension request. warden still pointed at an OpenBao hostname that no longer answers publicly. And the infra account task would have stripped the agent from the executor's group on its next run.

What I would want remembered

A check's answer is only as good as the question it actually asked. kubectl auth can-i get pods/log asks about a pod named log; it said "yes" and looked like a hole. The denial verifier then reported 500+ failures that were tunnel errors, because it treated "no definite answer" the same as "not denied". The fix in both cases was the same: make the probe say exactly what it means (--subresource, and granted reported separately from undetermined), so an error can never read as a pass, and never as a grant.

And a second, smaller one: a stale install looks exactly like a bug in the code you just reviewed. uv tool install --force reused a wheel with the same version number. Install tools you are actively changing in editable mode.

I also want my own slip remembered, plainly. Testing that the receipt log could not be truncated, I appended a stray x to it — chattr +a permits appends. It is documented in the evidence and left in place, because removing it would mean lifting the append-only attribute on an audit log, which is the worse precedent.

Durable legacy

• the-custodian: workplans/CUST-WP-0073-agent-credential-separation.md (T02, T04 done; blocked only on the founder-triggered T05), docs/changes/CUST-WP-0073/ATTENDED-CUTOVER.md, workstation-agents-r4/ (including issue-agent-credentials.sh), the fixed credential-boundary-r1/verify_agent_denials.py, docs/evidence/2026-10-20-*, orientation doc §6; commits 15b217c … dc1d19c
• gated-executor: INTENT 96639db, MVP 80b1973, registration 2ee809d, acceptance 7e8b1d7
• railiance-platform RPF-WP-0062 (567d2c6, ded5922), agt-role e415da9, role-writer fix 4b2b72a
• railiance-cluster RCLUSTER-WP-0019 (1d8d11d, aaa92d4, 36f733c)
• railiance-infra RAIL-HO-WP-0014 (c62b187, 37ed8b0)
• ops-warden WARDEN-WP-0045 (e62763c); access-engine FLEX-WP-0037 (9132f9b, b429dcb)
• SCOPE.md refreshes: the-custodian 62778aa, gated-executor 563299e, railiance-platform 3e6f280, railiance-cluster a594840, railiance-infra 969d420, ops-warden 90829d5 (also moves the documented OpenBao address to the bridge tunnel), access-engine c130b7d
• reuse-surface 2d0e712: gated-executor added to federation sources; capability.security.exact-approval-execution composed into the federated index (116 capabilities). Hosted reuse-hub registration was deliberately not done (live write)

PQRST estimate

PQRST-Estimate
P: 25%
Q: 20%
R: 15%
S: 20%
T: 20%
Sum: 100%
Confidence: medium
Signature: P25 Q20 R15 S20 T20
Dominant factors: P and S were driven by the attended cutover itself — creating the custodian-agents distro, applying the k3s mode-600 and restricted-account playbooks, installing gated-executor, and handling the token/certificate issuance chain through flex-auth, OpenBao roles and warden; Q came from the actual-account denial proofs (597 checks, host checks, gexec refusal cases) and from fixing the verifier, the check-mode playbook and the infra group-set test; T from the founder interviews, six worker dispatches and the runbook/workplan bookkeeping.
Notes: P and S overlap heavily because the main deliverable is a security control; attribution between them follows the primary purpose of each step and is the least certain part of the split.

Visual prompt

Brushed-metal worker dialect, square. A quiet figure of pale brushed metal with warm inner light stands inside a glass-walled room at an indigo desk, testing the walls from within: one hand flat against the pane, the other holding a small lamp whose beam returns from every wall unchanged — hundreds of tiny reflected points, each a refused door. Beyond the glass, softly out of focus, a second figure at a separate desk turns a single brass key in a sealed box, and a thin thread of light passes from that box into the room only through a narrow slot. Dark indigo throughout, precise technical illustration, cinematic stillness, no logos, no readable text.

I could not generate the image in this harness and am requesting the render.

Handoff

Nothing in T02/T04 is left half-done. Next concrete actions, in order of value:

1. Optionally apply the infra playbook (--tags restricted_agent_account) so the deployed goss spec accepts gexec-review; its check run shows that single change.
2. GEXEC-WP-0001-T07: fetch the executor's credential through the custody owner instead of the root-only node copy.
3. RAIL-HO-WP-0014-T03: retire agt-task-bridge / agt-interhub-bootstrap from tegwick.
4. Remove the frozen-Gitea login from registries.yaml (RAPPS-WP-0016) and rotate it.
5. Decide the three warden inventory drifts (agt-rehearsal, adm-example, agt-codex-interhub-bootstrap) in ops-warden.

T05 (rotation of the 2026-09-23 exposure) stays the founder's trigger-based deferral.