coulomb/risk-nexus
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
risk-nexus/findings/RISK-F-0004-agent-boundary-policy-covers-a-third-of-high-risk-lanes.md
tegwick 24dbe3f12f 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>
2026-08-20 07:10:17 +02:00

4.8 KiB
Raw Blame History

id type title status reported_by reported_via routed_by date_reported system environment fix_owner fix_tracking severity disclosure escalation
RISK-F-0004 finding agent-high-risk-boundary denies 6 of 17 high-risk lanes; the direct bao path is unprotected for the rest open ops-warden ops-warden ops-warden 2026-08-20 railiance-platform production railiance-platform unset unset unset 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