ops-warden/workplans/WARDEN-WP-0033-native-lane-handoff.md

id	type	title	domain	repo	status	owner	topic_slug	planning_priority	depends_on_workplans	created	updated
WARDEN-WP-0033	workplan	Native lane handoff — review secrets-engine's catalog admission, and fix what it exposed	infotech	ops-warden	active	ops-warden	netkingdom	P1	WARDEN-WP-0030	2026-08-21	2026-08-21

WARDEN-WP-0033 — Native lane handoff

On 2026-08-20 secrets-engine accepted five of ops-warden's seven interim proxy lanes for catalog admission (SECRETS-WP-0006, decision ae676382-1826-4e04-aa4e-bb77990c7a0d), rejected two with reasons ops-warden agrees with, drafted the five entries itself rather than waiting for the offered contribution, and asked for a line-by-line review of the non-secret metadata.

In the same hour railiance-platform closed the RISK-F-0009 coverage gap and asked ops-warden for two things back.

This workplan is the response to both, plus the defect the review turned up in ops-warden's own grading model — which is the most consequential item here and would not have been found without the second pair of eyes.

Why a workplan and not an adhoc

Four counterparties are waiting, one deliverable is a cross-repo interface another repo will consume on a schedule, and the review carries approval semantics — secrets-engine holds interim proxy ownership open until each lane has approved native verification. The convention reserves adhocs for low-risk work completed directly; this is none of those.

Tasks

id: WARDEN-WP-0033-T01
status: done
priority: high

Review the five drafted catalog entries and reply. issue-core-ingestion-api-key, reuse-surface-hub-write-token, openrouter-llm-connect, forgejo-admin-api-token, email-connect-transactional at secrets-engine@784be97.

Review the axes they asked for: owner-repo coordinates, field grouping, workload consumers, rotation/deactivation owners, delivery intent. Verify claims against the authoritative railiance-platform CCRs — never against a secret read; bao kv get on any of these paths is the 2026-07-16 vector and three of the five are risk: high.

Accept their two rejections. openbao-api-key is a routing template rather than one lane and key-cape-oidc-login belongs to key-cape — that is ADR-0005 applied to ops-warden by someone else, correctly.

id: WARDEN-WP-0033-T02
status: done
priority: high

Correct ops-warden's per-path risk grading — the defect T01 exposed.

secrets-engine graded issue-core-ingestion-api-key high; ops-warden grades it standard, and deliberately: WP-0032-T05 regraded it down on 2026-08-19, operator-sanctioned, because test_high_risk_lanes_classified asserted standard and was judged right — "ordinary internal workload secrets are standard".

That reasoning was incomplete, and CCR-2026-0002 says so explicitly: the path carries both ISSUE_CORE_API_KEY and GITEA_BACKEND_TOKEN, a Forgejo backend token, and the CCR records keeping both as a deliberate field-set decision.

The root cause is structural, not a single bad call. ops-warden grades a lane by its headline field — the catalog carries one fetch_command naming one field and no fields list at all — but the disclosure unit is the path: a bao kv get returns every field stored there. So a lane can be graded on its least dangerous contents. ADR-0007 says every lane carries an explicit grade; it does not say the grade must cover everything a read of that path would disclose, and it should.

Fix the grade, then fix the model that produced it: record fields per lane and grade on the union. Check the other 25 lanes for the same shape.

Done 2026-08-21 — and it was two lanes, not one. While verifying reuse-surface-hub-write-token I told secrets-engine their second field was unevidenced and asked them to confirm it. It was evidenced: CCR-2026-0005's kv_path block lists both fields and its notes describe the HMAC's alignment with Forgejo org webhook id=1. A truncated grep, and a retraction sent within twenty minutes so they would not spend time on it. That lane was under-graded on exactly the same reasoning, and both had been regraded down in the same T05 pass — which is what makes this a systematic flaw rather than one bad call.

Blast radius checked and bounded: of the 8 remaining standard lanes, 6 have no KV path at all (SSH, policy check, tunnel, principals, issue-sink, key-cape login) so nothing is disclosed by a read. Two do have paths and no CCR field evidence — rein-openweights-openrouter-approle and coulomb-social-runtime-env (a whole k8s env Secret, which by shape almost certainly holds several fields). Deliberately not regraded: ADR-0008 §3 says an unknown field set is stated rather than assumed, and grading is operator-sanctioned judgement, not backfill. They are the open item on this task.

Shipped: both regrades with their evidence and the superseded reasoning kept inline, fields recorded with its CCR source, the test that had been holding the wrong answer inverted with an explanation of why it was wrong to trust it, and ADR-0008 — a lane's grade covers every field its path discloses. That is a new binding rule, so it is a record rather than a wiki note.

id: WARDEN-WP-0033-T03
status: done
priority: high

Emit the generated high-risk data-path artifact for railiance-platform.

They asked for a versioned artifact of concrete high-risk data paths (id + data_path + catalog revision) to consume instead of hand-maintaining the deny list — the half of the RISK-F-0009 fix ops-warden explicitly declined to build for them. Emitting the artifact is not the same as amending their policy: they still own what to deny. That boundary is the point of ADR-0002 and must survive this task.

Must be generated, never hand-edited, and must carry the catalog revision so a consumer can tell what it was derived from. Depends on T02 — publishing the deny set before fixing the grades would ship the wrong list to a consumer who will apply it.

Done 2026-08-21. scripts/emit_high_risk_paths.py → registry/generated/high-risk-data-paths.yaml: 19 high-risk lanes, 14 concrete data paths, 5 with no single KV address listed separately so a consumer does not read the absence as an omission. Carries catalog_revision, its date, and a catalog_dirty flag — a revision that does not describe the file it came from is worse than none.

The T02 dependency was not theoretical. The two regrades land in this artifact, and check_agent_read_boundary.py now reports 2 uncovered against a policy railiance-platform closed to 0 yesterday. Emitting before regrading would have handed them a list that confirmed a coverage claim that had just stopped being true.

fields is emitted as null where no CCR declares the set, never as a single-element guess — ADR-0008 §3. Two CI tests: the artifact must be current, and every high-risk lane must appear in it, so a lane graded high after the last emit cannot silently fail to reach the consumer.

Boundary held: the header states this is an input and not a policy, and that railiance-platform may deny more, deny less, or dispute a grade (ADR-0002).

id: WARDEN-WP-0033-T04
status: wait
priority: medium

Route the coding-agent issuance identity question.

RAILIANCE-WP-0017 is blocked on defining a distinct coding-agent issuance identity and proving deny-wins when that identity is combined with workload read. They asked ops-warden to route ownership.

Route it; do not absorb it (ADR-0005, ADR-0003). ops-warden owns actor identity for adm/agt/atm SSH certificates and nothing else — a coding agent's OpenBao issuance identity is an IAM question. The likely owner is key-cape, with user-engine and zone-engine both plausibly involved. Say so with reasoning rather than guessing, and record the answer either way.

Note the interaction with ADR-0004: the agent read-boundary already depends on WARDEN_AGENT_ID being set, which is an honour-system marker on the ops-warden side. A real issuance identity is what would make that boundary hold on the OpenBao side too, so ops-warden is an interested consumer, not a bystander.

Routed 2026-08-21 to key-cape (msg 903b2223); waiting on accept or refuse. Reasoning given: it is an identity and issuance question about a principal authenticating to OpenBao, which is key-cape/Keycloak's. The precedent is an hour old and runs the same direction — secrets-engine declined key-cape-oidc-login as ops-warden's to hand them, on the grounds that login and identity-token issuance stay with key-cape. Absorbing this would contradict agreeing with them.

Named the adjacent parties explicitly rather than leaving them to inference: zone-engine has an interest (a coding-agent identity is a strong candidate zone subject) and user-engine is not involved — this is a machine principal, not an end-user account. Stated so nobody concludes it by elimination.

Asked for a refusal-with-pointer as an equally good answer. The failure mode to avoid is the 2026-08-17 one recorded in .claude/rules/finding-routing.md: ops-warden answered a question well and never routed it, and another repo ended up filing it.

Related

• secrets-engine SECRETS-WP-0006 — catalog admission, decision ae676382
• RISK-F-0009 — closed by railiance-platform 2026-08-21; 0 uncovered
• railiance-platform RAILIANCE-WP-0022 (boundary coverage), RAILIANCE-WP-0017
• ADR-0002, ADR-0003, ADR-0004, ADR-0005, ADR-0007
• WARDEN-WP-0030 — the delegation register these five lanes retire from