Answer flex-auth caller-auth question; refresh two delegation lanes

Inbox triage (ADHOC-2026-08-17), three messages, all answered and marked read.

flex-auth (FLEX-WP-0015 T02) reported that /v1/check and /v1/batch_check
authenticate no caller — any workload with cluster reach can assert any subject
and get an authoritative allow. It lands here because ops-warden owns workload
identity in this estate and its pre-sign gate is a flex-auth PEP.

Recommendation recorded in wiki/NetKingdomSecurityMap.md: Kubernetes
ServiceAccount TokenReview with a projected, audience-scoped token. Rejected the
shared-secret header — it manufactures a risk: high lane with a rotation owner
per caller on the authorization path, the exact interim-proxy debt WP-0030
exists to stop growing. Deferred mTLS pending an owner for a workload X.509 CA.
Bind `system` to the authenticated SA at auth time, but keep the resource-type
allowlist in the policy package rather than the admission layer. Warn-only
rollout; policy.enabled must not flip while /v1/check answers unauthenticated
callers. Recorded as a pattern, not a catalog entry.

Catalog delegation refreshes:
- coulomb-social-runtime-env: USER_ENGINE_PROXY_SECRET ownership settled
  (decision 8fe22037, USER-WP-0021) — intended_owner stays railiance-apps,
  answered clause dropped from blocked_on, consumers: [user-engine] recorded.
- rapp-qonto-keycape-client: blocked_on no longer implies an in-flight
  KEY-WP-0008 dependency; the key-cape-native exchange command is unopened work.

uv run pytest -q → 338 passed, 4 deselected.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

workplans/ADHOC-2026-08-17.md

@@ -0,0 +1,124 @@
+---
+id: ADHOC-2026-08-17
+type: workplan
+title: "Ad Hoc Tasks — 2026-08-17"
+domain: infotech
+repo: ops-warden
+status: finished
+owner: claude
+topic_slug: custodian
+created: "2026-08-17"
+updated: "2026-08-17"
+---
+
+# Ad Hoc Tasks — 2026-08-17
+
+Inbox triage session. Three unread messages, all follow-on from the WP-0030 delegation
+register plus one new design question that lands on ops-warden as the estate's
+workload-identity owner.
+
+### T01 — Answer flex-auth: how should `/v1/check` authenticate its callers?
+
+```task
+id: ADHOC-2026-08-17-T01
+status: done
+priority: high
+```
+
+flex-auth (msg `130a148c`, FLEX-WP-0015 T02) reported that `POST /v1/check` and
+`/v1/batch_check` authenticate no caller — any workload with cluster network reach can
+assert any subject/tenant and receive an authoritative allow. It lands on ops-warden
+because ops-warden owns how workloads prove identity in this estate, and because the
+ops-warden pre-sign gate is a flex-auth PEP that would implement the calling side.
+
+Their four questions answered in `wiki/NetKingdomSecurityMap.md`
+§ *Service-to-service caller authentication (in-cluster)*:
+
+- [x] **Q1 — is there an existing estate pattern to adopt?** No. Surveyed what exists:
+      ops-warden SSH certs (host reachability, not pod→pod HTTP), KeyCape
+      `client_credentials` (`rapp-qonto-keycape-client` — a custodied client secret per
+      caller), OpenBao AppRole (host-standing; the WP-0030 register already flags it as
+      having no owner front door). None covers in-cluster service→service HTTP, so
+      flex-auth is not growing a parallel mechanism by adopting one.
+- [x] **Q2 — which mechanism?** Confirmed their instinct: **(a) Kubernetes
+      ServiceAccount TokenReview**, with a *projected* token carrying an explicit
+      `audience`, keeping `automountServiceAccountToken: false` and adding the volume
+      per Deployment. Rejected (c) shared-secret header — it manufactures a `risk: high`
+      credential lane with a rotation owner per caller, on the authorization path, which
+      is exactly the interim-proxy debt WP-0030 exists to stop growing, and ops-warden
+      would end up fronting it. Deferred (b) mTLS as the stronger end state that first
+      needs an answer to *who owns the workload X.509 CA* — nobody does; ops-warden
+      issues SSH certs, not workload X.509.
+- [x] **Q3 — authenticate only, or also constrain?** Both, but split: bind the asserted
+      `system` to the authenticated ServiceAccount and reject a mismatch (identity
+      binding, no per-consumer operational cost). Keep the *resource-type* allowlist
+      ("only ops-warden may ask about `ssh-certificate`") in the policy package, not in
+      the auth middleware — flex-auth is the policy engine, and encoding it in its own
+      admission layer puts authorization in two places where only one is versioned.
+- [x] **Q4 — rollout shape?** Warn-only first, as they proposed; ops-warden adopts the
+      calling side on its own schedule. Binding condition is sequencing, not a date:
+      `policy.enabled` must not flip anywhere while `/v1/check` still answers
+      unauthenticated callers.
+- [x] Recorded as a **pattern**, not a catalog entry — `registry/routing/catalog.yaml`
+      indexes credential needs and their owners; caller authentication is neither.
+- [x] Noted the division of the call: mechanism is ops-warden's/architectural; accepting
+      the pod-spec change and rollout timing are the operator's.
+
+### T02 — user-engine: USER_ENGINE_PROXY_SECRET stays railiance-apps; record consumer-only
+
+```task
+id: ADHOC-2026-08-17-T02
+status: done
+priority: medium
+```
+
+user-engine (msg `2af4a124`) answered the open confirm question on
+`coulomb-social-runtime-env`. Decided by Bernd 2026-08-16, State Hub decision
+`8fe22037-5bbb-4487-bb86-e4beccee454b` against USER-WP-0021: the secret is
+infrastructure trust between ingress and workload, not a user-domain fact; user-engine
+consumes it and has no authority over custody, rotation, or issuance.
+
+- [x] `intended_owner` stays `railiance-apps`; dropped the now-answered
+      "confirm whether user-engine should front USER_ENGINE_PROXY_SECRET" clause from
+      `blocked_on`, which now names only the real remaining blocker (CCR not applied).
+- [x] Recorded the positive signal they asked for: `consumers: [user-engine]` on the
+      lane, with the decision id in a comment.
+- [x] Their second point — `USER_ENGINE_EVENT_TOKEN`, `USER_ENGINE_MAIL_TOKEN`, and the
+      transactional SMTP lane gating public registration — checked against the catalog:
+      `audit-core-senders` (native → ops-mason) and `email-connect-transactional`
+      (interim → secrets-engine) already cover the event and mail token custody. No new
+      lane opened; told them which ids to watch.
+
+### T03 — key-cape: `rapp-qonto-keycape-client` interim accepted; refresh the blocker
+
+```task
+id: ADHOC-2026-08-17-T03
+status: done
+priority: medium
+```
+
+key-cape (msg `099b7cba`) acknowledged the lane staying interim on ops-warden.
+KEY-WP-0008 is finished and its closeout does **not** include a key-cape-native
+`client_secret_basic` exchange/rotation command; that is a separate, not-yet-opened
+workplan.
+
+- [x] Refreshed `blocked_on` so it names the current reality rather than implying an
+      in-flight KEY-WP-0008 dependency: the native command is unopened work, and
+      key-cape has acked the interim hold.
+- [x] `key-cape-oidc-login` left pointing at `secrets-engine` — key-cape explicitly did
+      not claim the generic-vs-per-lane custody split, and that lane's blocker is the
+      same unanswered secrets-engine question as the other six.
+- [x] `reviewed` bumped to 2026-08-17 on both touched lanes so `warden route gaps`
+      staleness reflects a real re-check.
+
+### T04 — Session hygiene
+
+```task
+id: ADHOC-2026-08-17-T04
+status: done
+priority: low
+```
+
+- [x] `uv run pytest -q` → 338 passed, 4 deselected (routing anchor + no-double-source
+      checks green after the catalog edits).
+- [x] All three messages replied to and marked read; inbox empty.