Confidential computing: protecting a model and its inputs from the infrastructure operator

Standard cloud security protects data in transit and at rest, but the data is typically decrypted into plaintext memory while it is actually being processed — visible, in principle, to anyone with sufficient privileged access to the underlying host operating system or hypervisor. Confidential computing research asks whether inference can run without ever opening that exposure window.

Encrypting data at rest and in transit still leaves it naked while it's actually being used. Confidential computing is the attempt to close that last window.

A trusted island inside untrusted infrastructure

Slalom: Fast, Verifiable and Private Execution of Neural Networks in Trusted Hardware ↗, by Tramèr and Boneh, is foundational work in this space. A trusted execution environment (TEE) — a hardware-isolated, encrypted region of a processor, such as Intel SGX or Sanctum — keeps a portion of a computation invisible even to a compromised host operating system or hypervisor. Slalom's specific contribution is recognizing that a TEE alone is too slow for practical deep-learning inference, so it securely delegates the bulk of a neural network's linear-layer computation — the expensive matrix multiplications — to a faster, co-located but untrusted processor, while the TEE verifies that the offloaded results are actually correct.

Architecture / trusted execution

Verify the fast path instead of trusting it blindly

FIG 01

Running canonical networks including VGG16, MobileNet, and ResNet variants inside an Intel SGX enclave with GPU offload, the paper reports 6x to 20x throughput increases for verifiable inference, and 4x to 11x increases for verifiable and private inference, compared with running the equivalent computation entirely inside the slower trusted environment alone.

The threat model this actually addresses

It matters to be precise about what confidential computing protects against, because the term gets used loosely. The specific threat is a curious or compromised infrastructure operator — someone with privileged access to the host, hypervisor, or physical hardware a workload runs on, who should not be able to inspect the workload's memory even with that access. This is a narrower and more specific claim than "this system is secure" in general: confidential computing says nothing, by itself, about application-level vulnerabilities, credential management, or network-level attacks, all of which need their own controls regardless of whether a TEE is in use.

Scope / threat model boundary

One specific threat, not a whole security program

FIG 02

From an academic result to a production platform choice

The underlying hardware landscape has moved substantially since Slalom's 2018 publication. Modern confidential-computing offerings from major cloud and chip vendors have extended the same trusted-execution principle from a single enclave running alongside an untrusted co-processor, to full confidential virtual machines, and — more recently — to GPUs themselves, including NVIDIA's confidential computing capability on H100-class hardware, AMD SEV-SNP, and Intel TDX. The principle Slalom established — isolate what matters, verify what you offload — is the same; the scope of what can now run inside that isolation has grown to cover production-scale inference workloads that the original academic result could only gesture toward.

What this changes in production

Regulated-industry inference

Where a customer's model weights or a user's request payload must remain inaccessible even to the cloud provider operating the underlying hardware — a common requirement in healthcare, finance, and government workloads — confidential computing is one of the few technical mechanisms that can back that requirement with hardware-level attestation rather than a contractual promise alone.

Multi-tenant model hosting

Different customers' data sharing the same physical infrastructure need cryptographic isolation from each other, with attestation that proves that isolation held, not just an assumption based on the hosting provider's operational practices.

Protecting proprietary model weights on infrastructure the owner doesn't control

A model owner deploying to infrastructure they do not fully operate can use confidential computing to reduce the risk of weight exfiltration by the hosting operator itself — a distinct concern from protecting the model from external attackers.

A production checklist

Before relying on confidential computing for a security or compliance claim, the team should be able to answer:

• Is the specific threat being addressed — a compromised or curious infrastructure operator — actually the risk this deployment needs to mitigate, or is a different threat model being conflated with it?
• What is the current disclosed vulnerability and patch status of the specific TEE hardware generation in use?
• Does confidential computing here replace, or sit alongside, the rest of the security program — access control, encryption in transit, application-level controls?
• What is the measured performance overhead of the trusted-execution approach on this specific workload, compared with the equivalent non-confidential deployment?
• Is attestation actually being verified by the relying party, or is "confidential computing" being used as an unverified marketing claim?
• Who is accountable for re-evaluating this control as TEE hardware and its known vulnerabilities evolve over time?

Research referenced

• Tramèr and Boneh (2018), Slalom: Fast, Verifiable and Private Execution of Neural Networks in Trusted Hardware ↗.