coulomb/approval-engine
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Disable the live operator client, keep its custody

Browse source 
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
This commit is contained in:
tegwick 2026-09-10 20:49:36 +02:00
parent bfb1e66646
commit 2fdb01d42a
2 changed files with 39 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

26
docs/keycape-service-registrations.md
View file

@ -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

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

@ -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