# 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`