RISK-F-0004 — agent-high-risk-boundary covers 6 of 17 high-risk lanes

Static comparison of ops-warden's catalog against the policy file: 8 high-risk
lanes with concrete KV paths are not denied, four of which were already graded
high before the 2026-08-19 regrade, so the divergence is pre-existing.

ops-warden's CLI layer only protects the ops-warden path; the OpenBao policy is
what protects a direct bao kv get, which is the actual 2026-07-16 vector.

Not confirmed against the live OpenBao — ops-warden's token is expired, so the
deployed policy may differ from the file. Stated as such.

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

findings/RISK-F-0004-agent-boundary-policy-covers-a-third-of-high-risk-lanes.md

@@ -0,0 +1,103 @@
+---
+id: RISK-F-0004
+type: finding
+title: "agent-high-risk-boundary denies 6 of 17 high-risk lanes; the direct bao path is unprotected for the rest"
+status: open
+reported_by: ops-warden
+reported_via: ops-warden
+routed_by: ops-warden
+date_reported: "2026-08-20"
+system: railiance-platform
+environment: production
+fix_owner: railiance-platform
+fix_tracking: unset
+severity: unset
+disclosure: unset
+escalation: unset
+---
+
+# RISK-F-0004 — the OpenBao half of the agent read-boundary covers a third of the lanes
+
+## What is true
+
+`ADR-0004` (ops-warden) is enforced in two independent layers:
+
+1. **ops-warden's CLI** — `warden access <lane> --fetch` exits 7 when
+   `WARDEN_AGENT_ID` is set and the lane is high-risk. Verified working for all
+   17 high-risk lanes as of 2026-08-20 (`WARDEN-WP-0032-T05`/`T06`).
+2. **OpenBao policy** `agent-high-risk-boundary`
+   (`railiance-platform/openbao/policies/agent-high-risk-boundary.hcl`) — denies
+   `data` read and permits `metadata` read for agent tokens.
+
+Layer 1 protects the ops-warden path. **Layer 2 is the one that protects the
+path an agent actually takes when it bypasses ops-warden** — a direct
+`bao kv get`, which is the 2026-07-16 disclosure vector.
+
+Comparing the policy's deny list against ops-warden's catalog:
+
+- **17** lanes graded `risk: high`
+- **5** data paths denied by the policy
+- **6** high-risk lanes covered (one policy path serves two lanes)
+- **8** high-risk lanes with a concrete KV path that the policy does **not** deny
+- **3** high-risk lanes with no KV path (policy not applicable)
+
+Not covered:
+
+| Lane | KV path | Newly graded 2026-08-19? |
+| --- | --- | --- |
+| `rapp-qonto-keycape-client` | `platform/workloads/rapp-qonto/keycape-client` | no — already `high` |
+| `agent-harness-forgejo-deploy` | `platform/workloads/agent-harness/forgejo-deploy-key` | no — already `high` |
+| `email-connect-transactional` | `platform/workloads/email-connect/transactional` | no — already `high` |
+| `scaleway-bootstrap` | `platform/workloads/railiance/scaleway/bootstrap` | no — already `high` |
+| `whynot-design-npm-publish` | `platform/workloads/coulomb/whynot-design/npm-publish` | yes |
+| `audit-core-senders` | `platform/workloads/audit-core/senders` | yes |
+| `ops-warden-warden-sign-token` | credential-broker grant, not a KV path | yes |
+| `openbao-api-key` | `platform/workloads/<domain>/<workload>/<bundle>` — a **pattern**, not a path | yes |
+
+**Four of the eight were already graded `high` before this analysis.** The
+divergence is therefore pre-existing and not a consequence of the 2026-08-19
+regrade; the regrade only made it visible by making the two lists comparable.
+
+## Why it matters
+
+ops-warden's layer can be bypassed by not using ops-warden. An agent session
+holding a `workload-kv-read-*` policy can `bao kv get` these paths directly, and
+for the eight above nothing denies it. The playbook
+(`ops-warden/wiki/playbooks/agent-read-boundary.md`) already states that an agent
+token carrying `agent-high-risk-boundary` **must not** also carry the lane's
+`workload-kv-read-*` policy — but that is an instruction to whoever mints the
+token, not a mechanism.
+
+## Exposure — stated only as far as ops-warden can support it
+
+- The comparison above is **static**, from the policy file in the
+  `railiance-platform` checkout and ops-warden's catalog. It has **not** been
+  confirmed against the live OpenBao. The operator token available to ops-warden
+  is expired (`bao token lookup` → 403), so `bao policy read` and
+  `bao token capabilities` could not be run. **The deployed policy may differ
+  from the file.**
+- Whether any agent token currently carries `agent-high-risk-boundary` at all,
+  and whether any carries it *together with* a `workload-kv-read-*` policy, is
+  **not established**. If no agent tokens exist, exposure is theoretical.
+- `openbao-api-key` is a routing lane whose `path_template` is a pattern rather
+  than an address; it is listed for completeness but probably cannot be
+  expressed as a policy deny and should be handled by grading the concrete lanes
+  it resolves to.
+- No evidence of an actual disclosure through these lanes has been sought or
+  found.
+
+## Suggested direction, not a prescription
+
+The two lists should be **generated from one source rather than maintained in
+two places** — that is what let them drift for four lanes without anyone
+noticing. ops-warden's catalog already carries `risk` and `path_template` per
+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.
+
+## Related
+
+- `RISK-F-0003` — the ops-warden-side blind spot, mitigated 2026-08-19
+- ops-warden `ADR-0004`, `ADR-0007`
+- `ops-warden/wiki/playbooks/agent-read-boundary.md`
+- `railiance-platform/openbao/policies/agent-high-risk-boundary.hcl`