feat: integrate durable authorization audit and runtime composition
Some checks failed
CI Smoke / host-smoke (push) Successful in 0s
CI Smoke / pytest-smoke (push) Failing after 1s

Assistant: codex
Assistant-Model: gpt-6-astra
Assistant-Session: 01a0e747-8f27-7242-8df8-8bc44f88c929
This commit is contained in:
tegwick 2026-09-28 12:01:42 +02:00
parent 3e386147fd
commit c9b6916dac
14 changed files with 767 additions and 16 deletions

View file

@ -47,8 +47,9 @@ A host composes `create_app(access_controller=AccessController(...))` with:
set. The token is reread on every call and is separate from the end-user token.
Remote `/v1/keys` responses never establish their own trust. Current/previous keys
can coexist in the mounted trust file; removing a key takes effect next call.
- `Audit.append`: an **owner implementation still owed** that returns only after
durable acceptance. Every allow must reach this sink before handler execution;
- `AuditCoreSink`: implemented against the owner
[eight-field ingestion contract](../../audit-core/docs/event-envelope.md), returning
only after an operational-custody probe and explicit durable acceptance. Every allow must reach this sink before handler execution;
a failed sink blocks reads as well as writes. Authorization receipts say
`authorized`, not “operation completed.” Domain commit/outcome audit remains a
separate requirement; this source seam does not claim transactional audit.
@ -58,7 +59,10 @@ A host composes `create_app(access_controller=AccessController(...))` with:
Do not implement these missing adapters as a constant allow, in-memory audit sink,
or an assertion copied from token claims. Tests use synthetic owners explicitly.
The current CLI deliberately provides no fixture adapter or production bypass.
A deployment composition factory and dependency health probes remain T02–T04 work.
An explicit `SecuritySettings`/owner-facts composition now owns the HTTP client
and closes it with the runtime. Audit custody is probed per append. Real owner-facts
admission and additional owner dependency probes remain T02–T04 work; see the
[owner integration review](owner-access-integration.md).
For this candidate all Hub resources are explicitly **platform-owned**. Other
target tenants are refused. Root requires AAL2/3, active account and tenants,
@ -124,8 +128,8 @@ browser PKCE sessions/logout and real MCP root login remain open.
2. T02: immutable root binding, registered audience/redirects, PKCE/MFA/recovery,
admitted live facts adapters, attended login/logout and revocation receipts.
3. T03: dedicated Hub policy and fact provenance review; authenticated deployment,
credential/key custody, durable audit implementation and native rotation probes.
4. T04–T05: composed deployable runtime, dependency health probes, all client/extension
credential/key custody, real Audit Core sender admission and native rotation probes.
4. T04–T05: deploy the admitted composition, complete dependency health probes and all client/extension
migrations, domain outcome audit, legacy lane rollback and full root journeys.
5. T06–T08: every platform/Railiance receipt, separate public-enable approval and
later role/delegation/tenant isolation. No milestone is closed by local fixtures.