# 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.