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>
This commit is contained in:
2026-06-27 21:02:46 +02:00
parent 55c3404741
commit 46b340f45f
6 changed files with 210 additions and 21 deletions

View File

@@ -4,9 +4,15 @@
for inference. Run this check **before** requesting secrets, API keys, SSH access,
login tokens, or database passwords — in any repo, not only `ops-warden`.
ops-warden **issues SSH certificates only** (`warden sign`, `cert_command`). Every
other credential need belongs to another subsystem. **Do not** message
`ops-warden` on State Hub expecting a secret value; the reply is a pointer, not a key.
ops-warden **issues SSH certificates** (`warden sign`, `cert_command`) **and is the
operator access front door** for every other credential need. For `exec_capable` lanes
(OpenBao reads, key-cape login) `warden access <need> --fetch/--exec` **proxies the fetch
as you** — it runs the owner's tool with your identity and streams the value to you;
ops-warden holds, caches, and logs nothing. For non-exec lanes it points you at the owner.
**Do not** `POST /messages/` to `ops-warden` expecting a secret *value* — a State Hub
reply is always a pointer. The **value comes from the CLI front door** (`warden access`),
run with **your** identity, never from the inbox.
### Lookup (do this first)
@@ -31,14 +37,14 @@ Requires the `warden` CLI from `~/ops-warden` (`uv tool install .` or `uv run wa
### Quick routing table
| I need… | Owner | ops-warden executes? |
| I need… | Owner | ops-warden role |
| --- | --- | --- |
| SSH cert (`adm`/`agt`/`atm`) | ops-warden | **Yes**`warden sign` |
| API key, DB password, provider token | OpenBao (`railiance-platform`) | No — route only |
| Login / OIDC / MFA | key-cape / Keycloak | No — route only |
| Authorization decision | flex-auth | No — route only |
| activity-core → issue-core emission | activity-core + issue-core | No`warden route show activity-core-issue-sink` |
| SSH tunnel | ops-bridge (+ `cert_command` from warden) | No — route only |
| SSH cert (`adm`/`agt`/`atm`) | ops-warden | **Issue**`warden sign` |
| API key, DB password, provider token | OpenBao (`railiance-platform`) | **Assist**`warden access <need> --fetch/--exec` proxies as you; OpenBao keeps custody |
| Login / OIDC / MFA | key-cape / Keycloak | **Assist**`warden access <need> --fetch` runs the login as you |
| Authorization decision | flex-auth | Route only |
| activity-core → issue-core emission | activity-core + issue-core | Route`warden route show activity-core-issue-sink` |
| SSH tunnel | ops-bridge (+ `cert_command` from warden) | Route only |
### Anti-patterns (do not do these)