Files

tegwick 46b340f45f feat(WARDEN-WP-0017): make the access front door discoverable (not SSH-only)

WP-0014 made ops-warden the operator access front door (warden access --fetch/--exec
proxies an exec_capable secret as the caller), but every discovery surface still told
the pre-WP-0014 "SSH certs only, pointer not key" story — so agents like whynot-design
never found the proxy and concluded they had to message ops-warden for a token value.

Messaging/discoverability only; the conduit security model is unchanged (no custody,
no broker).

T1 — CLI: `warden route` table warden column is now three-valued (issue/assist/route);
route + access JSON gain warden_role + exec_capable and a proxy-aware next_action;
`warden access` closing line leads with "ops-warden can fetch this for you as the
caller" for exec_capable lanes (route-only lanes keep "owner vends").

T2 — .claude/rules/credential-routing.md reframed (lead + routing table role column);
SCOPE one-liner + a second capability block for the access front door.

T3 — registered the State Hub capability "Operator access front door (caller-identity
fetch proxy)" (the hub had no ops-warden security capability at all); messaged
whynot-design the corrected `warden access "npm auth token" --fetch/--exec` path.

210 tests pass, lint clean.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

2026-06-27 21:02:46 +02:00

4.9 KiB

Raw Blame History

id, type, title, domain, repo, status, owner, topic_slug, planning_priority, planning_order, created, updated

id	type	title	domain	repo	status	owner	topic_slug	planning_priority	planning_order	created	updated
WARDEN-WP-0017	workplan	Access front-door discoverability — stop reading as SSH-only	infotech	ops-warden	finished	claude	custodian	high	17	2026-06-27	2026-06-27

WARDEN-WP-0017 — Access front-door discoverability

Problem: WP-0014 made ops-warden the operator access front door — for exec_capable lanes (OpenBao reads, key-cape login) warden access <need> --fetch/--exec proxies the fetch as the caller and streams the value to them (ops-warden holds nothing). But every discovery surface still tells the pre-WP-0014 story, so agents (e.g. whynot-design needing NPM_AUTH_TOKEN) conclude "ops-warden only issues SSH certs and replies with a pointer, not a token" and never find the proxy.

Fix: propagate the WP-0014 conduit charter to the surfaces agents actually read. This is a messaging/discoverability change — no change to the security model: the conduit stays a conduit (no custody, no standing broker; the responsibility-map boundary holds).

Out of scope: ops-warden holding/brokering token values (that would override the WP-0014 charter); shipping the concrete OpenBao npm KV path (railiance-platform infra — tracked separately); any new fetch capability (the proxy already exists).

Depends on: WP-0014 (the proxy lane being described).

Surfaces that mislead today

Surface	Says now	Should say
`warden route` table `warden` column	binary `issue` / `route`	`issue` / `assist` (exec_capable) / `route`
`warden route` `--json`	no proxyability field	add `warden_role` + `exec_capable`
`warden access` closing line	"warden advises, the owner vends"	for exec_capable: "ops-warden can fetch this for you as the caller…"
`.claude/rules/credential-routing.md`	"issues SSH certs only… reply is a pointer, not a key"	issues SSH certs and is the access front door; exec_capable lanes proxy as you
Federated capability registry	only "SSH certificate issuance"	also "Operator access front door / caller-identity fetch proxy"
SCOPE one-liner + capability block	SSH + routing + posture	add the access-assist/proxy front door

Tasks

T1 — CLI discoverability: route role + access framing

id: WARDEN-WP-0017-T01
status: done
priority: high

warden route table: three-valued warden column — issue / assist (exec_capable) / route. _entry_summary JSON gains warden_role + exec_capable; route show JSON next_action surfaces the proxy for exec_capable lanes.
warden access closing line: for exec_capable lanes leads with "ops-warden can fetch this for you as the caller (--fetch/--exec); runs the owner's tool with your identity, value never held/cached/logged." Non-exec lanes keep "advises, owner vends." _access_json next_action mirrors it.
Tests in tests/test_routing.py (warden_role issue/assist) and tests/test_access.py (front-door framing for exec lane, owner-vends for route-only lane). 210 pass.

T2 — Agent rule + SCOPE reframe

id: WARDEN-WP-0017-T02
status: done
priority: high

.claude/rules/credential-routing.md: reframed the lead ("issues SSH certs and is the operator access front door…") and the quick routing table (ops-warden role column: Issue / Assist / Route). Kept the true anti-pattern: don't POST a State Hub message for a secret value — it comes from the CLI front door run as you.
SCOPE one-liner reframed to "steward and front door"; added a second capability block "Operator access front door (caller-identity fetch proxy)".

T3 — Federated capability registration

id: WARDEN-WP-0017-T03
status: done
priority: medium

Registered the State Hub capability "Operator access front door (caller-identity fetch proxy)" (id 708e46f6, repo ops-warden) — the hub had no ops-warden security capability before, so the front door was undiscoverable cross-domain.
Sent whynot-design (msg 83a3bb2e) the corrected path: warden access "npm auth token" --fetch/--exec, the CLI refresh, the OpenBao-auth prereq, and the railiance-platform path caveat.

Acceptance

An agent doing the first-line warden route find / --json lookup can see ops-warden assists (proxies) the OpenBao lane, not merely points.
The credential-routing rule and federated capability registry describe the access front door; none of them say "SSH certificates only".
The conduit boundary is unchanged and explicit: ops-warden fetches as the caller and holds nothing — no custody, no broker.

4.9 KiB Raw Blame History