access-engine/docs/bounded-execution-admission-pdp.md

Bounded Execution Admission and the PDP — access-engine owner answer

Answer to NetKingdom NK-WP-0056-T02 (owner request net-kingdom/docs/proposals/2026-10-31-nk56-t02-owner-requests.md, section "access-engine"), for the proposed standard net-kingdom/canon/standards/bounded-execution-admission_v0.1.md (BEA v0.1). Date: 2026-10-31. Status: owner answer and proposal. The founder and the named owners decide; nothing here is enabled or deployed.

Follow-on work: workplans/FLEX-WP-0040-bounded-execution-pdp-gate.md.

What exists today (from source)

Fact	Evidence
access-engine is the estate's only PDP and validates approvals as input claims; it never owns, mutates or consumes the approval object	SCOPE.md (One-liner, Out of Scope: approval object is approval-engine's)
A typed task-execution path exists on /v1/check. It requires TokenReview caller mapping, a fixed owner-installed Approval reader (GET /v1/approvals/{UUID}/claim, no consume) and original/fresh claim correspondence before policy runs	docs/trusted-service-task-source.md, internal/taskexecution/approval_source.go, internal/taskexecution/service_input.go
That path is hard-wired to one consumer: subject secrets-engine, transport principal system:serviceaccount:secrets-engine:secrets-engine, contract SECRETS-EXEC-20261011-v1, operation metadata-apply-ccr, exactly six OpenBao operations	examples/secrets-engine-service-task-execution-v2/policy_package.md (status proposed)
The v2 policy requires approval.consumed == false at decision time	same file, candidate_matches
The older secrets-engine apply rule ignores execution_contract content: an allow there is not exact task authority	internal/policy/secrets_execution_gap_test.go (gap characterization test)
The Approval claim adapter carries id, native binding and PDP digest; it carries no approver assurance level	third_party/approvalfact (pinned copy of approval-engine/adapters/go/approvalfact/claim.go)
Human callers on the typed path must present aal2 + MFA from key-cape, at most 300 s old; that is the caller's assurance, not the approver's	internal/taskexecution/identity.go
No chart, runtime admission or credential custody is enabled for the typed path	docs/trusted-service-task-source.md

So the mechanics a BEA gate needs exist in one consumer-specific shape. There is no bounded-execution action, no namespace for admissions, no caller mapping for service:nk-bind-executor, and no evaluator for BEA's scope_ceiling or plan.steps.

Q1 — Should a PDP decision gate executor operations?

Answer: yes, in scope, recommended for production; not required for the pilot.

A decision "executor X may run operation O on target T under admission A" is the kind of decision this repository exists to make (SCOPE: estate's only PDP), and reading the admission as an approval claim through approval-engine matches the existing boundary (approval-engine owns the object, access-engine validates it as input). It adds what local enforcement cannot: an independent evaluator outside the executor's own code, a signed decision record per step with policy version and request digest, and a single place to revoke or narrow executor authority across admissions.

Two shape points we propose (they change the request NetKingdom sketched):

1. Two decisions, not one per step against an unconsumed claim. The current typed path demands consumed == false. BEA consumes once before the first step (BEA-C6/C7). Proposed:
   • start — before consume: claim valid, unconsumed, approver human/aal2, executor == admission executor, now inside window, admission digest matches the claim's target. ALLOW is the precondition for the consume call.
   • execute-step — after consume: claim consumed exactly once, by this executor, inside the window; the step id, operation, target and required mode/scope match the digested plan and lie inside scope_ceiling. This needs approval-engine to expose consumed_by and consumed_at in the claim (question for approval-engine, alongside NK's question 3).
2. The PDP never consumes. Consume stays the executor's call to approval-engine, as today (approval_source.go: "no policy, retry, consume or effect lives here").

Q2 — What is needed, who owns it, timeline

Item	Status	Proposal
Action vocabulary start, execute-step on resource type bounded-execution-admission, system net-kingdom	needs change	access-engine adds; vocabulary only, no allow
Typed path generalised from the single secrets-engine mapping to an owner-installed caller map (first entry system:serviceaccount:sso:nk-bind-executor → service:nk-bind-executor)	needs change	access-engine; keeps the existing secrets-engine behaviour byte-identical
Admission input: the executor submits the admission document; access-engine recomputes its digest and requires equality with the claim's target.admission_digest	needs change	access-engine; canonical digest rule must match NK's BEA digest definition
execution_contract coverage: evaluate step id/operation/target/mode/scope against plan.steps and scope_ceiling, plus window and blast-radius (max_concurrent)	needs change	in the new pack; the old apply gap (see test) is not reused and stays characterised
Approver assurance aal2 (BEA-C4)	missing input	approval-engine must carry approver assurance in the claim; access-engine will not infer it
consumed_by / consumed_at in the claim	missing input	approval-engine
Policy pack net-kingdom.bounded-execution	proposal	Pack mechanics and fixtures: access-engine. Semantic content (what a ceiling admits): NetKingdom as BEA standard owner, reviewed by gate-house for authority ceilings. Founder to confirm owner
Deployment of a pin serving the pack, caller trust, Approval reader credential	gated	founder/platform admission, as for every pin; not in this workplan's authority

Timeline (proposal). Source work (vocabulary, generalised caller map, pack with fixtures, DENY-by-default until inputs exist) can be done in about one to two weeks of repository work once approval-engine answers the claim-field questions. It lands as proposed, evaluated only in tests. A live gate follows FLEX-WP-0039 (per-pin readiness and policy import) and a founder rollout decision. Realistic: source-ready mid/late November 2026, live after the pilot. It does not block the pilot window in the BEA example (2026-11-03).

Q3 — Pilot with local enforcement only

Answer: acceptable, with conditions.

• The executor's validator (BEA-C1..C7 against the carrier) plus a namespaced Kubernetes Role and narrowly scoped OpenBao/LLDAP credentials are the enforcement for T06. That is a consumer-side PEP and is the consumer's to own.
• The pilot must not claim PDP gating. Its receipt should state the PDP decision as not-evaluated (no decision id), so later evidence cannot be mistaken for a flex-auth ALLOW.
• Do not call the existing secrets-engine apply rule or the generic /v1/check as a stand-in: the former ignores execution_contract, the latter refuses task execution.
• When the gate goes live, the executor's stance on PDP unavailability is fail-closed (declared by the consumer, per SCOPE "Out of Scope: fail-open").
• Revisit after the pilot: the second admission should not run without the PDP gate unless the founder records an explicit exception.