Track confidentiality guarantees across model execution, tools and agent delegation

[imran-siddique]

Objective

Establish when a confidentiality policy survives model execution, tool use and agent delegation. Track reusable contracts, enforcement and evidence across repositories. Keep model-, vendor- and cloud-specific mechanisms in explicit adapters; unsupported properties must remain visible.

Work queue

Work one bounded slice at a time. Begin with response requirements, then implement and validate before advancing that issue's status. Hardware work has separate prerequisites and is not authorized merely by this tracker.

• 1. Define and implement authenticated responses bound to an attested request: Define and implement authenticated responses bound to an attested request ca2a#188 — active: live response authentication implemented in Authenticate live handoff responses and preserve timeout diagnostics ca2a#187 at 4f2fcab; 57 focused tests and 691 full-suite tests pass locally. Hosted CI passed (12 successful checks, two main-only skips); implementation review remains pending.
• 2. Validate that agent egress cannot bypass configured release controls: Validate that agent egress cannot bypass configured release controls cmcp#659 — reference #662 merged; follow-up Supervise confined agents and validate policy and export boundaries cmcp#663 at a56f5ab adds bridge supervision, live restrictions and export-leak regressions. All 57 hosted confinement tests and 17 CI checks passed. Bounded reference criteria are exercised; acceptance review remains pending.
• 3. Bind deployed broker code and effective configuration to appraised workload identity: Bind deployed broker code and effective configuration to appraised workload identity weight-custody-manifest#144 — approvals, deterministic boot packaging and provisional native loader implemented in Add broker provisioning, deployment approvals and provisional boot loader weight-custody-manifest#143 at 4497db9. All 936 local tests, ten native Linux tests and 15 hosted checks passed. Actual bundle repeats on one runner. Full VM boot, firmware/kernel coverage and native-SNP hardware validation remain outstanding.
• 4. Validate provisioning lifecycle under restart, rollback and interrupted outcomes: Validate provisioning lifecycle under restart, rollback and interrupted outcomes weight-custody-manifest#145
• 5. Demonstrate protected model provisioning, loading and execution: Demonstrate protected model provisioning, loading and execution weight-custody-manifest#146
• 6. Define explicit authorization for releasing confidential data and derived outputs: Define explicit authorization for releasing confidential data and derived outputs cmcp#660
• 7. Build a reproducible acceptance harness for confidential workflows across components: Build a reproducible acceptance harness for confidential workflows across components integrations#199

Execution order follows dependencies: response binding and confinement can be developed in software; measured identity is required before hardware lifecycle and protected-execution claims; disclosure authorization composes with confinement. The shared harness can start synthetically, but its live milestone depends on the component gates.

Existing work to reuse

• tracker: complete confidential-hardware conformance and release assurance decision ca2a#47: confidential-hardware conformance and release-assurance decision.
• Execution lineage is hash-linked but unsigned, so a different history can be presented around a valid chain ca2a#168: signed execution lineage; response authentication alone does not fix it.
• [phase-2] Policy enforcement inside TEE — Cedar evaluation runs in the enclave, not at API boundary cmcp#124 and feat(tee): seal the TRACE signing key to the gateway measurement (RFC P3) cmcp#462: enforcement inside a TEE and protected signing-key custody.
• feat(attestation): cryptographically verify NVIDIA GPU evidence end to end cmcp#537: GPU evidence verification; a verifier is not proof of protected execution.
• Bind MCP Tasks and authenticated callbacks into cMCP evidence cmcp#567 and Separate workload identity, represented user, and delegated authority claims cmcp#568: task/callback evidence and principal/delegation semantics.
• Define and enforce graceful serving stop when re-attestation fails weight-custody-manifest#119 and PR #141 in that repository: serving-stop behavior.
• Enforce nonce-bound OCSP for attestation-key revocation, and fail closed when unreachable weight-custody-manifest#123: attestation revocation freshness.

Delivered foundation and active PRs

• Enforce sensitivity ceilings at tool and response boundaries cmcp#657 merged: operator-owned tool/response sensitivity ceilings and selected log suppression. It does not establish confinement.
• Add Linux agent confinement reference and causal bypass tests cmcp#662 merged the confinement reference/harness. Follow-up Supervise confined agents and validate policy and export boundaries cmcp#663 is active for supervision, live restrictions and export boundaries; neither establishes hardware-backed confinement.
• Add broker provisioning, deployment approvals and provisional boot loader weight-custody-manifest#143 remains the active provisioning/container, deployment-approval and provisional boot-loader PR.
• Authenticate live handoff responses and preserve timeout diagnostics ca2a#187 remains the active handoff diagnostics/requirements PR.
• Initial controls landed in Harden key release and add owner-side broker provisioning weight-custody-manifest#142, Enforce verifier-owned SNP platform policy cmcp#656 and Require hardware appraisal and add mutual SNP acceptance harness ca2a#186.

Keep existing open PRs current. A merged PR is delivered history, not a branch to keep extending. Do not close a hardware or composition issue merely because a component PR merges.

Completion discipline

Every work item needs an explicit threat model and trusted base, bounded acceptance criteria, implementation/revision links, reproducible evidence, negative controls and remaining limitations. Report requirements drafted, implemented, locally tested, hosted-tested and hardware-validated as distinct states. Closing an issue requires its stated acceptance criteria, not a generic green CI result.

The parent closes only when a documented deployment satisfies the selected end-to-end claim and the independent acceptance run is reproducible. Model correctness, unrestricted side-channel resistance and retroactive revocation of disclosed plaintext are not implied.

This issue is the canonical cross-repository backlog. Child issues own their acceptance details; local notes retain execution evidence rather than a second competing task list.