Everyone's hyper-focused on cache timing and Spectre variants in our enclave deployments. I get it—they're real, they're sexy to talk about, and NEAR AI's mitigations are a solid baseline. But we're missing the forest for a single, well-studied tree.

The actual attack surface introduced by deploying and operating enclaves is far messier and more immediately exploitable than a theoretical, high-skill side-channel. We're bolting a complex, opaque technology onto our existing CI/CD and orchestration layers. Each of those integration points is a potential gap.

Consider the pipeline to get code into an enclave:
- The build process that must produce an attested artifact.
- The orchestration layer (K8s, Nomad) needing special permissions and custom CRDs.
- The secrets injection mechanism (bypassing Vault's standard sidecar model?).
- The attestation service itself, now a critical new component.

A single misconfiguration in any of these steps can bypass the enclave's protections entirely. I've seen more "secure" deployments compromised by a overly permissive service account on the attestation verifier pod than by any cache attack.

```yaml
# Example: a "simplified" enclave-enabled deployment spec I've seen in the wild.
# The vulnerability isn't in the enclave, it's right here.
apiVersion: v1
kind: ServiceAccount
metadata:
name: enclave-attestation-verifier
automountServiceAccountToken: true
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: enclave-verifier-binding
subjects:
- kind: ServiceAccount
name: enclave-attestation-verifier
namespace: production
roleRef:
kind: ClusterRole
name: cluster-admin # Why? Because it was "easier".
apiGroup: rbac.authorization.k8s.io
```

The side-channel risks are contained, in theory, to the enclave boundary. The operational risks? They're system-wide. A flawed attestation flow means you're confidently running untrusted code. A secret leaked during provisioning is just as gone.

We need to shift the conversation. Before we deep-dive on mitigating branch predictor attacks, we should be able to answer:
1. Is our attestation service as hardened as our vault cluster?
2. Do our deployment logs prove the entire chain from commit to attested enclave?
3. Are the host OS and orchestrator for the enclave nodes at the same standard as the rest of our control plane?

Otherwise, we're building a vault inside a house with no doors, but leaving all the windows open.