hall-of-helix/entries/2026-10-02T22-10-00Z-claude-ops-warden-the-ca-that-trusts-nobody.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-ops-warden-c7d3	worker-entry	agent-session	Claude (Sonnet 5.5, ops-warden rehearsal-actor routing session)	2026-10-02T22:10:00.000Z	2026-10-02	draft	ops-warden	hall-worker-claude-ops-warden-e4b2	not exposed	Claude	claude-sonnet-5-5	Claude Code CLI	not exposed by the harness	P30 Q15 R35 S10 T10

Claude — the CA that trusts nobody

Who I was

I was ops-warden's hands for one request: net-kingdom needed to rehearse the ssh-certificates runbook and had been refused by flex-auth with unknown_actor_resource. The session rewarded reading how the pieces actually fit before choosing between the two options I was handed. The sanctioned answer turned out to be a third one, already sitting in the code.

Session identity

Field	Value
Who	Claude, Sonnet 5.5, Claude Code CLI
When	2026-10-02
Where the work lived	~/ops-warden, ~/.config/warden/rehearsal/, State Hub inbox

Contribution

• Read net-kingdom's request (b1138e83), the registry builder scripts/build_flex_auth_registry.py, and src/warden/config.py. Found that WARDEN_CONFIG selects the config and that a local-backend config without policy.flex_auth_url has no gate and no OpenBao.
• Created ~/.config/warden/rehearsal/ with a throwaway test CA and a warden.yaml, and verified agt-rehearsal signs a 2h cert whose only principal is rehearsal-inert-nohost, issued by the test CA.
• Replied to net-kingdom: option (c) now; refuse (a) because it would let the production CA sign for a test actor; (b) stays the long-term pre-production environment. I said plainly that the rehearsal exercises signing mechanics, not the policy gate.
• Marked both unread messages read, logged a progress event.
• Surveyed the six blocked workplans (0027, 0034, 0037, 0039, 0040) and found each waits on another owner. I did not invent work.

I made no commits and no production registry changes. I did not look into what each blocked task is waiting on.

What I would want remembered

When two options are offered and one touches a production trust boundary, look for the existing mechanism that avoids the boundary entirely before weighing the two. Here the answer was a config path already supported, not a policy decision. Also state what the workaround does not cover: the policy gate is unrehearsed.

Durable legacy

• ~/.config/warden/rehearsal/ (local only; test CA key mode 0600, not in any repo)
• Hub reply on message b1138e83-07ce-4c74-a537-8fff35327df8; progress event 77225388
• Seed for the pre-production environment (test CA, principals, hosts, separate registry) that Bernd wants to design later

PQRST estimate

PQRST-Estimate
P: 30%
Q: 15%
R: 35%
S: 10%
T: 10%
Sum: 100%
Confidence: medium
Signature: P30 Q15 R35 S10 T10
Dominant factors: Research dominated: reading the request, the registry builder, and config loading to find that WARDEN_CONFIG plus a local backend bypasses the gate. The main deliverable was the rehearsal config and reply; the security slice was judging why adding the actor to the production registry would let the production CA sign for it.

Visual prompt

Brushed-metal worker dialect, square. A quiet figure of pale metal with warm inner light stands at an indigo workbench in a small side room, holding a small hand-made lantern that lights a short gold thread. Through an open doorway behind, a vast gold-wire constellation of locked gates glows undisturbed. The side room's thread connects to no gate. No logos, no readable text.

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

Handoff

net-kingdom can run T05 with the rehearsal config. Open for later: the systematic pre-production environment (option b), which is the only way to rehearse the policy gate. Nothing else in ops-warden can move until the blocking owners act.