access-engine/docs/task-execution-pdp-consumer-contract.md

# Exact execute-ccr PDP consumer integration (source preparation)

Access source baseline: c829e530309d4a885a7dbe34ddc316e0c25d205f.
No native readiness or formal owner assent is established by this staged artifact.

## Existing interface, without a new grant API

Use POST /v1/check with CheckRequest, DecisionEnvelope and the existing served
approval claim/consume APIs. pkg/api/canonical.go already hashes nested context
values, including an execution_contract object. No new canonical digest function
or access-engine execution ledger is needed. Access owns policy decisions only;
Secrets owns PEP lifecycle and one-shot admission, Platform owns OpenBao custody.

The published request action for the new CLI must be execute-ccr, resource
secret-catalog-lane under system secrets-engine, id catalog:<catalog id>, stage
prod and tenant tenant:platform. CLI execute-ccr must never send apply: shipped
lifecycle v2 accepts apply while ignoring all execution_contract contents. That
existing grant is not the reviewed metadata execution contract. Preserve existing
12-action behavior and add a separate owner-reviewed exact execute-ccr policy
version/action declaration and denial tests before publication.

The proposed policy must enforce human_control true, served approval kind/issuer/
valid_now/human_control/pdp_path, closed contract_version and metadata-apply-ccr,
nonempty exact operation_id, bounded deadline/budget, explicit target/body/catalog/
CCR/grant/source hashes and trusted principal representation. Hash existence is
shape, not provenance: body equality and owner-source reconstruction remain PEP
obligations. Policy cannot compare its own post-evaluation request digest.
Unknown action, missing contract/approval, foreign principal and older package
must refuse. A package/version pin is validated in envelope provenance, not hashed
as an authority field: api.RequestDigest excludes request.policy_version.

## Mandatory digest joins

1. Compile owner sources and catalog into the complete claim-free request.
   All execution fields are inside context.execution_contract before issue Check.
   Use context.purpose for consumer purpose. Top-level purpose is reserved for
   advisory readback and enforcement /v1/check refuses it.
2. Issue approval against claim-free Check's enriched binding.request_digest.
   Approval Engine records that value as claim.binding.pdp_digest.
3. Fetch the live served claim, attach it only at context.approval, and Check the
   exact same request again. Retain the submitted request in owner memory.
4. PEP validates binding.submitted_request_digest against its submitted request;
   binding.request_digest against the returned enriched binding material; and
   claim.binding.pdp_digest against binding.approval_binding_digest. The latter
   is the enriched request with only top-level context.approval removed. It does
   not remove execution_contract, human_control, catalog_target or purpose.
5. Validate signature/served authenticity using existing configured PEP path,
   provenance package/version, caller record, registry snapshot, allow lifetime,
   live claim freshness, and exact subject/action/resource/tenant/context. Registry
   enrichment can alter subject/resource attributes: do not compare locally
   computed claim-free digest to claim.pdp_digest.
6. Consume once with approval_id, full enriched binding.request_digest and exact
   decision_id. Approval Engine's consume checks request digest format/CAS, not
   semantic correspondence to issue pdp_digest; steps 1–5 are mandatory. Independently
   read the durable approval consumption triple through the authenticated owner
   route and match it before OpenBao. Idempotent response is never fresh admission.
7. A changed operation UUID/method/path/body/source/catalog/subject yields a
   different approval-free digest; require a fresh exact approval. Retries only
   return final stored receipt. Unknown consume/backend outcomes require recovery.

## Minimal consumer code delta

Secrets authorization.build_action_request gains a strict optional keyword-only
execution_contract parameter. validate/compile it in Secrets' owner compiler,
then deep-copy it into context. Reject a contract on any action except execute-ccr,
reject execute-ccr without the contract. Set human_control true on this action
regardless of legacy catalog default. Catalog_target remains included.

Thread the SAME validated object through approval_consume._expected_request,
resolve_approval_observation and authorize_action. Today _expected_request rebuilds
from cfg/entry and drops any caller-added context; merely adding context in CLI
would not reach the claim/PDP join. No arbitrary caller request/body injection.
Require the execution boundary's verified initiator identity, not cfg/environment
strings, and exact package/version configuration for execute-ccr. Return the
existing ConsumeBinding and confirmed ConsumedApproval, never an opaque approval
label. require_production_consume runs only in owner child after admission reserve.

Platform independently recompiles exact operations and compares full digest,
then invokes the reviewed Secrets consume path at the actual effect boundary.
Its persistent one-shot ledger requires unique approval+digest and durable states
before each external call. This ledger and restricted backend do not currently
exist; audit outbox and bare consumed bool do not substitute. No unrestricted
subprocess, generic OpenBao apply, caller ACL/HCL, path override or bearer return.

## Principal and route truth

values/secrets-engine.yaml enforces Kubernetes TokenReview for
system:serviceaccount:secrets-engine:secrets-engine representing protected system
secrets-engine. This authenticates transport caller/system correspondence only:
internal/callerauth/auth.go does not bind CheckRequest.subject to that identity.
The v2 policy separately admits only subject secrets-engine/type service. A
caller-authored initiating human is neither authenticated by this path nor an
admitted v2 subject. An explicit identity-owner verified representation contract
plus policy grant is required before actual initiating-principal design can ship.
Do not rename service:secrets-engine to secrets-engine silently; authentication
service subject and PDP principal have different published vocabularies.

FLEX-WP-0023 records historic enforce-mode positive/negative native caller proof.
This is source evidence of an existing route, not a current live probe. Operator
CLI access needs attended admitted TokenRequest/tunnel/network path; in-cluster
DNS is not a workstation route. No token was requested and no native query ran.
FLEX-WP-0036 runtime rename remains active: keep existing flex-auth coordinates
until exact consumer transition is separately admitted. No new executor route,
metadata CCR, task execution grant, source pin, real native effect, cleanup proof,
principal representation or steady-state workflow adoption is supplied by this
stage. RPF35-T02 and Secrets T06 must remain open.

## Verified source tests

Run go test ./pkg/api ./internal/policy -run ExecutionContract -count=1 in staged
source. API tests cover ten changed semantic fields, claim attach/removal,
registry enrichment and correlation ID irrelevance. Policy test runs actual v2
Rego: execute-ccr denies unknown_action, fake execution context on apply still
allows (demonstrating the semantic gap), human principal denies wrong_subject_type.
These characterize shipped behavior and digest integration; they do not claim
new entitlement policy or executor is shipped.