Kan TEE'er sikre LLM-inferens i multicloud-miljøer?

Store sprogmodeller (LLM’er) kan hurtigt blive det centrale konkurrencemiddel - både som proprietær model, som fin-tuned udgave af en åben model eller som prompt-drevet “agent”. Hvis kode, vægte eller kundedata kompromitteres, risikerer virksomheden:

• Tab af intellektuel ejendomsret: Modelarkitektur, træningsdata og fin-tuning repræsenterer år af FoU-investeringer.
• GDPR-bøder og omdømmeskade: Personhenførbare oplysninger (PII) kan “siv­e” fra prompts, outputs eller cache. Artikel 32 kræver passende tekniske foranstaltninger.
• Sektorregulering: Finans (EBA, DORA), sundhed (NIS2, ISO 27799) eller offentlig sektor har skærpede krav til datalagring og behandlingssted.
• Supply-chain angreb: En kompromitteret runtime eller container kan manipulere inferensen eller plante bagdøre.

Trusselsbillede i skyen

Hvad gør multicloud anderledes?

1. Forskellige tillidsrods
   Azure bruger Intel SGX/TDX og AMD SEV-SNP; AWS baserer sig på Nitro Hypervisor + Nitro Enclaves; Google tilbyder AMD SEV og snart TPU-baserede TEE’er. Hver leverandør udsteder egne attestation-certifikater, hvilket komplicerer “chain of trust”.
2. Geografiske variationer
   Dataresidenskrav kan betyde, at franske HR-data kører i Frankrig (GCP Paris), mens japanske kundedata ligger i Osaka (AWS). Ensartet politik-håndhævelse kræver krypterede images og policy-motorer, der forstår lokal lovgivning.
3. Fragmenterede compliance-kontroller
   Hver cloud har egne metrikker (Azure Policy, AWS Config, Google Assured Workloads). Cross-cloud regelefterlevelse bliver en disciplin i sig selv.
4. Øget angrebsflade
   Flere konsoller, flere IAM-systemer og flere netværksbaner = flere muligheder for fejlkonfiguration og phishing.
5. Lock-in kontra portabilitet
   Virksomheder ønsker at kunne flytte en fortrolig inferens-pipeline mellem clouds - men forskellige TEE-API’er, GPU-drivere og key-management-systemer er sjældent kompatible out-of-the-box.

Opsummeret kræver fortrolig LLM-inferens end-to-end isolation - fra prompt til tensor og tilbage - og en konvergeret sikkerhedsmodel, der kan fungere på tværs af flere skyer uden at tabe fart eller fleksibilitet.

Trusted Execution Environments (TEE’er) er hardware-understøttede, isolationszoner i CPU, GPU eller hypervisor, hvor kode kan afvikles med følgende egenskaber:

1. Isolering - data og registrer-tilstand er afskåret fra resten af maskinen, selv for root‐brugere og cloud-administratorer.
2. Memory-kryptering - alt der forlader chippen (RAM, interconnect) krypteres med nøglemateriale, som kun eksisterer i silicium.
3. Remote attestation - kryptografisk bevis på, at den korrekte software kører i et ægte TEE, før nøgler eller modeller frigives.

Markedsoversigt over tee-teknologier i de store skyer

Container- og framework-kompatibilitet

• Confidential Containers (CNCF) gør det muligt at køre OCI-images uændret i SEV-SNP, TDX og fremtidigt CCA. Kubernetes-integrationen leveres via CRI-plugin + pod-annotations.
• Gramine, Occlum, Graphene og andre “library OS”-projekter oversætter POSIX-kald til SGX, så Python/Go/Node-apps kan køre i enclaves uden store code-refactors.
• Frameworks som PyTorch, TensorFlow, ONNX Runtime har konfidentielle builds, der bruger Intel SGX orv Gramine, samt SEV-SNP med kørsel i fortrolige VM’er.
• Triton Inference Server implementerer nu eksperimentel support til Nitro Enclaves og SEV-SNP gennem vsock-transport.

Multicloud-portabilitet

Selvom alle leverandører lover “confidential compute”, er root-of-trust, attestation-formater og nøgle-API’er forskellige:

• Intel baserer sig på EPID/ECDSA; AMD bruger ARK/ASK/VMPL; AWS Nitro har egen PCR-model; ARM CCA definerer Realm Attestation Token.
• IETF RATS og OASIS CCA-X.509 profiler er på vej til at standardisere attestations-tokens, så et Key Broker Service kan validere på tværs af clouds.
• Projekter som Enarx, ParagonIE Biscuit og SPIFFE/SPIRE tilbyder abstraheret identitet, så samme image kan køre i SGX lokalt og SEV-SNP i skyen.

For LLM-inferens betyder det, at modelvægte, tokenizer og KV-cache kan holdes fortrolige - men DevOps-holdet skal vælge den laveste fællesnævner på tværs af clouds eller indbygge adaptere for attestationsformat. De fleste organisationer starter derfor med én primær cloud-TEE og bygger et key brokering-lag, der senere kan udvides til flere leverandører.

Den mest robuste måde at indkapsle en LLM-pipeline i et multicloud-miljø er at kombinere en fortrolig container i et CPU-baseret TEE (fx Intel TDX eller AMD SEV-SNP) med en dedikeret GPU-TEE (AWS Nitro TPU, NVIDIA H100 Confidential Computing, m.fl.).

1. Indgående kald landet i en API-gateway, som terminerer mTLS og videresender krypterede protobuf-payloads.
2. Tokenizer-/controller-containeren kører som en Confidential Pod i Kubernetes. Den:
   • verificerer brugertokens (OIDC/JWT)
   • udfører prompt-sanitering & tokenizer-step
   • styrer batch-/kvantiseringsparametre pr. session
3. Modelvægt-dechifrering foregår kun efter vellykket remote attestation. Vægtene ligger krypteret i et virksomheds-KMS og hentes ved behov via Key Broker Service (KBS).
4. Tensorberegningerne køres inde i GPU-TEE’en, som eksponerer et “fortroligt MIG-slot” til hver pod. Memory-kryptering sikrer både vægte og KV-cache, mens DMA-blokkering stanser værts-inspektion.
5. Streamet inferens leverer tokens løbende via gRPC-streaming med end-to-end-krypteret datapipeline, så ingen plaintext forlader enclaven - heller ikke midlertidige logits.

Fortrolig rag-pipeline

Retrieval-Augmented Generation (RAG) stiller yderligere krav:

• Embeddings genereres i CPU-TEE’en og sendes krypteret til en fortrolig vektordatabank (Milvus + SGX, Pinecone Confidential, el.lign.).
• Selve søgeforespørgslen sker in-enclave, så udtrukne kontekster aldrig persisteres åbent.
• Top-k-resultaterne svejses sammen med brugerprompten og sendes videre til GPU-TEE-inferens uden at bryde fortroligheden.

Data- og nøglestrømme

Stateless vs. Stateful beskyttelse

En vigtig designbeslutning er, om KV-cache og session-state skal

• holde sig fuldt in-memory i GPU-TEE’en (lav latenstid, høj pris)
• eller spille ud til et krypteret, transient NVMe-drev (billigere, men side-channel-risiko).

Flere teams vælger en hybrid, hvor de første N tokens forbliver in-enclave, mens resterende cache krypteres med nøgle rullet pr. request.

Multicloud-policy for dataresidens og modelversionering

Forskellige clouds har ofte separate root-of-trust-kæder. En praktisk governance-model kan skitseres sådan:

1. Cross-cloud SPIFFE identiteter binder pod-attestationer til organisationens PKI.
2. OPA/Gatekeeper injicerer policies ved deploy-tid:
   • residens: vægte med “EU-ONLY” tag må kun dekrypteres på clusters label’et region=eu
   • versionering: produktion må kun køre signed images med semver.patch % 2 == 0
3. SBOM-koppling sikrer, at model-artefakter i hver cloud matcher en centralt publiceret checksum.

Streaming uden læk

Selv om tokens afleveres fortløbende, skal man gardere sig mod timing-/traffic-analyse. Populære teknikker:

• padding af gRPC-frames til fast størrelse
• randomiseret inter-token delay (under 5 ms jitter) for høj-sikkerheds workloads
• kombineret rate-limiter & detokenizer på klient-siden for at hindre model-replay.

Opsummering

Ved at koble CPU- og GPU-baserede TEE-teknologier, orkestrere dem med fortrolige containere og disciplinere data-/nøglestrømme med attestation og policy, kan organisationer opnå ende-til-ende fortrolighed for LLM-inferens på tværs af mange skyudbydere. Løsningen er ikke gratis - hver ekstra isolationslag koster latency, RAM og GPU-kvoter - men giver en realistisk vej til at møde både IP-beskyttelse, sektorregulering og kommende EU-AI-lovgivning uden at ofre multicloud-fleksibilitet.

Når en LLM-workload skal køre fortroligt på tværs af flere skyer, bliver attestation-workflowet selve navlestrengen mellem en beskyttet runtime og de hemmeligheder, den har brug for. Nedenfor gennemgår vi de vigtigste byggeklodser - fra måling af kode til udstedelse af nøgler, orkestrering, audit og politik.

1. Remote attestation som adgangsbillet
   • Hver TEE - hvad enten det er en AMD SEV-SNP-VM, en Nitro Enclave eller en Intel TDX-guest - udstiller en målbar firmware-rapport (PCR-hashes, chip-certifikater m.m.).
   • Rapporten sendes til en attestation-service (Azure Attestation, AWS Nitro Attestation, veraison on-prem) som validerer signaturen op mod producentens CA.
   • Når målingen matcher en godkendt policy hash, udstedes et signed Evidence Consumption Token (EAT JWT eller COSE-signeret) som bevis for at koden kører i en godkendt TEE.
2. Nøgleudlevering via KMS/Key Broker

   Komponent	Rolle
   KMS (AWS KMS, Azure Key Vault, GCP KMS)	Opbevarer krypterede model- og API-nøgler
   Key Broker Service (KBS)	Verificerer EAT, udpakker policy claims og udleverer dekrypteringsnøgler til korrekt TEE-instans
   Tenant Policy	Definerer *hvilke* TEEs (målinger, region, cloud) der må få adgang til *hvilke* nøgler

   Først når attestation er godkendt, får Pod’en en short-lived data-key, der dekrypterer modelvægte, RAG-vektorer eller prompt-cache.

3. Supply-chain-sikring før første byte
   • Signerede images: Cosign/Notary v2 signaturer kontrolleres af admissions-kontrol, før Pod’en schedule’s.
   • SBOM: CycloneDX- eller SPDX-manifest følger containeren og matches op mod CVE-feeds.
   • SLSA Level 2-4: GitHub Actions, Tekton Pipelines eller GitLab CI udsteder provenance-attester (in-toto) som del af build’en.
4. Kubernetes-orkestrering med Confidential Containers
   • Kata Containers eller CC Runtime kører hver Pod i sin egen SNP-/TDX-VM.
   • En RuntimeClass (fx confidential-guest) styrer schedulering på noder med TEE-støtte.
   • initContainers henter model-artefakter via KBS, hvorefter main container starter inferens-serveren (vLLM, TensorRT-LLM m.fl.).
5. Identitetslag med SPIFFE/SPIRE
   • Pod’en præsenterer sin TEE-attestation til SPIRE Server.
   • Serveren udsteder en X.509- eller JWT-SVID (spiffe://org/llm-service/pod-123), der bruges til mTLS mellem microservices - også på tværs af clouds.
6. IETF RATS/EAT end-to-end flow
   1. Evidence (TEE-rapport) → Verifier (cloud attestation-service)
   2. Verifier sender et Attestation Result (EAT) til Relying Party (KBS/KMS).
   3. Relying Party udleverer nøgler & politikker baseret på claims (hash, region, tenant-id).

   Dermed taler CPU- og GPU-TEE’er samme sprog - uanset om de kører i AWS eller GCP.

7. Audit-logning & politikhåndhævelse
   • OPA Gatekeeper validerer, at Pods kun kører i godkendte regioner og med signeret kode.
   • Attestation-resultater sendes til SIEM (Elastic, Splunk, Azure Sentinel) samt immutabel log (Sigstore Rekor, AWS Audit Manager).
8. Mønstre for cross-cloud trust
   • Federeret nøgle-broker: Central KBS udsteder nøgler til edge-KBS’er i hver cloud - least privilege via tenant-scopes.
   • Policy as Code: Samme Rego-politikker versioneres i Git og pushes til Gatekeeper-instanser i alle skyer.
   • Mesh-gateway: Istio + SPIFFE forbinder TEE-workloads over private links med automatisk cert-rotation.

Med dette setup opnås en kæde af tillid fra firmware til applikation, hvor hver komponent kan bevises og revokeres individuelt - en forudsætning for at drifte fortrolig LLM-inferens i et ægte multicloud-landskab.

Fortrolig inferens er dyrere end almindelig cloud-drift - både i kroner, watt og ventetid.

1. GPU-tilgængelighed: Konfidentielle GPU-instanser (fx NVIDIA H100 CC eller AMD-kort med SEV-SNP) er endnu kun forhånds­tilgængelige i få regioner. Multicloud-strategien må derfor tage højde for capacity busting og køsystemer. Mange teams kombinerer CPU-TEE’er til tokenizer/kv-cache og lejer ufortrolige GPU’er til “kolde” batch-jobs - en afvejning af fortrolighed vs. throughput.
2. Overhead: Kryptering af hukommelse og kontekstskift mellem TEE-world og normal-world koster typisk 2-8 % CPU og 5-15 % GPU-ydelse. Ved streamet generering kan latens stige yderligere pga. krypteret I/O.
3. Hukommelsesgrænser: Enclaves har ofte <1 TB fysisk adresse­rum og kan være begrænset til 64-256 GB on-package krypteret RAM. Store sprogmodeller (70B+) kræver derfor tensor-parallel eller offload til delt, men krypteret, VRAM - et område hvor GPU-TEE-teknologien stadig modnes.

Sidekanaler og prompt-baseret datalæk

Selv om hukommelsen er krypteret, kan angribere aflure data via tidsmålinger, energiforbrug og model-output:

• Microarchitectural leaks: Cache-evictions, branch predictor eller DMP. Løsninger: frekvenspinning, page-lock randomisering og dataparallel “noisy” padding.
• Co-tenant sidekanaler: Isolér GPU’er pr. tenant og brug IOMMU + DMA-beskyttelse. In-flight re-encryption mellem CPU- og GPU-TEE begrænser DMA-høsting.
• Prompt injection & training data leaks: Kombinér policy-styret input-output filter (Rego/OPA) med RAG-tjek (red teaming) og watermarking af output.

Driftsmæssig kompleksitet

Attestationstrin, nøglehåndtering og specialiseret hardware skaber nye “run books”:

Standarder og økosystem

Der er lys for enden af siloen:

• Confidential Computing Consortium (CCC) driver reference­implementeringer af cc-runtime, Key Broker Service og det nye Enarx-projekt.
• OCCP søger at normalisere attestation-tokens over Intel TDX, AMD SEV-SNP og ARM CCA.
• Cloud-udbydere publicerer attestation evidence format converters, så en Azure TEE kan attesteres fra en AWS KMS og omvendt.

Fremtidige spor

1. ZK-beviser & zkML: Giver kryptografisk garanti for korrekt inferens uden læk af vægte. Egnet til mindre modeller pga. tunge provers (O(n log n)).
2. Fuld homomorf kryptering (FHE): Intet leaker, men million-gange langsommere på GPT-skala. Tidlig anvendelse: privat sentiment-analyse eller embedding-beregninger.
3. Hybrid-tiltag: TEE til stateful kontekst + FHE til små, følsomme felter; ZK-beviser til audit af outputintegritet.

Praktisk roadmap til gradvis multicloud-adoption

• Step 1: Pilotér CPU-baseret TEE for tokenizer og KV-cache i én cloud. Mål latens og nøgleflow.
• Step 2: Introducér bring-your-own-GPU med delt nøglebroker. Evaluér om model­split (encoder i CPU, decoder i GPU) er nok til at opfylde regulatoriske krav.
• Step 3: Standardisér build-pipeline med SBOM + SLSA level 3-4, og håndhæv RATS-baseret policy i OPA/Gatekeeper.
• Step 4: Udrul cross-cloud DR med identiske container-images, replikér KMS-nøgler via HSM-backed escrow.
• Step 5: Eksperimentér med zkML/FHE på afgrænsede, højsikre workloads - fx finansiel risikomodellering - og brug erfaringerne til at justere cost-/risk-balancen.

Med andre ord: Start småt, mål alt, og lad formålet - ikke hardware-hypen - styre hvor, hvornår og hvor dybt fortrolig computing integreres i multicloud-strategien.