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

3.8 KiB

Raw Blame History

Credential and access routing

Audience: Codex, Claude Code, Grok, and custodian agents that call llm-connect 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 (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)

warden route find "<describe your need>" --json     # who owns it (pointer)
warden access "<describe your need>" --json          # how to get it (handoff)

warden access is the operator front door (WARDEN-WP-0014): it renders the owner, auth method, path template, command skeleton, and policy-gate status for any need. For exec_capable lanes it can proxy the fetch as you (--fetch/--exec) — it runs the owner's tool with your identity and streams the value to you; ops-warden never holds, caches, or logs the value. See wiki/OperatorAccessAssist.md.

Requires the warden CLI from ~/ops-warden (uv tool install . or uv run warden).

Agent runtime	How to orient
Codex / Grok (shell, HTTP State Hub)	`warden route` commands above; inbox `to_agent=ops-warden` is for coordination, not secret vending
Claude Code (MCP when available)	`get_domain_summary("custodian")` for workstreams; still use `warden route` for credential ownership
llm-connect (inference service)	Never put secret retrieval in prompts; route custody to OpenBao/operator paths surfaced by `warden route`

Quick routing table

I need…	Owner	ops-warden role
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)

POST /messages/ to ops-warden asking for ISSUE_CORE_API_KEY, OPENROUTER_API_KEY, etc.
Inventing warden secret, warden login, warden bao, warden tunnel — they do not exist
Pasting secrets into Git, State Hub, workplans, logs, or chat
Treating warden access --fetch as a secret store. It is a transparent conduit using your identity — it holds nothing. ops-warden as a standing broker (its own secret-read token, a cache of fetched values) is forbidden; runtime secret custody stays in OpenBao, authorization in flex-auth.

Other capabilities (reuse-surface)

Non-credential capabilities are usually discovered through reuse-surface federation (reuse-surface registry / capability.* indexes). Credential routing is inlined in every repo's agent instructions because it is high-frequency, high-risk, and easy to get wrong.

Canon: ~/ops-warden/wiki/CredentialRouting.md · catalog ~/ops-warden/registry/routing/catalog.yaml

3.8 KiB Raw Blame History