secrets-engine/workplans/SECRETS-WP-0007-production-lifecycle-hardening.md

id	type	title	domain	repo	status	owner	topic_slug	created	updated	state_hub_workstream_id
SECRETS-WP-0007	workplan	Production-safe provisioning, authorization, and lifecycle hardening	infotech	secrets-engine	active	codex	custodian	2026-08-23	2026-09-06	68a39be1-bd9c-5133-ad64-e7bca892aaf3

SECRETS-WP-0007 - Production-safe provisioning, authorization, and lifecycle hardening

Goal

Close the highest-risk gaps between the proven CLI MVP and the production workflow described by INTENT.md, before expanding secrets-engine into a service or moving additional high-risk lanes from interim routing to native operation.

The source assessment is history/2026-08-23-scope-intent-capability-gap-assessment.md. The most relevant gaps are:

1. single-field bao kv put can replace siblings on a multi-field path and puts the value in the local subprocess argument vector;
2. KV revoke destroys metadata while leaving policy/AppRole access behind, and its dry-run does not match live behavior;
3. production approval checks are coarse status checks, accept local fixtures, and do not bind actor, action, lane, fields, expiry, or dual control;
4. AppRole delivery tokens are not explicitly revoked after exec/verification;
5. route and verification can attest only the first field and use a garbage token rather than a real unrelated identity for KV denial;
6. evidence is best-effort and incomplete on failure paths.

Scope and sequencing

This workplan hardens the existing CLI contract first. It covers KV write transport and merge semantics, lifecycle command semantics, decision binding, short-lived delivery sessions, verification/readiness, and evidence. It then provides the safe implementation gate for resuming SECRETS-WP-0006-T05/T06.

The first task is containment. No task may exercise live production values to develop or test a primitive. Use fake values and a throwaway OpenBao instance until the relevant behavior has passed unit and integration tests. Existing ESO, Kubernetes/OIDC delivery, provider rotation, and application health remain with their current owners.

Non-goals

• A service API, daemon, UI, scheduler, or remote multi-user protocol.
• Runtime tenant authentication, quotas, or a tenant control plane.
• A second custody backend or backend-portability project.
• Provider-specific rotation automation.
• Replacing flex-auth, State Hub decisions, key-cape/user-engine identity, ops-warden routing, ops-bridge transport, or OpenBao enforcement.
• Unparking the standalone warden-sign AppRole as a break-glass path.

Service mode remains deferred until the exit criteria here are satisfied; it must not expose the current bootstrap and lifecycle shortcuts as an API.

Safety invariants

• No raw value in Git, State Hub, chat, prompts, workplans, evidence, normal logs, environment diagnostics, or a subprocess argument vector.
• No write to a shared multi-field path unless sibling preservation is proven.
• No destructive metadata deletion through a command presented as ordinary revoke/deactivate.
• Production actions require canonical, exact-action approval. Offline fixtures cannot authorize steady-state production mutations or delivery.
• Existing workload delivery stays in place until separately approved owner coordination says otherwise.
• Tests use fake values and throwaway OpenBao only; live checks are metadata/capability-safe and approval-gated.

Contain unsafe lifecycle surfaces

id: SECRETS-WP-0007-T01
status: done
priority: high
state_hub_task_id: "5ddba36d-bc86-5670-baf1-50c872e6577e"

Completed 2026-08-23. During containment, existing multi-field provisioning failed before file read or backend access. Ordinary revoke builds one lifecycle plan used by both dry-run and live execution, deletes only engine-managed native AppRole/policy objects, and explicitly preserves KV custody, external delivery auth, and workload delivery. No destructive KV command remains on the ordinary CLI. Focused lifecycle, admission, auth-capability, and throwaway OpenBao integration tests pass. The temporary multi-field rejection was then superseded by the merge-safe primitive completed in T02.

Add immediate fail-closed guards before implementing replacement primitives:

• reject provision on an existing multi-field lane;
• reject or rename the current destructive KV revoke path so it cannot be mistaken for soft deactivation;
• make KV revoke dry-run render exactly the operations the live path would run;
• document that SECRETS-WP-0006 may apply/verify metadata but must not provision or revoke shared values through the current commands.

Acceptance:

• A regression test proves no backend call occurs for multi-field existing-lane provisioning.
• A regression test proves dry-run and live operation plans contain the same KV, AppRole, and policy targets.
• The destructive action requires an explicit name/flag and a separately approved action; ordinary revoke cannot destroy KV metadata.
• CLI/help/runbook language no longer describes metadata deletion as reversible deactivation.

Implement merge-safe, non-argv provisioning

id: SECRETS-WP-0007-T02
status: done
priority: high
state_hub_task_id: "ddf3ed54-9cbc-5e18-b15a-5da14cda5d9b"

Completed 2026-08-23. Replaced raw field=value argv writes with a CAS-aware backend primitive: new paths use CAS-zero create; existing paths use server-side HTTP patch with the observed metadata version. Values travel through a mode-0600 temporary JSON reference removed in finally, and never appear in argv. Unit tests inspect the full request/cleanup; throwaway OpenBao integration proves sibling preservation and stale-CAS rejection. Stage policies now include the narrow KV patch capability needed by this operation.

Replace the raw field=value subprocess call with a backend write primitive that never places the value in argv and safely updates one or more declared fields without removing unmentioned siblings. The design may use OpenBao CAS, a merge/patch operation, an input file reference with strict cleanup, or direct request input, but it must remain isolated behind OpenBaoClient and preserve the catalog field allowlist.

Acceptance:

• Unit tests inspect the complete subprocess request and prove the fake value is absent from argv, environment, output, exceptions, and evidence.
• Throwaway OpenBao integration proves updating one field preserves every sibling field and fails closed on a CAS conflict.
• Multi-field input is atomic from the caller's perspective; a partial failure cannot silently leave an unreported mixed version.
• Source and generated inputs retain mode/path guards and guaranteed temporary cleanup.
• Production generation remains forbidden, and high-risk production provisioning is still decision- and dual-control-gated.

Split suspend, deactivate, and destroy semantics

id: SECRETS-WP-0007-T03
status: done
priority: high
state_hub_task_id: "bb6073e1-c952-5357-b707-5574cef50f2f"

Completed 2026-08-29. Suspend, deactivate, and destroy share one plan object for dry-run and live execution. Ordinary revoke aliases native deactivation and preserves KV custody plus externally managed workload delivery. Live destroy stays fail-closed until T04's exact-action contract; that is the designed containment, not unfinished T03 work. Issued delivery sessions self-revoke in T05.

Residual from this task, now implemented: secrets-engine session revoke --accessor-file or --lease-id-file (hardening H4a).

Progress 2026-08-23. Added one lifecycle plan model shared by dry-run and live execution. Ordinary revoke safely aliases native deactivation; suspend and deactivate preserve KV custody and externally managed workload delivery. Destroy has an unmistakable dry-run plan and exact-id confirmation, but its live handler is deliberately fail-closed before coarse lane approval or backend access until T04 supplies distinct action authorization. Scoped issued-session self-revocation is implemented in T05; a general known-accessor operator command is session revoke --accessor-file (H4a).

Replace the overloaded revoke behavior with explicit lifecycle operations and plans. Define at least:

• suspend delivery: stop minting new native delivery sessions while preserving custody and a documented rollback;
• deactivate native access: remove/disable the lane AppRole and consumer policy without deleting the KV value;
• revoke issued sessions: revoke known tokens/leases by non-secret accessor where the backend supports it;
• destroy custody metadata: irreversibly delete KV metadata/versions only through an unmistakable, separately approved action.

Preserve compatibility only where it cannot mislead. A legacy revoke alias may map to a safe non-destructive action; it must never silently retain the current destructive meaning.

Acceptance:

• Each operation has a guarded dry-run plan, exact targets, distinct approval action, non-secret evidence, and documented rollback/irreversibility.
• Dry-run and live use the same plan object rather than separate handwritten descriptions.
• Integration tests prove suspend/deactivate preserve KV data and destroy does not run without its explicit approval and confirmation contract.
• Auth-capability and KV lanes have coherent but kind-appropriate behavior.
• Existing workload delivery is reported as an external dependency and is not deleted by native lifecycle commands.

Bind approvals to exact production actions

id: SECRETS-WP-0007-T04
status: wait
priority: high
state_hub_task_id: "4b58edec-c705-55e5-9ece-362e1ff13079"

Wait 2026-08-29. The consumer validator and production fail-closed gate are shipped. What remains is not local engine work: State Hub / access-engine must serve the durable ActionAuthorization object. Paired with SECRETS-WP-0008-T02. Do not reopen live production on hub status or local fixtures.

Progress 2026-09-02. GH-DEC-2026-003 consume-before-OpenBao is now a shared production gate: _require_lane_approval CAS-consumes through approval-engine before any OpenBao client is resolved. Tests prove 409, unreachable, and missing-binding paths never call OpenBao. Live production stays fail-closed until the durable object is served; this task remains wait.

Progress 2026-08-23. flex-auth revision c473f19 now supplies execute-time structured binding and the proposed durable ActionAuthorization schema. The engine builds and fail-closed validates the exact secrets-engine profile, validity, State Hub authority, decision digest/binding, accepted policy revision, and a caller-selected minimum distinct-approver threshold. Every live production handler now carries its action into the shared gate and fails before OpenBao while State Hub lacks the durable endpoint. Legacy local decisions are reachable for prod-labeled lanes only with an explicit unsafe-demo switch, disabled Hub URL, and loopback OpenBao. The throwaway scripts declare that exception. Live destroy remains disabled independently. State Hub endpoint and authenticated approval storage are still outstanding. flex-auth corrected its example digest and added a complete binding regression assertion in d402408.

Correction 2026-09-06. The 2026-08-29 note above ("What remains is not local engine work") was wrong. resolve_consume_binding was a return None stub, so protocol step 1 (PIP GET /v1/approvals/{id}/claim) and the validation join were never implemented, and validate_action_authorization — the validator this plan called "shipped" — had no caller in src/ at all. Only step 3 (CAS consume) and the OpenBao gate were real. Production fail-closed was therefore correct but for a second, undocumented reason.

The join is now implemented. resolve_consume_binding reproduces the exact CheckRequest via build_action_request, fetches the durable ActionAuthorization, and validates request binding, digest, validity, authority, policy pin, and distinct-approver threshold before returning a binding. _require_lane_approval threads the exact field set for provision, rotate, verify, and exec so the digest covers the real proposed action. Eight tests in tests/test_consume_binding_join.py cover unconfigured, half-configured, digest mismatch, action mismatch, unreachable, and superseded paths.

Two deliberate choices, both recorded in docs/approval-consumption.md: the approval-engine object id is never inferred from a State Hub decision UUID (flex-auth: GET /decisions/{uuid} is not the durable object); and there is no default policy pin, because flex-auth stated secrets-engine.lifecycle/v1 is example vocabulary rather than a published package.

Behavior today is bit-for-bit unchanged: every new input is absent by default, so an unconfigured engine still fails production closed, and plan/--dry-run still work. This task stays wait, but the remaining constraint is now purely deployment: approval-engine must serve the claim endpoint and access-engine must serve Check. Probed 2026-09-06 — neither is reachable, and State Hub exposes only /decisions/.

Inbound 2026-09-06 (approval-engine APPROVAL-IN-0002, flex-auth FLEX-DEC-2026-005). The join committed in 627810b validates the wrong artifact and must not be extended until gate-house rules.

• ActionAuthorization is a PROPOSED, unratified object from flex-auth's own contract. It appears zero times in gate-house and state-hub. GH-DEC-2026-003 already names step 1 as GET /v1/approvals/{id}/claim -> valid_now, an approval-claim field that ActionAuthorization does not carry. The claim body is an approval-claim envelope, not an ActionAuthorization.
• Confirmed defect, ours, independent of the ruling: authorization.py pins AUTHORITY = "state-hub" and enforces it unconditionally, contradicting flex-auth's statement that State Hub decision records are not the runtime approval authority and our own read-model doctrine. Not patched yet: under option A the authority check belongs on the claim issuer, so it moves with the split rather than being guessed twice.
• If gate-house confirms option A, validate_action_authorization splits across the two artifacts already fetched: the claim carries approval fact (binding digest, validity window, consumption state, freshness, issuer); the step-2 DecisionEnvelope carries exact CheckRequest match and the package/version pin. No check is lost. Do not start until the ruling.
• Auth gap, tracked separately so it does not ride the envelope decision: we send a static mode-0600 token as Bearer. Production verifies a KeyCape RS256 JWT against JWKS and refuses opaque tokens. Requested registration clientId secrets-engine-approval, scopes approval:read + approval:consume, client_credentials, confidential. aud MUST be the resource server approval-engine, never the clientId. service_auth.py already implements this exchange for secrets-engine-openbao, so this is a second registration.
• approval-engine APPROVAL-WP-0002-T03 will publish the base URL; it is not deployed anywhere today and proceeds on its own evidence. The envelope question gates our first live consume, not their rollout.
• flex-auth endorsed the no-default-pin decision explicitly. The reserved coordinate secrets-engine.catalog-lane.lifecycle / v1 is a RESERVATION, not a publication; our pin stays unset. docs/gated-actions.md delivers the authoritative twelve-action list FLEX-WP-0021-T01 was blocked on. No estate-wide PDP exists by design: flex-auth runs per-consumer cluster-local pins, and flex-auth-secrets-engine has not been created yet, so the 2026-09-06 probe finding was the design working rather than an outage.

Resolved 2026-09-06 by gate-house GH-DEC-2026-005 (GH-IN-0002), settling approval-engine's APPROVAL-IN-0002. Both changes it assigned to this repo are implemented.

1. The validator is split by owning layer. approval_claim.validate_approval_claim consumes approval-engine's approval-claim for the approval fact (issuer, valid_now, consumption state, binding digest, freshness, reason_code). authorization.validate_decision_envelope consumes the flex-auth DecisionEnvelope for the decision (effect, exact CheckRequest binding, canonical request digest, lifetime, policy package/version pin). Neither republishes the other's data. ActionAuthorization is deferred and never ratified (FLEX-DEC-2026-006); nothing validates it any more.
2. AUTHORITY = "state-hub" and the provenance.authority requirement are gone. flex-auth traced the constant to their own fixture (examples/caring/action_authorization.json), which contradicted their ownership section — their bug, fixed at source. State Hub is a read model and holds no runtime approval authority, so the check failed closed against every correctly issued record.

Two consequences worth stating rather than burying:

• There are now two different digests over the same proposed action, by contract, never compared to each other: the approval-engine native binding digest over {action, actor, principal, purpose, target}, and the flex-auth canonical CheckRequest digest. claim.binding.pdp_digest is preferred when the issuer recorded one. The CheckRequest digest itself is unchanged and its contract test is preserved verbatim — flex-auth confirmed only the envelope went away, not the digest join.
• The distinct-approver threshold is no longer a consumer-side check. The claim does not expose approver entries; approval-engine folds that requirement into valid_now. We now rely on the issuer for it, which is the correct layer but is a real reduction in what this engine verifies independently.

Still outstanding, unchanged by the ruling: step 2 needs the flex-auth-secrets-engine Service DNS (not created — per-consumer cluster-local pins are the design, so the earlier "no reachable PDP" probe was not an outage) and the published package from FLEX-WP-0021-T02. The pin stays unset. docs/gated-actions.md delivered the twelve-action vocabulary that unblocks FLEX-WP-0021-T01. Separately tracked: production requires a KeyCape RS256 JWT, not the static Bearer token this engine currently sends.

Closed out 2026-09-06. gate-house amended GH-DEC-2026-005; flex-auth published the policy package (FLEX-WP-0021-T01/T02 done, commit f75db59).

• secrets-engine.catalog-lane.lifecycle v1 exists with both manifests, a loadable registry snapshot, 26 fixtures and five standalone check requests; validate -kind policy reports 22/22 Rego tests and 26/26 fixtures. Our vocabulary is recorded in flex-auth docs/secrets-engine-action-vocabulary.md. All four constraints from docs/gated-actions.md are encoded rather than assumed: test_revoke_is_not_an_action asserts revoke denies unknown_action, destroy is fixtured as the dual-control case before T04 opens the path, compromise/reactivate are annotated overlay-only, and the ungated verbs deny unknown_action. flex-auth reports four of the twelve would have been inferred wrongly, revoke most confidently.
• A published limit now rests on a property of this repo. apply and apply --dry-run are indistinguishable to a PDP; both arrive as action apply. What separates them is that our PEP does not call the gate for a dry run. flex-auth recorded that as a limit rather than implying a control they do not have, and asked to be told if the assumption stops holding. tests/test_dry_run_never_gates.py now enforces it across all five dry-run handlers, with a paired test proving the hook is load-bearing. Changing a dry-run path to gate is now a test failure carrying the instruction to notify flex-auth first.
• Dual control on destroy checks what the claim says (two distinct approver subject ids). flex-auth deliberately does not re-derive temporal validity, signature, or supersession — those are approval-engine's to assert and ours to verify against the live claim. validate_approval_claim is that check.
• allow_ttl is 15m in the package, stated rather than left to an engine default. Per FLEX-DEC-2026-004 that is authority to issue the operation, not to keep using what it produced; bounding a delivered secret's own lifetime is ours. Already satisfied: normalize_wrap_ttl caps wrap at 15m and lane AppRoles carry 5m/15m token TTLs with a single-use Secret ID.
• Structural note carried as a revisit trigger, not a defect: because we named exactly one calling identity, the denial ladder has no action_not_granted branch — with one subject holding all twelve actions it could never fire, and a rule that cannot fail reads as per-action control that is not there. Registering a second identity, or splitting the CLI identity by lane or stage, is the trigger; adding the branch then is additive and needs no request-shape change.
• gate-house struck the G3 revisit trigger for a composed authorization object, verified against the DecisionEnvelope schema: lifetime is required whenever effect is allow, so carrying its own end — the one structural thing the bundle did that the split does not — is already answered. Three triggers remain: a third or fourth PEP-shaped consumer, a single signed forwardable artifact, and §17 request-claim assent.
• On the approver threshold we stopped checking, gate-house recorded both that it is correct on layering and a genuine reduction in defence in depth, noting a decision recording only the first would be self-serving. The compensating property is reconstructability at the issuer under §9.6 — detection, not prevention — not a second check here.

The pin stays unset. Publishing is not deploying: there is still no flex-auth-secrets-engine pin and therefore no address to call. T04 stands it up in callerAuth.mode warn; T05 hands over the Service DNS and confirms the package/version to configure. Next inbound is the T03 replay fixture — a real DecisionEnvelope from this package including provenance.registry_snapshot_digest — to verify the digest join unchanged.

Verified 2026-09-06 against flex-auth's T03 replay fixtures (FLEX-WP-0021-T03, commit 9e10d1c), vendored to tests/fixtures/flex-auth-replay/. Running them found a defect of exactly the class we had just been warning about.

• request_digest was hashing fields the contract excludes. The material is tenant, subject, action, resource, context only; id is correlation, policy_version lives in provenance, and caring_context is hashed separately. This engine included all three when present. Because the join adopts the served request id, every real production request would have carried one, so the computed digest would have matched no issued decision and failed closed against every correct allow — the same unsatisfiable-rule shape as the removed AUTHORITY constant and as flex-auth's own destroy rule in 68ad039. Fixed by digest_material; both fixtures now reproduce their published digests exactly.
• The previously pinned digest constant was computed with the id inside the material, so it was wrong and its passing was not evidence. It is replaced by fixture-driven contract tests over two real envelopes plus a structural test that correlation fields do not move the digest. Both fixtures are required: provenance.input_claim_digests.context appears only with a non-empty context.
• The native claim digest is unusable and is no longer computed. The claim's binding.action/binding.target speak approval-engine's vocabulary while ours speaks the catalog's, and no mapping is published; flex-auth makes no cross-check and states the correspondence is ours via pdp_digest. A claim recording no pdp_digest now fails closed naming the missing mapping rather than comparing two vocabularies. A published mapping is a prerequisite for making destroy reachable under this task. flex-auth offered to co-author it with approval-engine.
• Narrowing accepted from approval-engine: entries is UNIQUE on (approval_id, subject_id), so approver distinctness is a storage invariant, not a count this engine was previously protecting. What we stopped verifying is that approval-engine applies its own invariant correctly — still a real reduction in defence in depth, but narrower than "the threshold is now unverified". They also added threshold objects to issuance and use events (87e55e2) so the evaluation is reconstructable under §9.6.
• flex-auth corrected the destroy dual-control rule (68ad039) before generating these fixtures: it had required context.approval.status == 'approved' and an approver list, neither of which exists in the claim schema. Our acknowledgement of the earlier rule crossed that fix. The corrected rule requires only kind/issuer/valid_now, and our claim validation is unchanged.
• One global pin confirmed correct: secrets-engine.catalog-lane.lifecycle v1 is one package covering all twelve actions. Do not build per-action pin configuration for a distinction that does not exist.

Brought into practice 2026-09-06. The chain is complete in code and proven end to end; what remains is deployment only.

• Step 2 is implemented (decision_check.check_decision, POST /v1/check) and approval_consume.authorize_action coordinates steps 1 and 2. Both build the same CheckRequest through one _expected_request, since two descriptions of the proposed action cannot produce corresponding digests.
• apply_unreachable_engine_stance now takes authorized=. The published map defines fail_closed as no protected side effect without a durable access-engine decision record, so holding a validated one means the engine was reachable and the residue does not apply. This is not a stance bypass: both steps must have succeeded, CAS consume still precedes OpenBao, and with nothing configured authorize_action returns None and production fails closed exactly as before. Verified by CLI, not only by unit test.
• tests/test_integration_authorization.py drives the real gate through claim -> check -> consume -> OpenBao against a live throwaway OpenBao, and asserts PIP-before-PDP ordering, consume as the last step before the backend, and that an unreachable PDP, a denied decision, an invalid claim, a missing pdp_digest, a consume conflict, and an action mismatch each stop before the backend. The stub serves transport and sequencing only; wire contracts stay pinned to flex-auth's real fixtures.
• The end-to-end run found a third instance of the cross-vocabulary defect: a leftover comparison of the claim's binding.action against ours. Real claims say secrets.kv.destroy where we say destroy, so it would have failed against every one of them. Removed; the tie is pdp_digest. Worth noting the pattern: unit tests with self-consistent fakes hid all three, and each was found only by a real artifact or a real chain.

Destroy gate closed 2026-09-06 (inbound FLEX-DEC-2026-007, GH-DEC-2026-008, approval-engine schema v3). The vocabulary mapping this task was waiting on is not coming, and it should not have been waited on: gate-house rejected it outright, for the reason flex-auth and approval-engine both gave independently — a translation can be confidently wrong and fails open by accepting a claim approved for a different action. The stronger option arrived instead, and both halves of it are now enforced here.

• The circularity we reported is fixed at source. A pdp_digest recorded at approval-issue time can never equal the request_digest of a request that carries the claim in its hashed context. With GH-DEC-2026-008 requiring that equality on the PDP path, destroy would have been permanently un-allowable, failing closed forever on a check no correct record could pass. flex-auth published binding.approval_binding_digest (commit dd3ce4c): the same canonical digest with context.approval removed, stable across attaching the claim. The comparison is against that field, never request_digest.
• request_digest deliberately still covers the claim, so the two digests disagree on a claim-bearing request and that disagreement is load-bearing: two requests differing only in which approval was presented must not share a replay identity, or an allow obtained with a valid claim could be replayed against a request carrying none. approval_binding_digest is not a replay identity and is not used as one.
• authorization.approval_binding_digest implements the published exclusion rule, including flex-auth's json:"context,omitempty" behaviour of dropping a context that strips empty. digest_material now drops an empty context for the same reason. validate_decision_envelope recomputes the field when present rather than trusting it, refuses a claim-bearing request whose decision records none, and takes the claim's digest from step 1 as expected_approval_binding_digest.
• binding.pdp_path is required true before pdp_digest is used at all. It is approval-engine's declaration that the approval was requested against a bound CheckRequest; their create() refuses pdp_path true without a digest, so the declaration guarantees the digest. The converse is not inferred: a digest present for some other reason is no declaration, and pre-v3 approvals carry pdp_path false regardless of any digest they hold.
• The cost is accepted rather than engineered around: an approval requested without a bound CheckRequest is not usable on this path and will not become usable later. If a real destroy workflow cannot bind at issue, that is the falsifier gate-house wrote into the reversal and it gets raised, not worked around.

The replay fixtures are re-vendored from dd3ce4c, and the pins moved a second and final time (request_digest sha256:c749ee2d…, context input-claim digest sha256:8b73d29e…; approval_binding_digest sha256:fa07becf…, which did not move — that is the point). The fixture now demonstrates the property instead of asserting it: test_pdp_digest_equals_the_published_approval_binding_digest rederives fa07becf… from the fixture's own request through our canonical implementation, which is a hermetic proof that this engine hashes the same material flex-auth does. A pin alone would only have asserted the constant. decision_rotate.json is unchanged and carries no approval_binding_digest; a test pins that omission so the field is not silently duplicated onto ordinary decisions.

Our own CheckRequest stays claim-free (context is {"purpose": …}), so the identity holds transitively today; the code is already correct for the day we carry a claim in context.

Still open and still ours: the T04 consumer-shape question flex-auth has asked twice — operator CLI reaching an in-cluster pin, a workload we do not have yet, or no pin at all. It is a deployment-shape answer, not engine work, and it is the reply owed on that thread.

Remaining to go live is configuration and deployment, not engine work: SECRETS_ENGINE_PDP_URL/_PDP_TOKEN_FILE (awaiting the flex-auth-secrets-engine pin, FLEX-WP-0021-T04/T05), SECRETS_ENGINE_APPROVAL_URL/_TOKEN_FILE (awaiting APPROVAL-WP-0002-T03), the policy pin (published but not to be set until T05), a KeyCape RS256 credential in place of the static Bearer token, and approval.authorization_id on each lane. Destroy's additional requirement is now met in code: the pdp_path + approval_binding_digest identity replaced the vocabulary mapping that was never going to exist.

Define and enforce the decision contract needed by production commands. A resolved approval must bind at least:

• canonical decision UUID and non-superseded status;
• catalog id and stage;
• action (apply, provision, verify, exec, handoff, suspend, deactivate, destroy, or later rotate);
• exact field set or policy/auth targets where applicable;
• requesting actor/purpose and expiry or bounded execution window;
• required approval count and distinct approvers for dual-control.

Coordinate the external object shape with State Hub/flex-auth rather than inventing authorization ownership in this repo. Keep local fixtures for throwaway demos and non-production tests only; require an explicit unsafe-demo switch if they remain reachable at all.

Acceptance:

• Every privileged production handler passes an action-specific request into one shared authorization function.
• Tests reject wrong lane, stage, action, field set, actor/purpose, expiry, superseded status, insufficient approvals, duplicate approvers, and local production fixtures before any OpenBao call.
• approval.model: dual-control has enforced semantics rather than being a label.
• Catalogs use resolvable canonical decision UUIDs for live actions; legacy CCR references remain provenance, not executable authorization.
• State Hub outage fails production actions closed while dry-run/catalog inspection remains usable.

Make delivery sessions short-lived and explicitly closed

id: SECRETS-WP-0007-T05
status: done
priority: high
state_hub_task_id: "36bcd64d-8b27-542d-b8da-ede1a4d3c22f"

Completed 2026-08-29. Delivery AppRole sessions self-revoke in finally on exec and both verification kinds. Bootstrap is a named provider with no implicit fallback from the KeyCape scaffold. Wiring that scaffold as OpenBao JWT login is SECRETS-WP-0008-T06 / hardening H1, blocked on the platform-owned role — not remaining T05 engine work.

Progress 2026-08-23. AppRole login material now travels through strict temporary JSON input rather than argv. Exec and both verification kinds use a scoped session that self-revokes in finally, drops the in-memory token even when cleanup fails, and exposes only an accessor fingerprint plus cleanup booleans as evidence. Tests cover success and exception cleanup, idempotence, failed revoke visibility, and value/credential exclusion. Provider review requests were sent to railiance-platform (8f910aff-3a94-43c6-8805-eb9276e46fc0) and key-cape (0627ca55-115e-43dc-b2f6-3195be3bc90d); steady-state engine authentication remains external-contract work.

KeyCape has accepted the secrets-engine-openbao service contract. An explicit consumer scaffold now performs HTTPS client-credentials exchange, strict out-of-repo client-secret input, exact claim/assurance/lifetime preflight, three-minute renewal classification, and rejection of ID/refresh tokens. It has no bootstrap/operator/AppRole fallback and is deliberately not wired into the CLI until railiance-platform materializes the exact OpenBao JWT mount and role.

Refactor AppRole login into a scoped session object that retains only the minimum non-secret lifecycle handle needed to revoke the issued token in a finally path. Apply it consistently to exec, KV verification, auth-capability verification, and any future file/wrapped delivery.

Define the steady-state OpenBao authentication interface separately from the delivery AppRole. Bootstrap token files remain an explicit break-glass/setup provider; add a bounded OIDC/service-auth provider only with railiance-platform and identity-owner review.

Acceptance:

• Success, child non-zero exit, setup failure, verification failure, SIGINT, and SIGTERM tests all attempt token revocation and clean temporary material.
• Secret IDs remain single-use where configured; tokens retain TTL/use limits as backstops rather than their only cleanup.
• Evidence records session establishment/revocation outcome using non-secret handles or request ids only.
• A failed revocation is visible and actionable without printing token or accessor material.
• Bootstrap-file authentication is clearly separated from the reviewed steady-state provider and cannot become an implicit fallback.

Strengthen verification, readiness, and evidence

id: SECRETS-WP-0007-T06
status: done
priority: high
state_hub_task_id: "431bc91b-439e-595a-8a8a-7d4c82e68322"

Completed 2026-08-29. Acceptance is met: multi-field readiness, real unrelated identity for KV denial, privileged attempt/terminal evidence, and audit. Residuals belong elsewhere: exact-action authorization is T04 / SECRETS-WP-0008-T02; OpenBao audit request-id correlation is hardening H5; unrelated-identity selection for production remains an owner/ops concern, not an engine mint.

Progress 2026-08-23. KV verification now checks every declared field by default, with one path-level negative probe, and route readiness reads once and requires all declared fields. Missing readiness evidence contains field names only. Tests prove a missing sibling makes readiness false. Evidence delivery attempts now receive append-only local success/failure receipts, and audit produces an allowlisted per-lane summary of actions, results, decisions, session cleanup, and delivery outcomes without echoing arbitrary detail. The real unrelated-identity input is now enforced as a strict mode-0600 out-of-repo token file; absence fails closed, and throwaway OpenBao integration deliberately adds an overlapping unrelated read policy and proves the check fails. Production identity selection/ownership, audit request correlation, queued/replayed State Hub delivery, and exact-action authorization remain outstanding. All live privileged handlers now share one attempt/terminal evidence guard: approval rejection, backend/input exceptions, interruption, verification failure, and success are recorded without exception prose. Tests prove decision and backend failures stop before inappropriate backend work and exclude fake secret text.

State Hub evidence posts now carry stable idempotency, source-agent, and repo headers. HTTP 202 edge-relay receipts are classified as queued and retain only their non-secret outbox id in the companion evidence record and lane audit. Outbox replay remains owned by State Hub/operator tooling.

The complete repository suite is re-run at each implementation slice, including throwaway OpenBao integration coverage.

Make verification and routing truthful for multi-field and high-risk lanes:

• verify every declared field unless the exact approved subset is explicit;
• make route readiness require every required field, not only the first;
• replace the garbage-token negative check with a reviewed real unrelated identity/token or a capabilities-based denial proof that can detect policy overlap;
• record attempt, success/failure, cleanup, and authorization outcome for every privileged command;
• correlate engine evidence with OpenBao audit request ids where available;
• provide a non-secret lane audit summary over local/State Hub evidence.

Acceptance:

• Removing any required sibling field makes readiness false and identifies only the missing field name, never values.
• Negative verification fails when a deliberately overlapping unrelated policy is introduced in throwaway OpenBao.
• Evidence tests cover backend exceptions, child failures, State Hub delivery failures, and cleanup failures without leaking fake secret patterns.
• An audit/report command summarizes decisions, attempts, outcomes, and cleanup for a lane without becoming an authority or replacing OpenBao audit logs.
• The full test suite and throwaway OpenBao integration suite pass.

Resume native production lane adoption

id: SECRETS-WP-0007-T07
status: wait
priority: high
state_hub_task_id: "a0a1dd92-d703-5a95-b488-d895f34d5cf7"

Dependency: T01–T03, T05, T06 are done. T04 still waits on the durable ActionAuthorization serving path. Also requires explicit per-lane approvals and scoped production authority from railiance-platform.

Resume SECRETS-WP-0006-T05 lane by lane. Apply only the exact native policy and bounded AppRole, verify every field plus unrelated-consumer denial, confirm the existing workload delivery remains healthy, exercise only an approved value-safe child command, and record rollback/session-cleanup evidence.

After a lane passes, complete SECRETS-WP-0006-T06 with ops-warden. Retire its interim proxy only after both parties agree that native readiness evidence is complete. Do not batch-retire all five lanes.

Acceptance per lane:

• Canonical action-bound approval is resolved and linked.
• Policy/AppRole server readback matches the reviewed exact-path plan.
• All declared fields pass presence/access checks; a real unrelated identity is denied; no value enters evidence.
• Issued delivery sessions are explicitly revoked and cleanup is evidenced.
• Existing ESO/OIDC delivery and application health remain good according to their owners.
• Rollback is rehearsed or capabilities-safe verified before proxy retirement.
• ops-warden routing reports native readiness and removes only that lane's interim proxy.

Dependencies and coordination

• SECRETS-WP-0006 owns the five-lane catalog admission and live cutover.
• railiance-platform owns production OpenBao authority, custody, and backend audit.
• State Hub/flex-auth own the canonical decision/authorization contract.
• key-cape/user-engine own human/service identity and claims.
• Workload owners own ESO/Kubernetes delivery and provider/application health.
• ops-warden owns credential routing and interim proxy disposition.

Any external contract change must be recorded as non-secret evidence and must not transfer custody or authorization ownership into this repository.

Exit criteria

• Current unsafe multi-field provisioning and misleading revoke behavior are contained and replaced.
• Raw values cannot enter subprocess argv or evidence through provisioning.
• Production approvals are canonical, exact-action, expiring, and genuinely dual-control-capable.
• Delivery tokens are explicitly revoked on every exit path.
• Readiness and verification cover all declared fields and meaningful unrelated identities.
• Lifecycle operations distinguish reversible access suspension from irreversible custody destruction.
• At least one of the five admitted production lanes completes the hardened native verification/cutover path; remaining lanes have explicit external blockers rather than engine-safety blockers.
• Service-mode design remains deferred until these guarantees are demonstrated.