diff --git a/README.md b/README.md index 5e680bc..1cabda8 100644 --- a/README.md +++ b/README.md @@ -38,8 +38,11 @@ Current constellations include: open-weight route, local bwrap sandbox. - `harness.agent-dev@1.0.0`: `rein-aharness`, remote agent-dev sandbox. -The two local profiles are currently `blocked` by the missing sand-boxer -owner-execution/runtime path. The remote profile is `unverified`: it may be +The two local profiles remain `blocked` pending their combined runtime, +credential-delivery and provider acceptance. Owner-mediated execution is +implemented, with separate non-secret boundary, runtime-startup, egress and +synthetic-credential proofs. Those proofs do not establish a real local model +run. The remote profile is `unverified`: it may be used only as an explicitly labeled proof attempt. No committed profile is currently declared `ready`. diff --git a/docs/anthropic-workload-key.md b/docs/anthropic-workload-key.md index 306610e..9618c86 100644 --- a/docs/anthropic-workload-key.md +++ b/docs/anthropic-workload-key.md @@ -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. diff --git a/workplans/GLAS-WP-0012-first-local-profile-production-proof.md b/workplans/GLAS-WP-0012-first-local-profile-production-proof.md index 337bb06..867ec08 100644 --- a/workplans/GLAS-WP-0012-first-local-profile-production-proof.md +++ b/workplans/GLAS-WP-0012-first-local-profile-production-proof.md @@ -258,3 +258,24 @@ record an unresolved approval/native action-vocabulary and embedded-claim digest mismatch for dual-control requests. This is owner integration evidence, not successful live activation; SECRETS-WP-0009-T03 remains wait. No new activation receipt was found in the Glas inbox. T02 remains waiting. + +## 2026-09-06 authorization-chain owner return + +Reviewed secrets-engine `f62d3fe` / `64aeec9`. Owner reports claim → Check → +consume → backend integration against a throwaway OpenBao, including denial, +unreachable service, invalid claim, missing digest, consume conflict and action +mismatch refusal before backend access. Authorization transport is stubbed; +wire shapes use published flex-auth fixtures. Do not describe this as a live +production service or Anthropic delivery proof. + +Owner now identifies deployment/configuration as the remaining live gate: +consumer PDP service and approval-engine rollout, production service +credentials, deployed policy pin and per-lane authorization id. +SECRETS-WP-0009-T03 remains wait. Earlier digest-defect notes are historical; +use this latest owner return for the integration status. Native lane positive/ +negative access checks, pinned Claude startup, provider scope/budget inputs and +combined Glas acceptance remain outstanding. T02–T05 stay wait. + +Review found no pending local changes or new inbox messages. Corrected stale +README wording that still called owner execution missing; the implemented +mechanism and its separate proofs do not change profile readiness.