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

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.