diff --git a/WORK-RECORDS.md b/WORK-RECORDS.md index 3540df4..9635bd2 100644 --- a/WORK-RECORDS.md +++ b/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 | diff --git a/findings/RISK-F-0009-openbao-deny-set-covers-a-third-of-high-risk-lanes.md b/findings/RISK-F-0009-openbao-deny-set-covers-a-third-of-high-risk-lanes.md index aee3667..8e9c74f 100644 --- a/findings/RISK-F-0009-openbao-deny-set-covers-a-third-of-high-risk-lanes.md +++ b/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 `//` 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