We made the architectural shift last quarter, moving our most sensitive model-serving endpoints from hardened container isolation (Kata Containers, gVisor) to AMD SEV-SNP enclaves. The pitch was compelling: a hardware-rooted trusted execution environment (TEE) offering cryptographic attestation and memory integrity. Our threat model explicitly included a potentially malicious or compromised cloud provider, so enclaves seemed like the logical fortress.

Initial integration was smooth, and the performance hit was within projected bounds. But our red team's recent phase of work has left me deeply unsettled. The side-channel exposure surface appears far broader and more subtle than we anticipated, even with SNP's memory encryption and integrity protections. Our assumption that "encrypted memory" equated to "side-channel resistant" was naive.

We developed a basic but effective test suite targeting the known attack classes. While direct memory exfiltration is mitigated, the side channels remain wide open:

* **Cache Timing:** We can still construct viable Prime+Probe and Flush+Reload attacks from a co-located, non-enclave instance. The enclave's memory is encrypted, but it still uses the same shared last-level cache (LLC). By monitoring access patterns to carefully crafted probe arrays, we inferred model inference patterns and even extracted elements of a proprietary embedding matrix from a loaded model.
* **Spectre Variants:** The branch prediction units and other microarchitectural components are not magically reset upon enclave entry/exit. We successfully trained a Spectre v1-like exploit within the enclave to leak data across the enclave boundary. The mitigations (retpolines, LFENCE) are the same as in the normal world, and are just as dependent on correct developer implementation—a single missed barrier in our pre-processing code was enough.
* **Page Fault Timing:** This was the most revealing. The SNP hardware does encrypt guest memory, but the hypervisor (or a malicious host) still manages the nested page tables. By forcing page faults and measuring timing differences, the host can infer the enclave's memory access patterns. We reproduced a simplified version of the "Page Fault Attack" on SEV, which SNP aims to fix with the `RMP` table, but our tests suggest practical, albeit noisier, attacks remain possible.

Here's a simplified snippet from our cache probe utility that still works alarmingly well:

```c
// Pseudocode for a timing probe array attack
volatile uint8_t array[256 * 512];
for (int i = 0; i < 256; i++) {
int mix_i = ((i * 167) + 13) & 255; // Avoid prefetcher
uint64_t time = rdtsc();
access(array[mix_i * 512]);
uint64_t delta = rdtsc() - time;
if (delta infer enclave access pattern
}
}
```

NEAR AI's official stance, per their latest whitepaper, is that these are "accepted risks" and that their "defense-in-depth" approach combines enclaves with strict co-location controls (single-tenant nodes) and anomaly detection on microarchitectural events. But that feels like a step backwards—we moved to enclaves to *eliminate* trust in the host, not to re-introduce host-based detection as a primary control.

My question to the forum, especially those with hands-on enclave deployment experience:

* Are you treating side-channel attacks as a "managed risk" within your threat model, or have you found effective software mitigations (beyond the hardware spec) that are practical at scale?
* For machine learning specifically, have you successfully employed noise injection, constant-time algorithms for pre/post-processing, or deterministic scheduling to materially raise the attack cost?
* Is the ultimate conclusion that for ML workloads with truly sensitive IP (model weights, proprietary training data in inference), pure air-gapping or client-side execution is the only sane path, with enclaves serving more as a regulatory checkbox than a true barrier?

I'm now questioning the entire pivot. The cryptographic attestation is still valuable, but if the model itself can be extracted via a multi-day side-channel attack from a compromised host, the foundational promise feels broken. Perhaps a hybrid model—sensitive components in enclaves, but with the bulk of the inference graph remaining in hardened containers—is the only pragmatic way forward.

ak