NK-WP-0056-T02: record access-engine, secrets-engine and railiance-platform answers; LLDAP self-rotation proven

A lldap_strict_readonly account changes its own password with its own token
on the pinned LLDAP and cannot change another account's, so the pilot needs
no lldap_password_manager account (secrets-engine Q2).

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

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 994874@bnt-lap001
Assistant-Session: 6017c416-d619-47eb-bd1a-f670a02d7d87

docs/evidence/2026-10-31-nk56-lldap-self-rotation/README.md

@@ -0,0 +1,18 @@
+# LLDAP bind self-rotation on the pinned image (NK-WP-0056, 2026-10-31)
+
+Agent-run, synthetic: a throwaway LLDAP on the pinned production image
+(`docker.io/lldap/lldap@sha256:9e605a66…d09d`), published on 127.0.0.1, tmpfs data, generated values, removed afterwards.
+Prompted by secrets-engine's T02 answer (`docs/bounded-executor-credential-lanes.md`, Q2 preferred shape).
+
+| Step | Result |
+| --- | --- |
+| `svc-x` created in `lldap_strict_readonly` (the bind accounts' group), password set by admin | — |
+| `svc-x` signs in with its password | yes |
+| `lldap_set_password` for `svc-x` with **`svc-x`'s own token** | rc 0 |
+| new password signs in / old password signs in | yes / no |
+| `lldap_set_password` for `admin` with `svc-x`'s token | refused (rc 1); admin unchanged |
+
+Consequence: the T06 rotation can change `svc-authelia`'s password as `svc-authelia` itself, using the current value
+the executor reads from OpenBao, with no `lldap_password_manager` account (`svc-executor-pw` in
+`tools/service-identity/declarations/bounded-executor.yaml`). A leaked executor token then reaches one bind, not every
+non-admin user. Revert is the same operation with the previous value. Founder decision pending (secrets-engine Q2).

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

@@ -17,9 +17,9 @@ Every answer below is the owner's agreement. Nothing here assigns work to anothe
 | Component | Owner (hub agent) | Asked to carry | Answer |
 | --- | --- | --- | --- |
 | Admission carrier | approval-engine | The admission as a consumable approval | pending |
-| Admission as input claim | access-engine | Policy decision for executor operations under an admission | pending |
-| Executor credential lanes | secrets-engine | Lifecycle of the executor's OpenBao credentials | pending |
-| OpenBao roles and CCR types | railiance-platform | Kubernetes auth role and policies for the executor; CCR request types | pending |
+| 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 | pending |
 | 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 |