From 24dbe3f12fe818791642bdc438e9a3ed2fbdf7e6 Mon Sep 17 00:00:00 2001 From: tegwick Date: Thu, 20 Aug 2026 07:10:17 +0200 Subject: [PATCH] =?UTF-8?q?RISK-F-0004=20=E2=80=94=20agent-high-risk-bound?= =?UTF-8?q?ary=20covers=206=20of=2017=20high-risk=20lanes?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 --- ...olicy-covers-a-third-of-high-risk-lanes.md | 103 ++++++++++++++++++ 1 file changed, 103 insertions(+) create mode 100644 findings/RISK-F-0004-agent-boundary-policy-covers-a-third-of-high-risk-lanes.md diff --git a/findings/RISK-F-0004-agent-boundary-policy-covers-a-third-of-high-risk-lanes.md b/findings/RISK-F-0004-agent-boundary-policy-covers-a-third-of-high-risk-lanes.md new file mode 100644 index 0000000..2ea2c51 --- /dev/null +++ b/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 --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///` — 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`