net-kingdom/docs/proposals/2026-10-31-nk56-t02-owner-requests.md

NK-WP-0056-T02: owner requests for the bounded executor (2026-10-31)

Basis: Bounded Execution Admission v0.1, proposed (canon/standards/bounded-execution-admission_v0.1.md, net-kingdom 989d5d4), and its examples in examples/bounded-execution-admission/. The first live use is NK-WP-0056-T06: unattended rotation of the svc-authelia directory bind, under one founder admission (bind-rotation-svc-authelia.yaml).

Founder decision 2026-10-31 (hub 6d1adce9):

• net-kingdom writes the executor runtime: source and tests, next to the admission validator, the bind lanes and the synthetic journey;
• a new rapp-* package builds the image and deploys it in sso (ADR-0015);
• glas-harness becomes the path for agent executors later (GLAS-WP-0018).

Every answer below is the owner's agreement. Nothing here assigns work to another repository.

Component	Owner (hub agent)	Asked to carry	Answer
Admission carrier	approval-engine	The admission as a consumable approval	answered 2026-10-31 (approval-engine 5028fe2, docs/bounded-execution-admission-carrier.md, APPROVAL-WP-0007 proposed): binding, single consume and revoke-before-start supported today; the executor creates the approval request itself (actor must equal its token subject, human_control: true), the founder approves; aal2 is recorded per entry but not enforced (APPROVAL-WP-0007-T01 adds a floor; until then the executor checks it); request_digest = admission digest for the pilot; independent GET before consume is the intended reading; consume does not check consumer = actor (T02 there); revoker identity not recorded (T03 there)
Admission as input claim	access-engine	Policy decision for executor operations under an admission	answered 2026-10-31 (access-engine f5b7a90, docs/bounded-execution-admission-pdp.md, FLEX-WP-0040 proposed): yes for production, two decisions start (before consume) and execute-step (after), new pack net-kingdom.bounded-execution, caller map generalised; needs approval-engine to add approver assurance and consumed_by/consumed_at to the claim; source mid/late November, live after the pilot. Pilot without the gate acceptable if the receipt records the PDP as not-evaluated; a second admission should not run without the gate unless the founder records an exception
Executor credential lanes	secrets-engine	Lifecycle of the executor's OpenBao credentials	answered 2026-10-31 (secrets-engine 8ec5aff, docs/bounded-executor-credential-lanes.md, SECRETS-WP-0017 proposed): engine lanes are read-only and AppRole-only today, so railiance-platform applies the Kubernetes role and policy and secrets-engine catalogs it as metadata; proposes the role exists only during the admitted window; Q2: prefer self-rotation of the bind (proven on the pinned LLDAP, see docs/evidence/2026-10-31-nk56-lldap-self-rotation/), fallback a lldap_password_manager account. Note: its message 3e865656 carried another worker's text by mistake; 084a731e is the correct answer
OpenBao roles and CCR types	railiance-platform	Kubernetes auth role and policies for the executor; CCR request types	answered 2026-10-31 (railiance-platform 8b57d27, not pushed; docs/credential-lane-designs/bounded-executor.md, RPF-WP-0069): new request type workload-kv-write-next-version (read+update on one data path, cas_required, no metadata/delete), CCR-2026-0058 drafted proposed for the svc-authelia write role; one role per lane; journey read needs a workload-kv-read CCR that widens CCR-2026-0057; audit sender in the CCR-2026-0021/0022 shape once audit-core names it. Recommends a standing write role for the pilot (secrets-engine recommends window-only: founder decides)
Receipt holder	audit-core	Execution-attribution receipts from the executor	answered 2026-10-31 (audit-core 1ef939b, docs/bounded-executor-receipts.md, AUDIT-WP-0018 proposed): yes, from a registered in-cluster sender nk-bounded-executor (secret_policy: reject); one receipt per run with steps inside data, plus a separate execution.run.started event at consume so a crashed run is detectable; envelope ids run:<run_id>:started/receipt, subject admission:<id>; asks NetKingdom to label decision_refs and decide the singular target/action shape
Agent executors	glas-harness	Session contract so a harness-launched agent can be an executor	answered 2026-10-31 (glas-harness 92dd299, docs/bounded-execution-agent-executor.md, GLAS-WP-0018-T07): not before GLAS-WP-0018-T04 (proposed; needs key-cape agent tokens with act and sandbox token delivery); a verifiable harness-launched assertion must be a key-cape-signed per-run token, claim set proposed; glas-harness proposes to own the agent-executor path later. Founder: approve GLAS-WP-0018 or not
Runtime package	railiance-apps	Where the new rapp-* package lives and who creates it	answered 2026-10-31 (railiance-apps c733e86, docs/rapp-bounded-executor-intake.md): not railiance-apps; rmgr rapp wrap (repo-manager) creates it locally, the Forgejo remote is the founder's; the image is built in the app repo (net-kingdom), the rapp pins its digest; deploy by kubectl server-side apply run by the founder; recommends one Job per admission. Founder decisions F1-F4 open

approval-engine

1. Binding. Can an approval carry a BoundedExecutionAdmission with these fields?

   • action: bounded-execution
   • actor: the executor identity (pilot: service:nk-bind-executor)
   • principal: the approver (admin)
   • purpose: spec.purpose
   • target: {admission_id, admission_digest}
   • validity equal to spec.window

   The plan, plan digest, budget and ceiling are inside the digested document, so target covers them.

2. Assurance. How does an approval record that the approver acted at aal2? The standard requires it (BEA-C4).

3. Consume. The executor's service principal consumes once, before its first step. Which scope and which request_digest does that take? Your contract notes that consume does not check digest equivalence, so we plan an independent GET /v1/approvals/{id} comparison of target.admission_digest. Is that the reading you intend?

4. Revocation. Can the founder revoke an approval that has not been consumed? This would be the kill switch before the start (T07).

access-engine

1. Should a PDP decision gate executor operations? For example: "executor X may run operation O on target T under admission A", with the admission read as an input claim through approval-engine.
2. If yes, what is needed: a bounded-execution action, a policy pack and its owner, and the execution_contract coverage that your current apply rules do not evaluate. What is the timeline?
3. For the T06 pilot, is it acceptable that the executor enforces the ceiling locally (validator plus a Kubernetes Role), with the PDP check added later?

secrets-engine

1. The pilot executor needs these OpenBao capabilities, at most 15-minute TTL:

   • write the next version of platform/workloads/net-kingdom/directory-binds/svc-authelia (CAS);
   • read it and .../synthetic-journey/syn-journey for its checks.

   Does secrets-engine orchestrate these lanes for an executor workload, as with other lifecycle lanes?

2. To set svc-authelia's password in LLDAP, the executor needs a directory credential. Would that be a dedicated LLDAP account (no narrower group than lldap_password_manager exists) delivered as a cataloged credential? Or do you see another lane shape?

railiance-platform

1. A Kubernetes auth role for the executor's ServiceAccount in sso, with policies limited to the paths above (as in CCR-2026-0052..0054). Which CCR request types: workload-kv-read for the journey secrets (NK-WP-0056-T10), and a new KV-write-next-version type for the rotation?
2. Receipt sender: per NK-WP-0040-T02, you register senders for audit-core. Can the executor pod receive an ESO-projected sender bearer like other in-cluster senders?

audit-core

1. Will you hold the executor's execution-attribution receipts (Playbook Capability Contract v0.2, NK-WP-0040) as audit events from a registered in-cluster sender?
2. The receipt adds per-step outcomes, check results, revert yes/no and budget used, and binds the admission id, admission digest and approval reference in decision_refs. Does that fit your event model, or should these be separate events correlated by run_id?

glas-harness

1. GLAS-WP-0018 (session contract): when could a harness-launched agent present as AGENT with a verifiable "harness-launched" assertion? The standard's BEA-4 requires it for agent executors.
2. Not needed for the pilot. This asks whether glas-harness wants to own the agent-executor path later.

railiance-apps

1. The executor needs a deployment package under ADR-0015 (working name rapp-bounded-executor): an image built by Forgejo, and a Deployment or Job in sso with its own ServiceAccount. Who creates the repository, and which conventions apply?

Outcome (2026-10-31)

All seven owners answered through worker agents in their repositories (founder instruction 2026-10-31). Open founder decisions, collected:

1. Executor OpenBao role: standing (railiance-platform) or only during the admitted window (secrets-engine).
2. Directory credential: self-rotation of the bind (proven on the pinned LLDAP) or a lldap_password_manager account.
3. CCR-2026-0058 (proposed): approve or change.
4. rapp package: create rapp-bounded-executor (F1), executor source location and image workflow in net-kingdom (F2), one Job per admission (F3), namespace sso (F4).
5. Pilot without the PDP gate (receipt records not-evaluated); a second admission only with the gate or a recorded exception.
6. Adopt the execution.run.started event; decision_refs labels and the admission-level target/action shape.
7. Approve the proposed owner workplans: APPROVAL-WP-0007, FLEX-WP-0040, SECRETS-WP-0017, RPF-WP-0069, AUDIT-WP-0018, GLAS-WP-0018 (and glas-harness owning agent executors later).

Hub hygiene: messages 3e865656, b3b9e3f3, 1a5ea23d, b748ba04 and 5a2dfbfb were posted under the wrong sender by workers sharing a scratch file; each is flagged by its worker's correction message and marked read here.