# KeyCape approval-client custody: review packet

Prepared 2026-09-09 by the-custodian. Both requests are **proposed**; no named
approval or custody mutation has been recorded. This is the review gate for
RPF-WP-0035-T05, consumed by HFACT-WP-0001-T03.

| Request | Secret path and field | Client authority | Pending decision |
| --- | --- | --- | --- |
| [CCR-2026-0017](../../credential-change-requests/CCR-2026-0017-keycape-secrets-engine-approval-client.yaml) | `platform/workloads/secrets-engine/approval-client`, `CLIENT_SECRET` | `approval:read`, `approval:consume` | `b533a271-b704-4c5c-98a2-9a5951aadfb6` |
| [CCR-2026-0018](../../credential-change-requests/CCR-2026-0018-keycape-approval-engine-operator-client.yaml) | `platform/workloads/approval-engine/operator-client`, `CLIENT_SECRET` | create/read/approve/revoke/supersede/observe/emit; no consume | `efa90517-0cae-4eb6-a68d-5b0489c84d65` |

Both require **platform-operator and key-cape-owner** review. Each has its own
exact-path policy, Kubernetes auth role and ClusterSecretStore, bound to
`external-secrets/external-secrets`, limited to `sso`. ESO owns the resulting
Secret; authentication tokens have a 15-minute TTL. Client secrets require
explicit rotation or registration disablement; token expiry does not revoke them.

The approved object would authorize verifier-side custody only. Client-side
retrieval, audit sender/receiver custody, operator `approval:consume`, adoption
of the Qonto Secret and factory spending remain outside these two requests.

Technical review completed: both CCRs validate, their generated policies match
the two source HCL files, and the delivery manifests map exactly to the declared
paths and fields. The signed upstream issuer is verified; NetKingdom's exact live
pin is independently read back at Secret revision `58713343`. The compatible
KeyCape image and rollout patch are prepared. These checks are evidence for the
review, not substitutes for either named approval.

Execution still follows the [owner rollout sequence](keycape-approval-clients.md)
through the founder-attended Warden/OpenBao envelope: policy/roles, CAS=0 initial
custody, Valid stores, SecretSynced delivery, compatible config/image replacement,
then positive and negative acceptance and metadata-only receipts. The generated
plan leaves initial secret provisioning to the contained owner procedure; it is
not an already exercised end-to-end activation command. Finish and exercise that
procedure before opening the activation window. Current proposed requests refuse
`apply-plan`; no status has been changed to get around that refusal.

Review outcome: approve, deny or needs changes, naming the reviewer and the role
they are accepting. Both required role confirmations must be recorded for each
CCR before execution. A generic CLI status change alone is insufficient evidence
that both reviews occurred. No owner messages or browser login were triggered
by preparation of this packet.