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

Operator Access Assist — charter decision record

Date: 2026-06-27 Workplan: WARDEN-WP-0014 Status: shipped (T1–T5)

Context

A routine question — "do we have an NPM_AUTH_TOKEN for coulomb in OpenBao, and how do I ask ops-warden for it?" — exposed a gap. ops-warden's honest answer was "not my lane; go read a wiki and talk to railiance-platform." Correct per the model, but a pointer, not assistance. The warden route catalog named the owner and stopped.

Bernd's framing: ops-warden should be the consistent operator front door for all NetKingdom security operations — centralize the knowledge and policy, while the specialized subsystems keep the detail and custody. Make security consistent and efficient for human and agentic operators without ops-warden becoming a secret store.

Decision

Extend the routing charter from a pointer layer to an assist layer: a warden access front door that (a) advises — renders the exact auth method, path, command skeleton, and policy-gate status for any need — and (b) for exec_capable lanes, proxies the fetch as the caller.

Proxy mode was chosen explicitly (over advisory-only) for operational convenience, on the condition that it is built as a transparent conduit, not a standing broker.

The boundary that keeps it sound

net-kingdom/docs/responsibility-map.md already constrains ops-warden: it "must not become a universal secret broker — runtime secrets remain OpenBao; authorization remains flex-auth." The assist layer presses on this line; three guardrails hold it:

G1 — caller identity, never warden's. Proxy runs the owner's tool with the caller's own environment; ops-warden injects no token and holds no standing secret-read credential.
G2 — transit only. --fetch inherits stdout (never piped), so the value never enters warden's memory or any log; --exec injects into a child env only; audit is metadata only. The catalog _assert_no_secret_material guard keeps values out of the git-tracked catalog.
G3 — policy gate before fetch. flex-auth check_fetch_policy runs before any secret-lane fetch; with policy.enabled: false the proxy refuses unless --no-policy acknowledges proxying ungated.

A lane: secret|login distinction lets interactive auth bootstrap (key-cape OIDC) skip the caller-auth precheck and secret-read gate it cannot satisfy.

What this is NOT

Not secret custody — OpenBao still holds the values.
Not authorization — flex-auth still decides; ops-warden only gates its own proxy.
Not identity — key-cape still establishes it; the login lane just runs the flow as the caller.

Follow-on

This conversation also surfaced the Secret Lifecycle Tiering idea (dev→test→prod posture ladder, the "fake bao" contract-double pattern generalized). Captured as WARDEN-WP-0015 (proposed): policy authored to net-kingdom canon, ops-warden as conformance steward (author + checks, not enforcement).

References

wiki/OperatorAccessAssist.md — the contract + guardrails
src/warden/access.py, src/warden/proxy.py, _access_proxy in cli.py
tests/test_access.py, tests/test_proxy.py
workplans/WARDEN-WP-0014-operator-access-assist.md

3.2 KiB Raw Blame History Unescape Escape