Confidential Computing／TEE × AI

Confidential Computing／TEEは、定義したthreat modelの範囲でAI workloadのdata-in-useと実行環境をhost/operatorから隔離し、remote attestationをsecret/key releaseの条件にできます。 ただし、TEEやattestation PASSだけでapplication code、GPU、side channel、availability、prompt/output/log、tool actionまで自動的に安全になるとは扱いません。

導入時にCPU/TEE technologyとgeneration、firmware/microcode/BIOS/TCB、VM/base image、workload image、runtime policy、GPU/accelerator、attestation verifier、key-release service、IAM/KMS、storage/network pathを固定します。「confidential VM」というproduct labelだけで全componentが同じ保護境界に含まれるとは推定しません。

remote attestationは、evidence生成→verifierによる署名/measurement/TCB検証→nonce/freshness/token expiry確認→reference value/policy照合→attested workload identity確定→policy PASS後のsecret/model key/resource access、というchainで扱います。token取得だけをauthorization成功としません。

image digest、boot/firmware/TCB、runtime policy等、resource release判断に必要なcomponentを明示的に測定・pinします。測定対象外componentを暗黙にtrustedとしません。TCB/image更新はreference value更新をchange controlとして扱い、古い脆弱TCBへのrollbackも確認します。

attestation evidenceにはnonce等のfreshness mechanismを要求し、stale/replayed evidenceをsecret releaseへ使用しません。verifier identity、token TTL、clock/expiry handlingも確認します。

secret/model keyはattestation policyが要求measurementとfreshnessを満たした後にreleaseします。release先public key/session identityをattested workloadへbindします。TEEの存在だけをkey release条件にしません。

AI accelerator利用時はCPU confidential VMとGPU confidential computing/attestationを別gateとして確認します。CPU VMがattestedでもGPU、driver、firmware、PCIe/device pathまで自動的にprotectedとは扱いません。GPU CC mode、GPU attestation evidence、driver/firmware compatibilityを確認します。

TEE内でもapplication vulnerability、prompt injection、malicious/excessive tool call、overbroad IAM、plaintext logs/traces、model output disclosure、secret persistence、business-action authorizationは別controlです。attestation PASSをapplication correctnessやtool-action permissionとして扱いません。

TEEをside-channel-freeまたはDoS-resistantと表現しません。platform threat model/current security bulletinを確認し、必要に応じconstant-time implementation、secret-independent access、resource isolation等を別control化します。availability/capacity/attestation outage/hardware shortageは別SLOです。

AWS Nitro Enclavesのdebug modeのようにdeployment modeでattestation suitabilityが変わるため、debug/dev imageとproduction attestation-capable imageを分離します。

TEE security claimはhardware generation名だけで固定せず、firmware/microcode/BIOS/TCB/security bulletin mitigation stateを確認します。attestation SDK/clientのdeprecation/compatibilityも追跡します。

stale/replayed attestation、missing nonce、verifier misconfiguration、wrong reference digest、unsigned/unpinned image、debug image、unpatched TCB、incomplete measurement、unmeasured runtime、CPU-only attestation、GPU CC disabled、device path outside boundary、premature/unbound key release、overbroad IAM/KMS、token expiry、TCB rollback、side-channel leakage、application bug、prompt/output/log exfiltration、tool authorization failure、secret persistence、DoS、capacity shortage、attestation outage、SDK incompatibilityを想定します。

本項は2026-10-06時点のAWS Nitro Enclaves/KMS、Google Confidential Space、Azure confidential VM、AMD SEV-SNP security bulletins、NVIDIA attestation/confidential-computing documentation、Confidential Computing Consortium threat-model materialに基づきます。live resource mutation、token cryptographic verification、side-channel test、performance benchmarkは未実施です。

Confidential Computing／TEEは、定義したthreat modelの範囲でAI workloadのdata-in-useと実行環境をhost/operatorから隔離し、remote attestationをsecret/key releaseの条件にできます。ただし、TEEやattestation PASSだけでapplication code、GPU、side channel、availability、prompt/output/log、tool actionまで自動的に安全になるわけではありません。measurement、nonce/freshness、verifier、TCB/firmware、workload identity、CPU/GPU境界、key-release policyを固定し、測定対象外とOPEN_UNKNOWNを明示します。

organization TEE architecture、cloud/region、CPU/TEE generation、firmware/microcode/BIOS/TCB、reference authority、verifier、nonce/token、key release、GPU/driver/firmware/CC、image signing/SBOM、runtime policy、IAM/WIP/KMS、storage/network、side-channel requirements、performance/cost、capacity/SLA、logging/residency、Agent tool auth、incident response、rollback/reference updateは未確認です。