Files

tegwick bd335ec724 feat(WARDEN-WP-0019): route secret-exec lanes to secrets-engine (route-primary, proxy fallback)

secrets-engine (SECRETS-WP-0003) shipped a native secret-exec front door
(`secrets-engine route/exec`, decision e6381a56) and asked ops-warden to route to it.
Bernd's call: route-primary, proxy-fallback — surface the secrets-engine exec as the
primary path for owned lanes, keep `warden access --exec` as a transparent fallback.

T1 — RouteEntry gains exec_owner/exec_command/pointer_command (+ has_native_exec),
screened for secret material like the other handoff fields. whynot-design-npm-publish
points its native exec at secrets-engine. `warden access` renders Primary (secrets-engine
exec) + Fallback (warden proxy); route/access JSON gain the fields and a native-exec-aware
next_action. Tests added; 217 pass, lint clean.

T2 — credential-routing.md adds secrets-engine as the secret-exec owner (route primary,
proxy fallback); SCOPE adds secrets-engine to Related Repos and records the npm lane as
production-exercised (@whynot/design@0.4.0); playbook leads with secrets-engine exec and
fixes the fallback one-liner (--field NPM_AUTH_TOKEN, --no-policy) per whynot-design.

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

2026-06-29 17:41:49 +02:00

4.2 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`
Provisioned secret-exec lane (e.g. npm publish)	secrets-engine	Route — primary is `secrets-engine exec --catalog <id> -- <cmd>`; `warden access <id> --exec` is the transparent fallback
Generic 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

For an owned lane, warden route find <need> --json / warden access <id> surface exec_owner, the secrets-engine exec command, and the resolvable flag. Run the secrets-engine command; ops-warden routes to it and requests/holds no token.

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

4.2 KiB Raw Blame History