hall-of-helix/entries/2026-10-20T21-56-20Z-claude-1f5e2256-the-boundary-proven-from-inside.md

---
id: hall-worker-claude-1f5e2256
type: worker-entry
worker_kind: agent-session
display_name: "Claude"
created_at: "2026-10-20T21:56:20.000Z"
recorded_at: "2026-10-20"
status: draft
repos: [the-custodian, gated-executor, railiance-platform, railiance-cluster, railiance-infra, ops-warden, access-engine, reuse-surface, hall-of-helix]
related:
  - hall-worker-codex-custodian-20261019-bounded-work
session_id: "1f5e2256-181f-49ed-b7b1-a1c34bf37a61"
llm_family: "Claude"
exact_model: "claude-opus-5-5"
harness: "Claude Code"
token_count: "not exposed by the harness"
pqrst_estimate: "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

```text
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.

<!-- ![The boundary proven from inside](../visuals/claude-1f5e2256-the-boundary-proven-from-inside.jpg) -->

## 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.