ops-warden/workplans/WARDEN-WP-0038-plan-mutation-intent.md

id	type	title	domain	repo	status	owner	topic_slug	planning_priority	depends_on_workplans	created	updated	state_hub_workstream_id
WARDEN-WP-0038	workplan	warden plan must distinguish reading a secret from mutating one	infotech	ops-warden	finished	ops-warden	netkingdom	P1	WARDEN-WP-0029	2026-09-08	2026-09-09	751ad530-e44b-52c4-b70e-cb47568a0179

WARDEN-WP-0038 — Read versus mutate intent in the policy front door

The defect

warden plan scores a need against catalog lanes by keyword overlap and returns a verdict. It has no notion of what the caller wants to do. So a need that says generate a successor secret and CAS-write it to two custodians matches the lane that reads that path, scores well on the shared nouns, and returns:

verdict: autonomous
commands: warden access <lane> --exec / --out / --wrap

Three read transports offered as the answer to a write, under the verdict that means "proceed without the founder". Reproduced 2026-09-08 against rapp-qonto-keycape-client (ADHOC-2026-09-08-T04).

Why this is worse than a bad suggestion

warden plan is the documented first step before drafting any founder credential step (.claude/rules/credential-routing.md), and autonomous is consumed as an authorization signal by agents that have no other check. WARDEN-WP-0029 shipped the verdict because instinct was not auditable; a verdict that is confidently wrong in the permissive direction is worse than no verdict.

key-cape hit this and refused to rely on it — "we are not treating a generic match as authorization" — which is the only reason it surfaced as a design question rather than as an unadmitted custody mutation. The control that caught it was a counterparty's caution. That is not a control.

WARDEN-WP-0033-T06 is the same shape (rapp-postgres, generic openbao-api-key match → paste_once_provision for an act that could not work) and was fixed by adding one exact lane plus one regression. That fixed the instance. This is the class.

Shape of the fix (to be designed, not assumed)

• Classify need intent — read / mutate / establish — before scoring, and never answer a mutate need with a read lane's transports.
• A mutate need against a lane ops-warden does not own is unroutable with a CCR stub naming the custody owner, not autonomous. ADR-0003: cover gaps, never silently own them; a permissive verdict on someone else's custody act is a silent claim of ownership.
• Consider whether rotation.steps should be reachable from plan at all, given they are advisory prose and several are explicitly not automatable.
• Regression from the reproduced case, in the manner of T06.

Open question for design

Whether intent belongs in the matcher or in the lane. A lane could declare which acts it admits (read, rotate, provision) and plan could refuse any act a lane does not declare — stricter, and it fails closed on lanes that say nothing, which is the majority today. That is a catalog schema change and needs its own argument.

Confirmed independently, then fixed — 2026-09-09

railiance-platform hit the same defect from the other side while answering the Qonto custody routing question (msg 7c7228ac). Having stated that the correct verdict is founder_required — attended OIDC via netkingdom role=platform-admin, through the governed openbao-platform-admin-login lane — they added:

Note this is the same verdict your warden plan should have returned; it returning autonomous and offering read transports for a write is a real defect and WARDEN-WP-0038 is the right place for it. Until that is fixed, do not let a plan result stand in for this answer.

Two counterparties reporting the same wrong verdict in two days, one of whom is the write authority being wrongly bypassed, moved this from proposed to shipped.

What shipped

_need_intent() classifies a need as mutate or read by token match, and _owns_write_authority() tests delegation.mode == "permanent". A mutating need on a lane ops-warden does not permanently own can no longer reach any branch that returns autonomous:

• lane declares a rotation → founder_required, with an approve act naming the write owner, the rotation method, whether it is automatable, and warden rotate-guide as guidance;
• lane declares none → unroutable with a CCR stub whose owner_hint names the write authority.

Commands are empty of read transports either way. That is the half that made the wrong verdict actionable rather than merely wrong: --out, --exec, --wrap and a bare bao kv get were being offered as the answer to a write, and a test now asserts none of them appears.

The design question in the plan, answered by use

The plan asked whether intent belongs in the matcher or in the lane. It went in the matcher, with the ownership test doing the work that a verb list cannot: SSH certificate issuance is itself a mutating act, and warden sign must stay autonomous. delegation.mode: permanent is what separates ops-warden's own front door from someone else's custody — not the absence of a verb from a list. A regression asserts the SSH lane still proceeds, because a guard that refuses our own lane would be a worse defect than the one it fixes.

The stricter alternative — lanes declaring which acts they admit, plan refusing anything undeclared — is not built. It is a catalog schema change that would fail closed on the majority of lanes, which say nothing today, and it needs its own argument rather than arriving as a side effect of this fix.

Not claimed

This narrows what warden plan will assert; it does not make the tool an authority on custody. railiance-platform's instruction stands and is the right standing posture: a plan result does not substitute for the owner's answer.