--- id: RISK-F-0003 type: finding title: "ops-warden agent read-boundary does not fire on ungraded catalog lanes" status: open reported_by: ops-warden reported_via: ops-warden routed_by: ops-warden date_reported: "2026-08-19" system: ops-warden environment: production fix_owner: ops-warden fix_tracking: WARDEN-WP-0032-T05 # Graded by risk-nexus 2026-08-19 — docs/rulings/2026-08-19-first-grading.md severity: high severity_at_production: high impact: I4 likelihood: L2 fidelity_modifier: false production_rescore: false disclosure: embargoed embargo_condition: "the five exec_capable lanes graded under WARDEN-WP-0032-T05" embargo_since: "2026-08-19" embargo_review: "2026-09-18" escalation: none last_reviewed: "2026-08-19" review_by: "2026-09-18" graded_by: risk-nexus ruling: RISK-RULING-2026-08-19 --- # RISK-F-0003 — the agent read-boundary has a fourteen-lane blind spot ## What is true `ADR-0004` (ops-warden) states that high-risk lanes refuse raw value streaming to agent sessions. It is implemented in `src/warden/cli.py:1245`: ```python if raw_value_stream and entry.is_high_risk and agent_id: ``` and `is_high_risk` is defined in `src/warden/routing/models.py:123` as: ```python return self.risk == "high" ``` `risk` is an **optional** field on a catalog entry. Of the 27 entries in `registry/routing/catalog.yaml`, **14 carry no `risk` value at all**. For those, `is_high_risk` is `False`, so the boundary never fires regardless of what the lane actually vends. Five of the fourteen are `exec_capable: true`, meaning `warden access --fetch` can proxy a real value for them: | Lane | Owner | Status | | --- | --- | --- | | `openbao-api-key` | railiance-platform | active | | `whynot-design-npm-publish` | railiance-platform | active | | `key-cape-oidc-login` | key-cape | active | | `issue-core-ingestion-api-key` | railiance-platform | active | | `reuse-surface-hub-write-token` | railiance-platform | active | For these five, an agent session with `WARDEN_AGENT_ID` set can stream a secret value to stdout, which is the disclosure pattern of 2026-07-16 that WP-0026 and `ADR-0004` were written to prevent. The control is not bypassed; it is simply never reached. ## Why it matters beyond these five The failure mode is **omission, not error**. Adding a lane without a `risk` value produces a lane outside the boundary, silently, with no warning at load and nothing in CI that notices. Every future lane inherits this default. The nine other ungraded lanes are not `exec_capable` today, but `exec_capable` is itself an editable field. `ADR-0004` reads as a categorical rule. The implementation is an opt-in list. ## Exposure — stated only as far as ops-warden can support it - ops-warden is the affected system and owns the catalog, the ADR, and the code. - `WARDEN_AGENT_ID` is set by agent harnesses; ops-warden has not enumerated which sessions currently set it, so the population actually exposed is **not established** and should not be assumed to be zero or large. - There is a second, independent layer for OpenBao-backed lanes: the OpenBao policy `agent-high-risk-boundary` denies data-read for agent tokens on the paths it covers. Whether it covers these five paths **has not been verified by ops-warden** and should be checked against the live policy rather than inferred — the paths were graded by the same omission this finding is about. - No evidence of an actual disclosure through these lanes has been sought or found. This is a control gap, not a known incident. ## How it was found Doing `ZONE-WP-0001-T02` (zone-engine) — partitioning the estate for the security-zone model. Grading every lane on `risk` was a prerequisite for deriving zone membership, and the count of ungraded lanes is what surfaced it. ## Suggested direction, not a prescription Two candidate fixes, both ops-warden's to choose between: 1. **Invert the default.** Treat absent `risk` as high, so a new lane is protected until deliberately graded down. Fails safe; may be noisy. 2. **Make `risk` required**, enforced at catalog load and in CI, so an ungraded lane cannot be committed. Fails loud; requires grading 14 lanes now. Either way the grading is real work with real judgement in it, and the five `exec_capable` lanes are the ones that matter first. **Update 2026-08-19 — a third direction, and the one being taken.** The operator has directed that the default derive from **maturity context**: in an early or experimental context an absent grade is tolerable and explicitly accepted; in a production context an absent grade resolves to `high`, or `critical` where the context is critical. This validates against the data here — all five exposed lanes are owned by production-serving components, so the rule would have caught every one. The durable form of that is a zone-model question (`ZONE-WP-0001-T03`), because the `M0`-`M3` maturity ladder that would drive it has no join to catalog lanes today. That work is months out, so the two are being run separately: the five lanes are graded explicitly now under `WARDEN-WP-0032-T05`, and the structural fix that makes absence impossible follows under `WARDEN-WP-0032-T06`. Note for whoever sets severity: `.repo-classification.yaml` `category` is **not** usable as the maturity signal. `railiance-platform`, which runs production OpenBao and owns three of the five lanes above, is `category: tooling`. ## Related - ops-warden `ADR-0004` — high-risk lanes refuse raw value streaming - ops-warden `WP-0026` — disclosure hygiene, safe fetch transports - `wiki/playbooks/agent-read-boundary.md` - `RISK-F-0002` — ops-warden sign ungated (same system, different control) - `zone-engine` `ZONE-WP-0001-T02` — the work that surfaced this ## Register ruling — 2026-08-19 `high` (`I4` × `L2`), embargoed until the five `exec_capable` lanes are graded under `WARDEN-WP-0032-T05`, no escalation. **Graded on its worst lane.** Four of the five are `I3`-shaped — a publish token, an OIDC login, an ingestion key, a hub write token, each bad inside its own system. `openbao-api-key` is not: it reaches the store the estate's other secrets live in, and a disclosure there propagates past every boundary the others respect. **Likelihood `L2`** — an agent session with `WARDEN_AGENT_ID` is a foothold the estate does grant. The register holds the line this finding drew: the exposed population is not established, so it is neither assumed zero nor assumed large, and the unverified OpenBao `agent-high-risk-boundary` coverage is a review question rather than an assumption in either direction. Confirming that coverage for these five paths would lower the grade. **No fidelity modifier, and it was close.** `ADR-0004` reads categorical while the implementation is opt-in, so the documentation asserts a boundary that does not exist for 14 lanes. The modifier is scoped to attestations a system produces at runtime, and documentation drift is not that. But if any compliance evidence anywhere cites `ADR-0004` as implemented, that *is* a false attestation and a separate finding. This register has not looked, and says so rather than assuming. **No escalation.** Known, owned, tracked (`WARDEN-WP-0032-T05` for the five lanes, `WARDEN-WP-0032-T06` for the structural fix), and moving. Severity alone deliberately does not reach the operator. **On the maturity-context direction**, which is the operator's and not re-decided here: the note that `.repo-classification.yaml` `category` cannot carry the signal is confirmed from this repo's own registration work today. `railiance-platform` runs production OpenBao and owns three of the five lanes while classified `tooling`; `risk-nexus` classified itself with the same vocabulary an hour ago. The maturity ladder needs its own field, and that is `ZONE-WP-0001-T03`'s to build. Reasoning: `docs/rulings/2026-08-19-first-grading.md`. ## Reviews - **2026-08-19** — graded. Next review 2026-09-18 (`high` → 30 days). Open at review: OpenBao policy coverage of the five paths; whether `WARDEN-WP-0032-T05` has landed; whether any compliance evidence cites `ADR-0004` as implemented.