Mint a separate MAS workload key in the attended gate instead of copying the supplier key.
All checks were successful
CCR intake gate / gate (push) Successful in 2m14s
CI Smoke / host-smoke (push) Successful in 0s
CI Smoke / container-smoke (push) Successful in 1s

The lane design forbids copying the founder-held supplier key onto the
workload path. The gate now mints a second key on the MAS application, proves
it, writes it CAS=0 over HTTP, and deletes it if a later step fails.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 4541@bnt-lap001
Assistant-Session: 2099b3aa-d7d9-49a9-ab4e-fa8b7d0e39e8
This commit is contained in:
codex 2026-11-02 23:41:20 +01:00
parent e9a2f237b3
commit fbc4830aa0
5 changed files with 356 additions and 42 deletions

View file

@ -54,6 +54,10 @@ and is not created here.
denials still require this application's own key.
5. Provision the pair atomically with KV CAS=0 under the pair-writer policy
extended to this one path. The single-field paste desk is unsuitable.
The workload pair is a second API key minted on the same IAM application
inside the attended gate (`mas_evidence_publisher_gate.py
--mint-workload`). It is never a copy of the supplier key. The gate
deletes the minted key if the proof or the write fails.
6. Record positive reader proof and negative denials, then set delivery
admission. Export the admitted CCR and pin its SHA256 before creating
`/etc/mas-backup/primary.env`.