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

```task
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.

```task
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.

```task
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`).

```task
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