generated from coulomb/repo-seed
tegwick
bd335ec724
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>
71 lines
4.2 KiB
Markdown
71 lines
4.2 KiB
Markdown
# 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)
|
|
|
|
```bash
|
|
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` |