# 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?"*