railiance-platform/docs/credential-lane-designs/keycape-approval-clients-review.md

KeyCape approval-client custody: review packet

Prepared 2026-09-09 by the-custodian. Both requests are approved by the user as platform operator and KeyCape owner, explicitly recorded on 2026-09-09. The admission receipt is here. This is the review record for RPF-WP-0035-T05, consumed by HFACT-WP-0001-T03.

Request	Secret path and field	Client authority	Resolved decision
CCR-2026-0017	platform/workloads/secrets-engine/approval-client, CLIENT_SECRET	approval:read, approval:consume	b533a271-b704-4c5c-98a2-9a5951aadfb6
CCR-2026-0018	platform/workloads/approval-engine/operator-client, CLIENT_SECRET	create/read/approve/revoke/supersede/observe/emit; no consume	efa90517-0cae-4eb6-a68d-5b0489c84d65

Both named platform-operator and key-cape-owner reviews are approved. 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 requests 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 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 contained owner command is now scripts/keycape_approval_custody.py activate. It preflights both config and deployment changes, seeds with CAS=0, verifies native and namespace boundaries, then calls NetKingdom's contained compatible rollout. A failure restores the prior config/image pair before detaching verifier delivery; initial KV versions remain in custody. The four new exact data/metadata deny stanzas extend the coding-agent boundary without changing any grant.

Validation: six checks against a disposable local OpenBao, eight config/rollback tests, and real HTTP signature/claim/scope acceptance against the pinned KeyCape image with synthetic keys. Production in-pod CLI and existing-human-login checks remain part of the live window. The image exercise omits the in-pod CLI explicitly. Use a unique private receipt and protected owner recovery path; a fresh attended login after the rollout establishes the existing human path on the new build.