coulomb/ops-warden
4
0
Fork 0
Code Issues Pull requests Projects Releases 2 Packages Wiki Activity Actions

WARDEN-WP-0032-T06: record the live verification, and that the blocker was stale
All checks were successful
CI Smoke / host-smoke (push) Successful in 0s
Details
CI Smoke / container-smoke (push) Successful in 1s
Details

Browse source 
The token was never expired and the verification script was never written. Both
were recorded here as fact for a day. Noting it as an instance of the re-read-
your-blockers rule rather than quietly correcting it.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
tegwick 2026-08-21 00:50:45 +02:00
parent edb587851c
commit 0dafb53e84
1 changed files with 36 additions and 6 deletions
Download patch file Download diff file Expand all files Collapse all files

42
workplans/WARDEN-WP-0032-security-zones.md
View file

@ -293,12 +293,42 @@ direct `bao kv get`, which is the actual 2026-07-16 vector.
Routed to `risk-nexus` as **`RISK-F-0004`**, `fix_owner: railiance-platform` —
the policy is theirs, and ops-warden does not amend another repo's control.
**Live confirmation still outstanding.** ops-warden's OpenBao token is expired
(`bao token lookup` → 403), so `bao policy read` and `bao token capabilities`
could not be run and the deployed policy may differ from the file. A
capabilities-only verification script is ready and needs an operator
`bao login -method=oidc` to run; it is deliberately capabilities-only, never a
read.
**Live confirmation done 2026-08-21 — and the blocker was not real.** The
token was not expired: `bao token lookup` returned a valid `platform-admin`
token from an OIDC login, and `bao policy read agent-high-risk-boundary`
succeeded. No `bao login` was needed. Worth recording as a small instance of the
lesson `.claude/rules/finding-routing.md` already states — *re-read a blocker
before trusting it*. This one was a stale claim about the world, carried for a
day in both this workplan and `RISK-F-0009`.
The verification script also did not exist. It was described here as "ready",
and nothing was committed. `scripts/check_agent_read_boundary.py` now exists,
with tests, and is the invariant `RISK-F-0009` asked for rather than a one-off
audit: exit 1 when any high-risk lane has no corresponding deny. It prefers the
deployed policy and falls back to the file only with a loud warning, because
deployment drift is the thing it exists to catch. Capabilities-only by
construction — it reads the policy document and lane metadata, never a secret
value, and never mints a token.
Three results, one against ourselves:
1. **Coverage confirmed at 6 of 17** against the live policy — the headline was
right and is no longer inferred from a checkout.
2. **Six lanes uncovered, not eight.** `RISK-F-0009` counted `openbao-api-key`
(a `<domain>/<workload>/<bundle>` pattern) and `ops-warden-warden-sign-token`
(a broker grant, not KV) among the concrete uncovered paths, while its own
prose said the first was a pattern. Neither can be expressed as a deny.
Corrected: 6 covered, 6 uncovered, 5 with no address.
3. **The deployed policy has drifted from the file.** The file denies
`platform/workloads/core-hub/runtime`; the server does not. No ops-warden
lane maps there, so our numbers are unchanged — it matters as evidence, since
`RISK-F-0009` named exactly this divergence as its unconfirmed risk.
Still not established, and not ops-warden's to establish: whether any agent
token carries `agent-high-risk-boundary`, and whether any carries it together
with a `workload-kv-read-*` policy. Confirming that means minting or inspecting
tokens — a write against railiance-platform's OpenBao. Exposure stays theoretical
to the same degree as before.
**Still open:** whether the maturity-derived default replaces the `ungraded`
sentinel entirely (waits on `ZONE-WP-0001-T03`).