tegwick
9b7e2e9bd2
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>
5.8 KiB
| 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 |
|
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: 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.
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.
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.
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-engineSECRETS-WP-0006— catalog admission, decisionae676382RISK-F-0009— closed by railiance-platform 2026-08-21; 0 uncoveredrailiance-platformRAILIANCE-WP-0022(boundary coverage),RAILIANCE-WP-0017ADR-0002,ADR-0003,ADR-0004,ADR-0005,ADR-0007WARDEN-WP-0030— the delegation register these five lanes retire from