Files

tegwick 5bbb791f21 docs(WARDEN-WP-0014): T5 — assist-layer docs, security model, INTENT/SCOPE

- wiki/OperatorAccessAssist.md: warden access contract, conduit-vs-broker
  boundary, the three guardrails + catalog secret guard, lane semantics.
- AccessRouting.md: issue/route/assist roles; reconciled the anti-pattern
  table so the transparent conduit no longer contradicts it.
- credential-routing.md rule: added warden access + "standing broker
  forbidden, transparent --fetch sanctioned" anti-pattern.
- INTENT.md: pointer→assist charter extension. SCOPE.md: implemented
  list + Getting Oriented + maturity A4→A5 (Availability).
- history decision record for the proxy-mode choice and guardrails.

WP-0014 finished (T1–T5). 172 passed, lint clean.

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

2026-06-27 17:35:57 +02:00

3.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 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.

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 executes?
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

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.2 KiB Raw Blame History