access-engine/docs/service-task-execution-contract.md

Proposed faithful Secrets service task execution successor

Source component for existing SECRETS-WP-0013 and RPF-WP-0035-T12. Based on accepted-intent technical assessment in /tmp/execute-ccr-accepted-intent-assessment.json. This is neither foreign owner acceptance nor a new doctrine choice, live caller mapping or native permission.

Principal and scope

The initiating/represented principal for this first pilot is the admitted Secrets service itself. It does not claim to represent a named human. The operation still declares human-control approval; the authenticated human approver is a separate principal and cannot supply service caller authentication. Accepted v0.8/GH013/ GH016 do not impose universal human initiation/User/Tenant membership on every metadata action. Operations deliberately representing a human or relying on human membership need their own verified initiating/delegation/provider contract.

The prior proposed human package secrets-engine.task-execution v1 and its literal false gate remain byte-for-byte unchanged. This separate proposed secrets-engine.task-execution.service-pilot v1 package is not a toggle of that variant, not legacy lifecycle v2 apply and not whole successor-standard acceptance. Its literal runtime_admission=false keeps every runtime policy evaluation closed. Candidate-predicate characterization never flips that constant or grants an act.

Concrete authenticated source input component

internal/taskexecution.ServicePilotInputs uses actual existing callerauth Authenticator.Authorize/TokenReview machinery, fixed enforce mode, flex-auth audience and the explicitly proposed mapping:

system:serviceaccount:secrets-engine:secrets-engine -> secrets-engine/type service, protected system secrets-engine, tenant:platform.

The transport/system association is present in current values/secrets-engine.yaml; the explicit transport-to-subject association here is new proposed source and still needs owner/runtime admission. A2 system mapping alone does not prove arbitrary request subjects. The source constructor accepts only an owner-installed reviewer, never a request-selected principal or warn/disabled mode. The unexported ServiceInput records actual successful review, fixed matching subject/type and nonzero future transport expiry; zero/default input refuses. Its detached request snapshot never contains a bearer token or an unsigned authenticated flag.

service_actor_binding is PUBLIC DECLARED metadata included before approval issue: version proposed-service-task-caller/v1, exact principal/subject/type/tenant. It is not authentication evidence. Prepare compares it to the independently authenticated caller and source mapping. Incorrect/missing/extra binding fields refuse. Claimed human/delegation/projection/verified/owner_admission fields refuse rather than being interpreted as authority. Deadline must be live and no later than actual reviewed transport expiry. The returned input is eligibility preparation, not a PDP allow, trusted served approval, consume confirmation or operational entitlement.

Maker tests use a synthetic TokenReviewer, not actual Kubernetes authentication. Actual deployed TokenReview origin/CA/RBAC/audience/projection rotation and mapping admission must be proved before runtime use. The B1 source path now wires the actual service adapter into /v1/check only when the exact installed service-pilot v1 package is selected. Startup requires enforced retained flex-auth audience and the one exact Secrets mapping. The actual reviewer authenticates once; the detached ServiceInput is rechecked for caller/operation expiry at use. The single existing decision engine records only a signed DENY on this path; unsigned output or an accidental policy allow is withheld before recording. No native executor or Approval fact join is installed. A forged public service_actor_binding alone remains insufficient.

Generic Check, BatchCheck, ListAllowed and CLI/HTTP evaluation cannot evaluate execute-ccr under any package; the dedicated typed path is required. The exact service pin also refuses generic calls and batch requests. This deliberately invalidates the older separately named synthetic positive stack fixture on the new source. Its positive proof remains historical at Access ec21518e, not proof for B1. Do not add a fixture exception; a positive successor must use reviewed B2/B3 provider joins. The literal service policy false gate is unchanged.

B1 retains the exact original request context, carried claim, submitted digest and producer-owned canonicalization. Its bounded strict JSON decoder refuses duplicates, trailing/unknown typed fields and oversized input. The caller's Approval blob remains unverified and cannot enable anything. B2 requires the Approval owner's fact contract/vector review; B3 additionally requires exact server-owned native-act representation and the complete trusted join. Fresh provider observations stay out of band: no refreshed context or claim replacement may relax strict Secrets request correspondence. Access never invokes a credential-carrying Python subprocess, consumes approval or performs the effect.

Exact operation and independent gates

Owner compiler derives exact metadata CCR/catalogue/source/body/target plan. Whole SECRETS-EXEC-20261011-v1 descriptor binds unique operation UUID, CCR/grant immutable hashes, consumer thirteen-field local catalogue fingerprint, independently pinned source roles, estate/origin, expected before/after states, six GET/PUT/GET reader ACL then GET/PUT/GET role operations, bounded deadline and 120s/12-use ceilings. Platform rederives exact body bytes before each call. This source package models shape, service declaration, production tenant/stage and human-control claim shape; it neither authenticates sources nor compiles full baseline/grant/estate/deadline.

Required sequence remains:

1. Authenticate the admitted service caller and explicitly bind its subject; obtain exact owner-derived complete request before approval issue. Local/public discovery only precedes consume. No caller projection or founder bootstrap substitutes.
2. Obtain live served approval from independently authenticated Approval Engine origin; require declared human_control with verified human approver under GH016, fresh validity and canonical PDP path. Approval is a fact, never a decision.
3. Access renders fresh exact package/version result over authenticated caller, owner operation and served facts; decision binds full enriched request, exact submitted request, and approval-free request. The claim's recorded pdp_digest must equal served binding.approval_binding_digest. Use repaired Go-compatible canonical serialization; do not translate Approval native digest or rewrite old claims. Server must make trusted input provenance reconstructable and prevent caller substitution. This source candidate does not install that server join.
4. PEP obtains authenticated successful consume for exactly approval/request/decision before any protected consumer login/effect. Platform independently confirms original consumption using trusted provider transport; supplied booleans/receipts and same-digest CAS retry are not a fresh execution grant.
5. Owner-private durable journal reserves the same operation once, maintains exclusive admission and pending intent before each exact phase/call, and refuses replay or unknown recovery. Whole canonical request, caller mapping, body/plan and source correspondence remain unchanged across reserve/consume/applying/native phases.
6. Independently authenticate CCR38/OpenBao service provenance after consume. Owner separately admits task-execution-grant CCR, exact disposable target/estate/route and bounded owner-held ephemeral token. Token is never exported to the consumer; native ACL alone cannot constrain policy/role bodies. Mediator enforces exact body equality, real expiry/use budget, native readback, revoke and temporary cleanup.
7. Lost/uncertain response, crash, incomplete revoke or cleanup records unknown and does not auto-retry. Owner reconciliation plus fresh exact authorization governs another action. Actual positive/negative/interruption proofs and owner acceptance are required before pilot completion, then separately reviewed lifecycle adoption.

The pure candidate predicate's syntactic pdp_digest/freshness checks do not validate live provider provenance, exact digest equality, human approver identity or consume. They are source shape characterization only. Literal runtime_admission=false enforces that absence. Authentication plus approval alone cannot enable it. Future source successor must integrate all applicable gates, not expose an enable flag.

Verification and limits

Maker source tests verify supported synthetic authenticated-service input binding, wrong transport/subject/type/audience/tenant, missing/expired transport, deadline, forged binding/delegation/flags and detached snapshot/zero-input refusal. Actual Secrets ExecutionContract parser generates complete six-call synthetic input; OPA candidate predicate is queried directly for eligible/negative shapes while normal policy evaluation remains deny. Old human gate is unchanged. Source fixtures register synthetic attributes solely for package-validation checks, not an actual live catalogue or estate registry. No runtime image, credential, provider admission, API change or native effect occurs.

Exact component omissions (not completion evidence)

This source candidate is STRUCTURAL CHARACTERIZATION and authenticated-input preparation only. Its predicate checks a syntactically tagged pdp_digest, not its actual equality to enriched approval_binding_digest. It does not prove served claim origin or verified approver identity, reconstruct canonical native claim binding, validate full submitted/enriched DecisionEnvelope or consumption triplet, bind actual compiler bytes to the whole descriptor, enforce journal phase/order, admit grant/baseline/estate or perform an effect. Those are explicit implementation requirements; a matching predicate and reviewed TokenReview input are insufficient. The service adapter carries authenticated transport evidence outside the canonical request. B1 connects it only to signed-DENY HTTP evaluation; provider validation and executable eligibility remain absent. A caller's service_actor_binding remains a public declaration independently compared by the adapter, never a substitute for runtime provenance or exact operation authority.

The old human fixture's epoch nanosecond integer exceeds the repaired consumer's safe integer profile. Compatibility repair preserves that original projection as an explicitly refused counterexample and tests descriptor-only canonical parity. The old human package/identity schema are unchanged; no nanoseconds are rounded or relabeled, no RFC3339 projection contract is invented, and no constant is flipped. Any future human identity shape needs separate owner-reviewed source integration.