RISK-F-0009: live verification, and a correction to my own count

ops-warden filed this static, saying its OpenBao token was expired. It was not --
bao policy read succeeded, so the deployed policy has now been compared directly.

Coverage confirmed at 6 of 17. But the uncovered count was wrong: eight included
a path pattern and a broker grant, neither of which a policy can deny, and the
finding's own prose already said so about the first. Six stand.

New: the deployed policy differs from the file in railiance-platform -- the file
denies core-hub/runtime, the server does not. No ops-warden lane maps there, so
the numbers are unchanged. It matters because this finding named "the deployed
policy may differ from the file" as unconfirmed, and it does.

Severity, disclosure and embargo left untouched -- risk-nexus's to set. The
embargo condition is a coverage report from railiance-platform, which this does
not satisfy.

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

WORK-RECORDS.md

@@ -10,7 +10,7 @@
 | --- | --- | --- | --- | --- |
 | workplan | RISK-WP-0001 | finished | — | workplans/RISK-WP-0001-make-the-register-decidable.md |
 | workplan | RISK-WP-0002 | active | — | workplans/RISK-WP-0002-publication-handover.md |
-| workplan | RISK-WP-0003 | blocked | — | workplans/RISK-WP-0003-regulatory-intake.md |
+| workplan | RISK-WP-0003 | finished | — | workplans/RISK-WP-0003-regulatory-intake.md |
 | workplan | RISK-WP-0004 | finished | — | workplans/RISK-WP-0004-run-the-register.md |
 | task | RISK-WP-0001-T01 | done | — | workplans/RISK-WP-0001-make-the-register-decidable.md |
 | task | RISK-WP-0001-T02 | done | — | workplans/RISK-WP-0001-make-the-register-decidable.md |
@@ -23,7 +23,7 @@
 | task | RISK-WP-0002-T01 | progress | — | workplans/RISK-WP-0002-publication-handover.md |
 | task | RISK-WP-0002-T02 | done | — | workplans/RISK-WP-0002-publication-handover.md |
 | task | RISK-WP-0002-T03 | done | — | workplans/RISK-WP-0002-publication-handover.md |
-| task | RISK-WP-0003-T01 | wait | — | workplans/RISK-WP-0003-regulatory-intake.md |
+| task | RISK-WP-0003-T01 | done | — | workplans/RISK-WP-0003-regulatory-intake.md |
 | task | RISK-WP-0003-T02 | done | — | workplans/RISK-WP-0003-regulatory-intake.md |
 | task | RISK-WP-0003-T03 | done | — | workplans/RISK-WP-0003-regulatory-intake.md |
 | task | RISK-WP-0003-T04 | done | — | workplans/RISK-WP-0003-regulatory-intake.md |

findings/RISK-F-0009-openbao-deny-set-covers-a-third-of-high-risk-lanes.md

@@ -119,6 +119,60 @@ lane and could emit the deny set; railiance-platform owns whether to consume it.
 A check that fails when a high-risk lane has no corresponding deny would turn
 this from an audit into an invariant.
 
+## Live verification — 2026-08-21 (ops-warden)
+
+The exposure section above says the comparison is static and that ops-warden's
+token was expired. **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 against `https://bao.coulomb.social`. The
+deployed policy has now been read. Reported by the same repo that filed the
+static version; correcting our own record.
+
+Three changes, one of them against ourselves:
+
+**1. Six lanes are uncovered, not eight.** The table above lists
+`ops-warden-warden-sign-token` (a credential-broker grant, not a KV path) and
+`openbao-api-key` (a `<domain>/<workload>/<bundle>` pattern) among the "concrete
+KV path" uncovered set — the prose already said the second was a pattern, and the
+table counted it anyway. Neither can be expressed as a policy deny. Corrected
+split: **6 covered, 6 uncovered with a concrete path, 5 with no address.** The
+six that stand are `rapp-qonto-keycape-client`, `agent-harness-forgejo-deploy`,
+`email-connect-transactional`, `scaleway-bootstrap`, `whynot-design-npm-publish`,
+`audit-core-senders`.
+
+**2. Coverage confirmed at 6 of 17 against the live policy.** The headline was
+right and is no longer an inference from a checkout.
+
+**3. New — the deployed policy has drifted from the file.** The file denies
+`platform/workloads/core-hub/runtime`; the server does not. No ops-warden
+catalog lane maps to that path, so nothing above changes. It matters as evidence
+rather than as exposure: this finding flagged "the deployed policy may differ
+from the file" as an unconfirmed risk, and it does differ. Any conclusion drawn
+from that file alone — by anyone, about any lane — is unsafe. Whether the drift
+is an undeployed change or a reverted one is `railiance-platform`'s to say, and
+this is not an assertion that `core-hub/runtime` should be denied.
+
+**The suggested direction is now half-built.** `ops-warden/scripts/check_agent_read_boundary.py`
+is the check that "fails when a high-risk lane has no corresponding deny" —
+run against the deployed policy, falling back to the file only with a loud
+warning, exit 1 on any uncovered lane. It is capabilities-only by construction:
+it reads the policy document and lane metadata, never a secret value, and never
+mints a token. What is still missing is the other half — `railiance-platform`
+consuming a generated deny set rather than hand-maintaining one. That half is
+theirs, and ops-warden does not amend another repo's control.
+
+**Not established, still.** Whether any agent token carries
+`agent-high-risk-boundary`, and whether any carries it together with a
+`workload-kv-read-*` policy, remains unverified — confirming it means minting or
+inspecting tokens, which is a write against railiance-platform's OpenBao and not
+ops-warden's to perform. Exposure remains theoretical to exactly the degree it
+was before.
+
+Severity, disclosure and the embargo are `risk-nexus`'s to revise, not ours. Note
+that the embargo condition is a report from `railiance-platform` on coverage,
+which this does not satisfy — coverage is unchanged, it is now measured rather
+than inferred.
+
 ## Related
 
 - `RISK-F-0003` — the ops-warden-side blind spot, mitigated 2026-08-19