# KeyCape approval-client custody: accepted verifier delivery

Both CCR-2026-0017 and CCR-2026-0018 have the user's explicit approval as platform
operator and KeyCape owner. Both are now **verified**. Their existing decision
IDs remain resolved; no renewed review is needed for this completed scope.

[Combined live receipt](../evidence/2026-09-09-keycape-verifier-admission.json) records version-1 custody, both ESO
stores and Secrets, exact native scope/auth/namespace denials, reader revocation,
compatible pinned KeyCape deployment and both service-client verification runs.
The existing human OpenBao login passed before and after the rollout.

The two Warden fetch selectors remain unresolved: these CCRs authorize verifier
copies only. Client-side reads, audit custody, natural JWT expiry, real predecessor
rotation and factory operating/spend admission remain with the existing owner
records. See [the owner sequence](keycape-approval-clients.md).

The exercised procedure is `scripts/keycape_approval_custody.py`: `activate` for
first provision, `resume-activate` only with a completed rollback receipt, and
`verify` for existing custody. The selected kubeconfig must identify railiance01;
on this workstation it is `/home/worsch/.kube/config-railiance01`. Use the
Warden attended wrapper, a unique metadata receipt and protected recovery file.
The pinned native verifier is extracted from image digest `7ff54c54e63e...` and
hash-checked; its child environment carries credentials only during execution.
No Kubernetes egress policy changes are needed.

Validation: eight local OpenBao checks, ten config/rollback/clock checks, 53
existing credential-change tests, plus a disposable pinned-image HTTPS exercise
that runs the exact native verifier with synthetic keys and client credentials.