ops-warden/history/2026-08-11-delegation-surface-assessment.md

Delegation surface assessment — 2026-08-11

Trigger: founder directive — ops-warden should work with, but never replace or duplicate, secrets-engine, tenant-engine, user-engine and other NetKingdom components. Covering an unfilled gap is acceptable if the gap stays visible, gets filled with proper governance, and ops-warden then delegates.

Method: enumerate registry/routing/catalog.yaml by execution mode; check wiki/AccessRouting.md and wiki/playbooks/catalog-lane-promotion.md for existing interim/delegation doctrine; compare against SCOPE/INTENT claims.

---

1. Execution surface (24 catalog entries)

Mode	Count	Entries
warden_executes: true — ops-warden's own authority	1	ssh-cert-host-access
exec_owner: set — delegated, route-primary/proxy-fallback	2	whynot-design-npm-publish (secrets-engine), ops-warden-warden-sign-token (railiance-platform broker)
exec_capable proxy, no exec_owner	11	openbao-api-key, key-cape-oidc-login, issue-core-ingestion-api-key, reuse-surface-hub-write-token, openrouter-llm-connect, railiance-backup-offsite-lane, forgejo-admin-api-token, binky-company-email-imap, binky-qonto-api, rapp-qonto-keycape-client, agent-harness-forgejo-deploy
route-only pointer	10	remainder

Finding. The delegation primitive exists, is proven in production, and is used by 2 of 24 lanes. Eleven lanes have ops-warden as the de facto front door with no record of who should own it instead.

2. The doctrine is not written down

• wiki/AccessRouting.md — the canonical "what ops-warden answers" page — contains no mention of secrets-engine and no section on interim positions. A worker or agent reading it cannot tell that warden access proxying a workload secret is a stopgap rather than the design.
• wiki/playbooks/catalog-lane-promotion.md gates draft→active on the lane working (zero placeholders, resolvable, tests green). It never asks whether ops-warden should be the one executing it.
• The delegation intent for whynot-design-npm-publish lives in WP-0019 prose and SCOPE; the machine-readable expression (exec_owner) was a by-product, not a policy applied catalog-wide.

Consequence: an absorbed need is indistinguishable from a designed one. Ownership drift is invisible by construction, which is exactly the failure mode the directive targets.

3. Classification of the eleven (revised on inspection, founder review 2026-08-11)

A first draft sorted by subsystem — tenant lanes to tenant-engine, workload lanes to secrets-engine. Reading the entries showed that is the wrong axis. Nine of the eleven share one auth_method ("caller's own OpenBao token" via operator OIDC or a workload-kv-read-* policy) and one fetch_command shape (bao kv get -field=X <path>). No owner procedure is duplicated in those. Contrast whynot-design-npm-publish — npm config plus token injection into a specific tool, a procedure, which is why WP-0019 handed it to secrets-engine.

Test applied: owner-specific procedure or lifecycle → interim. Generic KV read → thin wrapper, arguably permanent.

Interim (5) — classified

Lane	Intended owner	Blocked on
rapp-qonto-keycape-client	key-cape	client_secret_basic exchange is a key-cape procedure; rotation already automatable: true
binky-company-email-imap	tenant-engine	tenants/binky/... custody, rotation owned by binky-control — split lifecycle
binky-qonto-api	tenant-engine	Same split
railiance-backup-offsite-lane	railiance-platform	Rotation is re-establish, a procedure ops-warden only describes
agent-harness-forgejo-deploy	railiance-platform / agent-harness	re-establish + alternative host-local key path

Held (6) — pending secrets-engine

openbao-api-key, key-cape-oidc-login, issue-core-ingestion-api-key, reuse-surface-hub-write-token, openrouter-llm-connect, forgejo-admin-api-token.

Permanent only if secrets-engine exec stays per-lane and provisioned. If it generalizes over arbitrary OpenBao lanes, all six become interim with secrets-engine as intended owner. Asked directly (msg 7d55d332). For three of them (issue-core-*, reuse-surface-*, openrouter-llm-connect) production never touches the proxy at all — External Secrets delivers the value and the proxy serves operator verification only, which weakens the case that a front door is missing.

No lane names user-engine as owner. It appears only as a consumer inside coulomb-social-runtime-env (route-only, owned by railiance-platform), whose rotation guidance points at the OpenBao path user-engine/user-engine-runtime for USER_ENGINE_PROXY_SECRET. So a user-engine runtime secret exists and is routed, but user-engine fronts nothing itself. Whether it should own that lane is worth confirming rather than assuming either way.

4. Secondary finding — SCOPE drift

SCOPE.md "Where we are" was dated 2026-07-01 and stated "Active work: none open in ops-warden after WP-0022/0023." Six workplans have shipped since (WP-0024–0026, WP-0028, WP-0029 finished; WP-0027 sits in backlog), adding warden plan, warden desk, warden taint, warden rotate-guide, experiential memory, the tenant custody pattern, and the build-phase organization posture axis. SCOPE understated the repo by roughly six weeks of work. Corrected in this pass.

5. Recommendation

WARDEN-WP-0030 — record delegation: (mode / intended_owner / blocked_on) on every entry, expose warden route gaps, gate promotion on the ownership question, and publish the resulting interim register to the owner repos. Absence of a delegation block should read as interim, owner unknown — a question — never as settled ownership.

The measure of success is not fewer proxies. It is that no proxy exists without an answer to "who should own this front door, and what is missing?"