Add proposed task execution policy and initiating identity contract

Assistant: codex
Assistant-Model: gpt-6.1-sol
Assistant-Session: 01a126e1-76f8-7643-8cf3-e93336539ade

docs/reviews/2026-10-11-task-execution-provider-source.md

@@ -0,0 +1,86 @@
+# Access owner source contract and readiness receipt
+
+reviewer: access-engine owner (agent access_task_execution_policy, Codex)
+disposition: bounded source contract acknowledged; executable readiness refused
+work_item: FLEX-WP-ADHOC-2026-10-11-T04
+
+The completed own source-preparation anchor was persisted before this receipt:
+Access commit 1d3a8727f50d4e855e5ddda9f8746d0f2dabbc12, exact
+workplans/ADHOC-2026-10-11.md SHA256
+4df32aafda0339a073bc2a512eef8d0db6686617ce6027ed554b3f5c68e4f2c6.
+All eight staged hashes were rechecked against immutable source manifest
+/tmp/access-execute-ccr-stage/manifest.json SHA256
+e7a36575c1e521613cc6092371058833d7f43b6739c3cee5b0929cb90c708d88.
+The source maker and this owner-role reviewer are the same agent: this receipt
+is not an independent code review or foreign issuer/provider acceptance.
+
+## Bounded source agreement
+
+Access INTENT Responsibility Boundary reserves policy decisions to the sole PDP,
+authentication to the identity layer, and protected effects to the consumer.
+The separate proposed secrets-engine.task-execution v1 package/action execute-ccr
+preserves that boundary: it neither overwrites lifecycle v2 nor translates apply
+into scoped task execution. Its literal owner_admission=false keeps the entire
+package closed today, including requests asserting verified, human_control or
+owner_admission. No consumer boolean can enable it.
+
+The actual Secrets immutable descriptor and existing canonical full/approval-free
+digest joins are the appropriate input for exact operation/CCR/grant/catalogue,
+source, ordered target/body plan, expected states, budget and deadline binding.
+The candidate policy models one two-object GET/PUT/GET plan, not arbitrary
+apply/provision/exec. Independent Platform source/body compiler and native ACL
+scope remain required; shape/hash matching never establishes owner-source trust.
+
+The source-only cryptographic verifier reuses existing KeyCape RS256 human
+access-token claim fields out of band. It uses owner-selected issuer/audience/
+public-key pins and trusted server time; rejects service subjects, foreign or
+registration-only tenant provenance, missing/stale MFA, expiry/future activation,
+wrong issuer/audience/key/signature and ambiguous JSON. It returns opaque identity
+only. It is not wired into HTTP evaluation, issues no key/token, selects no real
+client, accepts no native issuer and makes no authorization decision.
+
+## Readiness refusal and owner dependencies
+
+No authenticated initiating-human channel, admitted User/Tenant PIP retrieval,
+transport-to-human representation or server projection exists in this patch.
+The proposed task_execution_projection is an internal integration sketch, not an
+accepted public identity claim. Raw human JWTs must not enter CheckRequest,
+context, audit/decision records or receipts. Server implementation must reject or
+discard caller projection fields, independently verify KeyCape identity, acquire
+User membership/canonical-user facts and Tenant lifecycle facts through their
+actual authenticated interfaces, and impose the earliest freshness/lifetime
+ceiling. Service TokenReview proves transport only. Approval's human approver is
+not automatically the initiating human; a registration tenant is not membership.
+
+This receipt does not accept anything on KeyCape, User Engine, Tenant Engine,
+Approval Engine, Platform or Secrets Engine's behalf. Actual client/audience,
+issuer/key admission, PIP transport and freshness contracts, and representation
+must receive their owners' acceptance and integration evidence. Removal of the
+hard refusal requires a separately reviewed versioned source successor, never
+an unsigned flag, helm value or literal flip in a runtime test.
+
+Served approval claim validation and exact issue/full/submitted digest joins,
+trusted consume confirmation, owner compiler, durable journal and task grant/
+cleanup mediation remain required independently. Existing SECRETS-WP-0013 and
+RPF-WP-0035-T12 drive integration; no clone driver or operational closure is
+introduced. Native lifecycle adoption and standing service authority stay false.
+
+## Actual source verification
+
+Maker command in isolated staged Access source:
+GOCACHE=/tmp/access-taskexecution-go-cache go test -json
+./internal/taskexecution ./internal/policy ./pkg/api.
+Terminal exit zero: 118 passing Go test events, including 24 new parent/subtest
+events, zero failures. Log /tmp/access-execute-ccr-stage/test-results.jsonl.
+Actual Secrets Python ExecutionContract.parse and canonical request/approval-free
+digest functions produce the same complete synthetic descriptor and digests as
+Go. OPA candidate allow and mutation denials use an isolated in-memory package
+with the hard false literal replaced for the test alone. The actual staged
+package remains false and denies all requests. These synthetic results prove
+source semantics/interoperability, not provider facts or an available runtime
+allow path. The cross-repo generator currently relies on the estate's Secrets
+virtualenv, and is not claimed to be a portable standalone fixture.
+
+No native call, credential retrieval, package activation, foreign owner checkout
+write or privileged-action trial occurred. Exact source publication and independent
+code verification remain with the coordinator before adoption.

docs/task-execution-initiating-provider-contract.md

@@ -0,0 +1,97 @@
+# Proposed Secrets exact execution policy and initiating-provider boundary
+
+Prepared for Secrets SECRETS-WP-0013-T01 and Platform RPF-WP-0035-T12.
+This is a proposed Access source contract. It adopts no new identity protocol,
+issuer/client/key, runtime provider, source standard or native entitlement.
+
+## Why the separate policy exists
+
+Lifecycle v2 deliberately serves twelve generic operations. Existing apply
+ignores execution_contract and its service subject cannot prove which human
+initiated a task. The new package secrets-engine.task-execution v1 recognizes
+only execute-ccr and is separate from secrets-engine.catalog-lane.lifecycle v2.
+The entire execution descriptor, including operation/CCR/grant/catalogue/source,
+ordered two-object read/write/readback plan, budget and deadline, participates in
+existing canonical request and approval-free digest joins. No translation to
+apply and no service administrative grant occurs.
+
+The shipped source package is deliberately closed: owner_admission is a literal
+false. An unsigned verified, owner_admission or human_control request flag cannot
+open it. Synthetic future-provider tests replace that literal in an isolated
+in-memory package only; those allows are not runtime admission or native evidence.
+This is an enforced refusal until the identity boundary exists, not a switch to
+turn on once a human approves a proposal.
+
+## Reuse the actual providers
+
+* KeyCape owns authentication/MFA and RS256 access-token issuance. Reuse
+  docs/approval-engine-auth-contract.md and docs/tenant-claim-contract.md from
+  KeyCape: exact issuer/audience/subject/principal_type/tenant/tenant_source,
+  expiry and assurance level/mfa/source/at. internal/taskexecution's proposed
+  source verifier consumes the token out of band using locally owner-pinned RSA
+  keys, trusted server time and no JWT-selected discovery URL. It returns an
+  opaque Initiator, never a token or an authorization decision. No real issuer,
+  key or client is installed in the source. Human initiating audience/client
+  admission is still missing; an approval-engine access audience cannot silently
+  be reused for task execution.
+* Access's existing callerauth TokenReview choke point authenticates the service
+  transport and binds secrets-engine to its exact Kubernetes principal. It does
+  not authenticate the request's subject human or prove representation. Reuse
+  that authenticated server identity, never caller transport_principal text.
+* User Engine owns canonical user and active tenant account/membership facts;
+  Tenant Engine owns authoritative tenant existence/lifecycle. Their live,
+  authenticated, freshness-bounded read interfaces must be integrated by Access
+  (PIP consumption), with unavailable/stale facts reducing authority. No new
+  parallel identity engine or caller-authored membership provider is introduced.
+* Approval Engine supplies the served approval claim and authenticated consumption
+  facts. Its human approver can differ from the initiating human: a successful
+  approval is not initiating identity. Existing claim/PDP canonical correspondence
+  and later independent consume confirmation remain mandatory.
+
+KeyCape explicitly states registration-supplied tenant is store isolation, not
+human membership. The source verifier therefore requires directory provenance,
+exact tenant:platform, verified MFA within 300 seconds and a currently valid
+RS256 token. This strict proposed ceiling currently refuses registration-only
+humans; changing that requirement requires owner-reviewed doctrine, not relabeling
+registration as directory. Cryptographic verification alone still grants nothing:
+User/Tenant membership, representation and exact operation are separate facts.
+
+## Required server injection and activation proof
+
+The task_execution_projection shape in the candidate policy is a proposed
+internal server representation, not an accepted public claim format. Access
+must acquire initiator token on a separate authenticated channel, verify it,
+resolve canonical user/membership/tenant using the owning PIPs, correlate it with
+the authenticated transport and full exact operation, and inject a bounded
+projection. Raw human JWTs must never enter CheckRequest context or decision/audit
+records. An HTTP-supplied projection must be rejected or discarded before any
+trusted projection is injected, including nested/duplicate-field collisions.
+
+Projection expiry must be the earliest identity/session expiry, provider
+freshness deadline, approved operation deadline and PDP authority ceiling.
+Fresh PIP retrieval/refusal and revocation visibility must be recorded; cached
+membership alone cannot silently extend a KeyCape session. Package activation
+requires an actual authenticated KeyCape origin/client, admitted User/Tenant read
+routes/identities, server-controlled provenance and exact request/claim binding.
+No raw JWT verifier endpoint, projection injection, transport-to-human binding,
+PIP resolver, new server route or native package deployment is implemented here.
+Only a reviewed versioned source successor may remove the hard refusal after
+these gates have executable counterexamples. There is no unsigned enable flag.
+
+## Tested scope and unfinished integration
+
+Source tests verify RSA signatures and wrong issuer/audience/principal/tenant,
+registration provenance, missing/stale MFA, expired/future token and absent key
+admission. Strict nested duplicate/trailing JSON is refused. Python uses the
+actual Secrets ExecutionContract parser and canonical request/approval digest
+functions; Go and OPA evaluate the same complete synthetic two-object descriptor.
+Synthetic future-projection allow and mutation denials prove candidate semantics;
+current package denies regardless of asserted flags. They do not prove providers.
+
+The candidate predicate is not a full independent typed owner compiler: source
+and body provenance, exact estate origin/CCR readiness, bounded parser admission,
+platform plan compilation and immutable body mediation remain Platform/Secrets
+requirements. Nor does it independently validate served approval claims, consume,
+run journal admission, dispatch or issue/revoke native grants. Existing journal,
+confirmation and descriptor work must be integrated before this can perform one
+metadata action. No existing operational task closes from this source package.