risk-nexus/findings/RISK-F-0003-ops-warden-read-boundary-ungraded-lanes.md

id	type	title	status	reported_by	reported_via	routed_by	date_reported	system	environment	fix_owner	fix_tracking	severity	disclosure	escalation
RISK-F-0003	finding	ops-warden agent read-boundary does not fire on ungraded catalog lanes	open	ops-warden	ops-warden	ops-warden	2026-08-19	ops-warden	production	ops-warden	unset	unset	unset	unset

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:

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:

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.

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