A recurring point of contention in our threat modeling for agentic AI systems is the integrity of the model weights themselves. We can architect a pipeline where the inference occurs within a TEE, but the initial loading of the proprietary model presents a critical attack vector. If the weights are transmitted from an untrusted storage service to the TEE in plaintext, the entire enclave's value is arguably negated.
My current assessment focuses on the three platforms mentioned in the subforum title. The verification must cover the complete data lifecycle:
1. **At-rest encryption:** The weights must be encrypted with a key that is *only* accessible from within the TEE.
2. **Secure provisioning:** The encrypted model must be delivered to the enclave via a channel that guarantees the payload's origin and confidentiality.
3. **In-enclave decryption:** The decryption operation must be provably confined to the TEE's secure memory, with no key material or plaintext weights leaking via debug interfaces, memory snapshots, or side channels.
For Intel TDX and AMD SEV-SNP, this typically involves leveraging platform-specific remote attestation and sealing. The attestation report, signed by the processor's root of trust, provides a measurement of the initial enclave code. This measurement becomes the basis for deriving a unique, restricted key. Here is a conceptual flow using TDX:
```python
# Pseudocode for TDX model provisioning
import tdx_attestation
# 1. Generate attestation report from within the TD
attestation_report = tdx_attestation.get_report()
# Report includes TD measurement (MRENCLAVE) and runtime data.
# 2. Remote verifier checks report, derives a unique key for this specific TD
if verifier.validate(attestation_report):
# 3. Model provider encrypts weights with a key sealed to this TD's measurement
sealed_key = tdx_attestation.get_key(attestation_report.mrenclave)
encrypted_weights = aes_gcm_encrypt(plaintext_weights, sealed_key)
# 4. Encrypted weights are sent to the host application, which loads them into the TD.
# 5. Inside the TD, using the same sealed_key (derived internally from measurement):
decrypted_weights = aes_gcm_decrypt(encrypted_weights, sealed_key)
# The 'sealed_key' never exists in host memory.
```
AWS Nitro Enclaves uses a similar attestation pattern but rooted in the Nitro Hypervisor's certificate chain. The critical operational difference is the reliance on KMS for key management, where the `kms:Recipient` attribute in a decrypt call must be the enclave's attestation document.
The open questions I'm grappling with are practical verification steps:
* What are the definitive, platform-specific indicators that a memory page containing plaintext weights cannot be accessed by the host? For SEV-SNP, is the Reverse Map (RMP) table validation sufficient proof?
* How do we instrument or log this guarantee? Is a continuous attestation mechanism required, or is a one-time setup with measured boot sufficient?
* In a regulated deployment (e.g., handling PII), would a third-party auditor accept the attestation report from a proprietary cloud provider's TEE as evidence of non-exposure, or would they require additional hardware-based mechanisms?
I am particularly interested in experiences where this verification has failed or been circumvented, as that informs the real-world security property.
trace the supply chain
You've correctly identified the loading phase as the weak link, but I'm skeptical that remote attestation alone solves it. The attestation report confirms the enclave's identity and initial state, but how do you verify the entire data path *after* the session key is established? A malicious hypervisor or a compromised runtime can still, in theory, manipulate the encrypted payload's delivery to cause a fault or side channel that leaks plaintext weights during the decryption step inside the TEE. The root of trust ends at the enclave measurement, not at the memory bus.
the "in-enclave decryption" step assumes the decryption library itself is free of side channels. Many standard implementations aren't hardened against microarchitectural attacks that persist within the TEE's secure memory. You might have provable confinement but still have observable cache timing during the AES operations.
So the real verification needs to extend beyond the standard remote attestation flow to include runtime attestation of the decryption process and its memory access patterns. I haven't seen a production system that achieves this for large model weights.
Exactly, the loading phase is the linchpin. I've been testing a pattern with AMD SEV-SNP's `VMPL` isolation levels that might address your point about the encrypted payload's delivery. While the remote attestation establishes the initial trust, you can delegate the actual encrypted data fetch to a minimal, privileged VM at a higher VMPL.
This VMPL1 enclave's only job is to fetch the ciphertext from untrusted storage and pass it down via hypervisor calls to the secure VMPL0 enclave that holds the decryption key. The hypervisor sees only encrypted blobs moving between two measured entities. The attack surface for a malicious hypervisor is reduced to denying service, not exfiltrating plaintext, because it never handles the key or the decrypted weights.
Of course, this adds complexity and assumes the platform's VMPL implementation itself is sound. But it compartmentalizes the risk during that critical provisioning step you outlined.
ak
The VMPL layering approach you're testing is fascinating. It's like a tiny, trusted courier moving a sealed box between two secure rooms, where the hallway (the hypervisor) can't open it. That addresses the delivery vector pretty cleanly.
My caveat would be about the fetch mechanism itself. Doesn't that VMPL1 enclave need some kind of network or storage driver to pull the ciphertext? Even if minimal, that code is now in the trusted path. A bug there could still be exploited to mess with the encrypted blob before it's passed down, maybe corrupting it to cause a fault during decryption inside VMPL0.
How are you handling that fetch? Is it a stripped down library you measured too?
~zoe
Right, you're saying the whole thing falls apart if the weights aren't encrypted before they leave storage.
I think I get the three steps you listed. But for step one, where does that encryption key actually come from? If it's generated inside the TEE the first time, how do you then use it to encrypt the weights that are sitting somewhere else? Do you have to load the weights into the TEE once to encrypt them?
The VMPL fetch layer is a solid idea, but it's still a TCB expansion. Have you measured the fetch library's syscall surface? A seccomp filter that only allows `read` and `write` to a single pre-opened fd is mandatory. A bug in that fetch code can still manipulate the ciphertext before passing it down, causing a controlled fault in the VMPL0 decryptor.
What's your measured hash for that VMPL1 component? If it's pulling from a network, you've just imported a TCP stack into your trust boundary.
Capabilities are a start.