Trust & Threat Model

In practice, the parties don’t need unrestricted review of each other’s proprietary source code before reaching agreement. They agree on signed artifacts, measured builds, allowed network paths, logging rules, attestation evidence, and the key-release policy that ties them all together. High-assurance deployments, especially anywhere code handles regulated payloads, may still call for source review, third-party audit, SBOM review, or reproducible-build evidence.

The model provider distributes encrypted model artifacts and defines who may run them. A key-release authority releases model keys only to workloads that present valid attestation evidence matching that policy. The enterprise data owner controls which inputs are sent into the attested workload, where outputs are delivered, and how outputs and logs are retained.

This figure maps those responsibilities to administrative domains.

Figure 4 CoCo task workflow for attestation and workflow deployment

Table 3: CoCo Trust and Responsibility Model

Figure step	Diagram element	What it means
1	Model release policy	Model owner defines approved measurements and release conditions.
2	Enterprise data policy	Enterprise data owner controls callers, input/output paths, egress, logs, and retention.
3	Assurance authority	Key-release authority owns reference values, collateral, and release audits.
4	Kubernetes operation	OEM or platform operator provides cluster, nodes, firmware, networking and storage.
5	Model-key gate	Model weights become readable only inside the measured confidential workload and protected GPU session.
6	Request path	Enterprise requests traverse approved ingress, service, and NetworkPolicy controls.
7	Assurance gate	Evidence verification and key release replace direct platform trust.

Table 4: Persona Trust and Controls

Party	Owns or controls	Trusted for	Not trusted with
Model provider	Model weights, serving code, workload image, encrypted artifacts, model-key policy, approved measurements	Defining the approved workload and protecting model IP	Enterprise infrastructure administration, enterprise data stores, or platform logs
Enterprise data owner	Data-handling policy, approved users, retention policy, business risk acceptance	Defining what data may enter the service and what operational data may be logged or retained	Unencrypted model weights, model keys, or model internals
CC software provider	Confidential containers runtime, guest image or initrd, attestation components, Trustee/KBS integration, GPU integration, measurement tooling, support matrix, failure signals	Correct confidential-computing implementation, verifiable measurements, patching, and key-release enforcement	Unencrypted model weights, enterprise payloads, or platform administration unless explicitly contracted
Platform operator	Kubernetes cluster, worker nodes, firmware, GPU mode, runtime class, networking, storage, monitoring, SIEM, data paths, incident response, change control	Availability, correct scheduling mechanics, approved platform operation, and logs that exclude sensitive payloads	Unencrypted model weights, model keys, or decrypted runtime memory
Application or agent developer	Gateway, application logic, user experience, prompt handling, authorization, retention controls	Implementing application behavior, authorization, and logging under enterprise data policy	Model-provider keys or unencrypted model weights
Key-release authority	Reference values, verifier policy, key-release policy, KMS/HSM configuration	Correct policy enforcement and audit	Kubernetes or node administration by default
End user	Prompts, files, audio, images, or other inputs	Supplying authorized inputs to approved application endpoints	Model internals or administrative control

What this protects against: a cluster or node admin reading confidential guest memory, an attacker pulling unencrypted weights off node storage, key extraction from standard Kubernetes or VM secret stores, and standard debugging or administrative tools attached to the confidential workload. More broadly, anyone with privileged platform access, including cluster, host, storage, network, and support teams, shouldn’t be able to see model weights, model keys, or decrypted runtime memory through normal platform control.

What it doesn’t: a malicious workload image supplied by the model provider, vulnerable inference code inside the confidential pod, payload logging by the application itself, a compromised attestation or key-release administrator, side channels, or physical attack. The platform operator stays trusted for availability. They can still delete the pod, cordon the node, block the network, or refuse to schedule the workload. Confidential computing isn’t a defense against denial of service.