Open WARDEN-WP-0033 — native lane handoff
secrets-engine accepted five interim lanes and drafted the entries itself rather than wait for our contribution. Reviewing them turned up a defect in our own grading model, which is now T02 and the most consequential item in the plan. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
parent
06d0a1e690
commit
9b7e2e9bd2
1 changed files with 141 additions and 0 deletions
141
workplans/WARDEN-WP-0033-native-lane-handoff.md
Normal file
141
workplans/WARDEN-WP-0033-native-lane-handoff.md
Normal file
|
|
@ -0,0 +1,141 @@
|
|||
---
|
||||
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: progress
|
||||
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: todo
|
||||
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.
|
||||
|
||||
```task
|
||||
id: WARDEN-WP-0033-T03
|
||||
status: todo
|
||||
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.
|
||||
|
||||
```task
|
||||
id: WARDEN-WP-0033-T04
|
||||
status: todo
|
||||
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.
|
||||
|
||||
## 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
|
||||
Loading…
Add table
Add a link
Reference in a new issue