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 customer 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 a policy that allows secure key distribution with successful attestation evidence. A key-management authority implements the policy and 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.

Figure 4 maps those responsibilities to administrative domains.

Figure 4 Confidential VM Trust and Responsibility Model

Table 4: Confidential VM 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 audit.
4	CVM platform operation	OEM or platform operator provides host firmware, KVM/QEMU, OVMF, GPU assignment, and runbooks.
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 gateway, CVM endpoint, and network controls.
7	Assurance gate	Evidence verification and key release replace direct platform trust.

The different personas in the end to end deployment are trusted and untrusted with different artifacts in this deployment allowing a clean separation of ownership and access while all personas are outside the trust boundary of the execution environment where the AI model runs and data is provided to it. The following table explains the controls, trust each persona has:

Table 5: Persona Trust and Controls

Party	Owns or controls	Trusted for	Not trusted with
Model provider	Model weights, guest image contents, artifact encryption, model-key release policy	Defining the approved workload and protecting model IP	Access to enterprise infrastructure, persistent data stores, or operational 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
Platform operator	Bare-metal host, firmware rollout, CVM launch environment, networking, storage, monitoring, capacity, incident response	Availability, correct launch mechanics, and approved platform operation	Unencrypted model weights, model keys, or decrypted runtime memory
CC software provider	Guest image bootstrap, attestation client, measurement tooling, GPU CC enablement, image-build validation tooling, support matrix, failure signals	Correct confidential-computing implementation, verifiable measurements, patching, and key-release enforcement	Production model keys unless explicitly operating a trusted key-release service
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	Host or VM 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 host admin reading guest memory, an attacker pulling unencrypted weights off disk, key extraction from standard VM secret stores, and standard debugging or administrative tools attached to the confidential workload. More broadly, anyone with privileged infrastructure access — host, hypervisor, storage, network, datacenter, support — shouldn’t be able to see model weights, model keys, or decrypted runtime memory through normal platform control.

What it doesn’t: a malicious guest image supplied by the model provider, vulnerable inference code inside the CVM, 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 power the box off, block the network, or refuse to launch the VM. Confidential computing isn’t a defense against denial of service.