ops-warden/wiki/playbooks/rein-openweights-openrouter-approle.md

rein-openweights AppRole for non-interactive OpenRouter key read

Date: 2026-07-27 (promoted to active same day, after live verification) Catalog: rein-openweights-openrouter-approle (status active, resolvable: true) Owner: ops-mason (plans/rein-openweights-openrouter-approle.md) · consumer: rein-openweights glas-harness: GLAS-WP-0002-T02 (the demand this lane unblocks — closed)

An OpenRouter API key so rein-openweights (the OpenRouter-driven rein in the glas-harness family) can authenticate to OpenBao non-interactively — no operator OIDC session, no human in the loop at run time — the same shape agent-harness-binky-mail-approle already uses for its own AppRole lane.

Deliberately not a reuse of the existing openrouter-llm-connect lane: that lane's auth_method is interactive-caller-shaped and its policy is shared/high-risk across activity-core's broader usage. This lane is narrowly scoped to exactly one path, one consumer — see ops-mason/plans/rein-openweights-openrouter-approle.md §2 for the full reuse-vs-new reasoning.

---

OpenBao pointers

Field	Value
Mount	reins (new KV v2 engine, enabled 2026-07-27 — no existing mount fit without widening scope)
Path	reins/rein-openweights/openrouter
Field	api_key
Policy	workload-kv-read-rein-openweights-openrouter (read-only, scoped to exactly this path)
AppRole	rein-openweights
token_ttl / token_max_ttl	15m / 30m (matches agent-harness-binky-mail)
token_num_uses	8 (matches agent-harness-binky-mail — not OpenBao's own default of 0/unlimited, see build note below)
secret_id_ttl	0 (no expiry, current build-phase posture — same choice agent-harness-binky-mail made)
Risk	standard (single provider key, no data-store or infra access; bounded to this one path)

---

Worker checklist

For rein-openweights itself, non-interactive:

1. AppRole login (no operator present):

   ROLE_ID=$(cat ~/.local/rein-openweights/approle/role_id)
   SECRET_ID=$(cat ~/.local/rein-openweights/approle/secret_id)
   TOKEN=$(bao write -field=token auth/approle/login role_id="$ROLE_ID" secret_id="$SECRET_ID")
   

2. Fetch the field (matches rein_openweights/credentials.py's own resolve_openrouter_api_key() — this is exactly what that code does):

   BAO_TOKEN="$TOKEN" bao kv get -field=api_key reins/rein-openweights/openrouter
   

rein-openweights's own REIN_OPENWEIGHTS_APPROLE_DIR env var already defaults to the delivery path above; no code change needed to consume this lane once the value is provisioned.

---

Founder provision (the one place the live value exists outside OpenBao)

Done (2026-07-27) via warden desk --act paste_once_provision --path reins/rein-openweights/openrouter --field api_key. Two real issues hit along the way, both fixed at the root cause rather than patched around:

• platform-admin's own policy had no entry for the new reins/ mount (every other KV mount was already listed there; this one predated the fix) — the desk write 403'd until a matching path "reins/*" {...} block was added.
• The consumer policy itself (workload-kv-read-rein-openweights-openrouter) was originally written against the bare KV path — the KV v1 shape, which silently denies everything on a v2 mount. Fixed to grant on reins/data/rein-openweights/openrouter + reins/metadata/rein-openweights/openrouter instead (see ops-mason/plans/rein-openweights-openrouter-approle.md §7 for the full account, and ops_mason/executor.py::_policy_hcl for the code fix + regression test).

Field verified present (length only, never the value) after the fix. GLAS-WP-0002-T02's live verification then succeeded for real: AppRole login, KV v2 read, a real OpenRouter API call, a real commit — OPENROUTER_API_KEY unset throughout, so it was genuinely the vault path that ran.

Rotation

bao write -f auth/approle/role/rein-openweights/secret-id   # new secret_id
# deliver mode-0600 to REIN_OPENWEIGHTS_APPROLE_DIR; shred the old file

See also

• ops-mason/plans/rein-openweights-openrouter-approle.md — full construction plan, all four phases
• ops-mason/INTENT.md — the builder role this lane was provisioned through
• wiki/playbooks/agent-harness-secrets.md#lane-3-mail-approle — the closest existing analog this lane's shape was mirrored from