docs: reconcile Claude readiness with authorization chain proof
All checks were successful
ci / validate (push) Successful in 1m32s

Assistant: codex
Assistant-Model: gpt-6-astra
Assistant-Session: 01a0726e-5232-73f2-aaca-2c05ceb62efb
This commit is contained in:
tegwick 2026-09-06 19:21:56 +02:00
parent 27a72537b2
commit c67a22dbe2
3 changed files with 42 additions and 2 deletions

View file

@ -127,3 +127,19 @@ approval-engine ActionAuthorization claim endpoint and access-engine Check
service, then configuration, per-lane approval and positive/negative checks.
The owner explicitly distinguishes these durable objects from State Hub
decisions. This update does not activate the route or verify the provider key.
## Authorization-chain proof update — 2026-09-06
Reviewed secrets-engine `f62d3fe` and its evidence note `64aeec9`. The owner
reports a complete claim → Check → CAS consume → backend integration proof
against a throwaway OpenBao. Authorization HTTP transport/sequencing is
stubbed, with wire contracts pinned to flex-auth fixtures. Negative cases
refuse before the backend. This is integration evidence, not production
authorization-service deployment or real Anthropic-key delivery.
Remaining live inputs are the consumer PDP and approval service endpoints,
production service credentials, the deployed policy pin, and each lane's
`approval.authorization_id`, followed by native-lane access verification.
SECRETS-WP-0009-T03 remains waiting. The existing custody-only CCR and stored
key do not supply these authorizations. Glas retains its blocked local profile
and must still verify pinned Claude startup and the combined real task.