Disable the live operator client, keep its custody

key-cape reports the withdrawal came too late: approval-engine-operator
was provisioned in the 2026-09-09 custody window and is wired into a pod.
A live credential that can create and approve approvals, presented by
nobody, is a worse resting state than either extreme.

As requesting owner: disable, do not delete. CCR-2026-0018 stands so it
is restorable under the narrowing constraint once a presenter exists. A
recorded expiry was rejected — it promises to act later on a capability
that is dangerous now, guarding exactly the case where nobody is
watching.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HyybaE7DUXrWYrhbnESCTe

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 1275879@bnt-lap001
Assistant-Session: eb464208-f821-41b2-bc5a-a6c33d92a8ad

docs/keycape-service-registrations.md

@@ -165,6 +165,32 @@ evidence at all is `gate-house`'s to rule on.
 `secrets-engine-approval` above is unaffected — it has a real presenter, a
 narrow scope pair, and is the client that unblocks `T05`.
 
+### It was already live — disable the registration, keep the custody
+
+2026-09-10: key-cape reports the withdrawal came too late. The client was
+provisioned in the 2026-09-09 attended custody window and verified there
+(`docs/evidence/2026-09-09-keycape-verifier-admission.json` records
+`exact_claims_verified` and a working exchange for `approval-engine-operator`),
+its secret is in the namespace and wired into a pod.
+
+So the estate holds a live confidential credential that can **create and
+approve** approvals, that nobody presents, and that no consumer is waiting on.
+Standing capability with no counterparty is a worse resting state than either
+extreme: it serves no one, and it is the shape found later by someone other
+than its owner.
+
+**Decision, as requesting owner: disable the registration, keep the custody.**
+Not delete. `CCR-2026-0018` verifier custody stands, so the client remains
+authenticable and restorable the moment a presenter is named; the re-request
+constraint above still applies — narrowed to that presenter, and
+`approval:approve` must not travel with the operational scopes. key-cape
+executes the disablement with railiance-platform as the deployment change.
+
+The middle option — leaving it standing with a recorded expiry — was rejected
+deliberately. An expiry is a promise to act later on a capability that is
+dangerous now, and the thing it protects against is precisely the case where
+nobody is watching.
+
 ## Human approver client — not supplied (2026-09-08)
 
 `KEY-WP-0013-T02` asked for two exact strings for the human approver

workplans/APPROVAL-WP-0002-production-readiness-and-consumer-adoption.md

@@ -275,6 +275,19 @@ must not be treated as satisfying it. Evidence:
 `docs/evidence/2026-09-10-human-control.json`. No production approval or database
 migration occurred during these tests.
 
+2026-09-10 (second): key-cape reports the `approval-engine-operator` withdrawal
+came too late — the client was provisioned and verified in the 2026-09-09
+attended custody window, secret in the namespace and wired into a pod. A live
+confidential credential that can create *and* approve approvals, presented by
+nobody. As requesting owner: **disable the registration, keep the custody.**
+`CCR-2026-0018` stands so it is restorable when a presenter is named, under the
+same narrowing constraint. The recorded-expiry option was rejected as a promise
+to act later on a capability that is dangerous now. Recorded in
+`docs/keycape-service-registrations.md`; key-cape executes with
+railiance-platform. Also confirmed by key-cape as closed and now removed from
+our open list: the human client carries `[openid, approval:read,
+approval:approve]`, and the `assurance` object has a published shape.
+
 ## Harden durable storage and migrations
 
 ```task