0. 核心观点
机密 AI 推理不是“把模型放进 TEE 就安全”。企业真正要保护的是推理过程中的提示词、检索上下文、用户数据、模型权重和输出结果；这些数据会穿过网关、调度器、CPU、GPU、内存、日志和监控系统。TEE 与 GPU 机密计算只能覆盖其中一段执行边界，不能自动解决密钥管理、远程证明、日志脱敏和供应链可信问题。
本文的判断是：机密 AI 推理应被设计为一条可证明的信任链，而不是一个孤立的安全特性。
1. 背景与问题定义
LLM 推理服务的敏感性来自两个方向：输入可能包含企业私有数据，模型本身也可能是商业资产。传统云部署主要依赖传输加密、磁盘加密和 IAM，但在运行时，数据仍会进入主机内存、设备内存和服务日志。机密计算试图缩小云平台、宿主机管理员或同租户攻击面在运行时看到明文的机会。
2. 信任链设计
| 环节 | 需要证明什么 | 常见失败模式 |
|---|---|---|
| 镜像与启动 | 运行的是被批准的镜像和启动参数 | 镜像漂移、调试端口残留 |
| 远程证明 | 当前实例处于可信硬件与可信配置 | attestation 未校验或校验结果不绑定会话 |
| 密钥释放 | 只有证明通过后才能解密模型或数据 | 密钥提前下发、长期驻留 |
| 推理执行 | 明文尽量限制在可信边界内 | CPU-GPU 传输路径暴露、日志泄露 |
| 观测审计 | 记录足够证据但不记录敏感明文 | trace 过度采样、错误日志带 prompt |
机密计算的工程重点是“绑定”：证明结果要绑定到工作负载身份、镜像摘要、策略版本和会话密钥。否则 attestation 只是一次启动时截图，不能支撑持续信任。
3. 工程化设计
推理网关应成为可信边界的编排点。它不只负责路由模型，还负责校验证明、选择执行池、控制密钥释放、标记敏感请求、限制日志字段。对于不同数据等级，可以选择不同路径：普通请求走标准 GPU 池；敏感请求走机密执行池；极高敏感请求走本地或专有环境。
inference_routes:
- match:
data_class: public
target_pool: standard-gpu
logging: sampled_metadata
- match:
data_class: confidential
target_pool: confidential-gpu
require_attestation: true
release_key_after_attestation: true
logging: metadata_only
- match:
data_class: restricted
target_pool: dedicated-tenant
require_human_approval: true| 控制点 | 要绑定的对象 | 失败模式 | 验证办法 |
|---|---|---|---|
| 远程证明 | 硬件状态、镜像摘要、启动参数、策略版本 | 只校验证明但不绑定会话 | 网关日志记录 quote hash + session id |
| 密钥释放 | attestation 结果、工作负载身份、时间窗口 | 密钥提前下发或长期驻留 | KMS release log 与 workload identity 对账 |
| GPU 执行 | 机密 GPU 能力、驱动/固件版本 | CPU 安全但 GPU 明文路径暴露 | 节点标签与 attestation policy 联动 |
| 日志观测 | trace_id、模型版本、错误码 | prompt/检索片段进入日志 | 敏感字段采样审计 |
4. Windows 能做的验证：证明本机不是机密推理环境
没有机密 GPU 或云厂商 attestation 服务时，不应该伪造“已验证机密推理”。可以做的是把本机能力边界写清楚，避免把普通 Windows 主机误当作可信执行环境。DESKTOP-HT6EO5E 的一次只读实测结果如下：
OS: Microsoft Windows 10 Pro for Workstations 10.0.19045 / build 19045
PowerShell: 5.1.19041.6456
DeviceGuard.SecurityServicesConfigured: [0]
DeviceGuard.SecurityServicesRunning: [0]
DeviceGuard.VirtualizationBasedSecurityStatus: 2
TPM query: fields returned null in this node context这组输出只能支持一个克制结论：这台机器可以用于说明“普通主机基线与机密推理要求之间的差距”，不能用于宣称 GPU attestation、TEE 密钥释放或机密执行已经成立。真正的机密推理 PoC 至少要补齐三类证据：attestation quote、策略校验日志、KMS 按证明结果释放短期密钥的记录。
5. 性能与成本取舍
公开研究与厂商实践都显示，机密执行会引入性能、调度和可运维性成本。是否值得采用，不应由“是否更安全”这个抽象问题决定，而应由数据等级、威胁模型、合规要求和延迟预算共同决定。
6. 风险与安全边界
TEE 不能防止模型输出敏感信息，也不能修复业务层越权检索。GPU 机密计算不能替代 API 鉴权、DLP 和审计。远程证明也不能保证应用逻辑没有漏洞。机密 AI 推理的边界主要防运行时基础设施观察者，而不是防所有应用层风险。
因此，机密推理应与 RAG 权限控制、模型输出审查、日志治理和供应链签名一起部署。只要检索系统把不该看的文档交给模型，TEE 会忠实保护这次错误推理的明文，却不会阻止越权结果返回给用户。
结论
机密 AI 推理的可信边界建立在远程证明、密钥生命周期和最小日志策略之上。远程证明保证运行环境符合预期，密钥管理保证数据只在证明通过后解密，最小日志策略保证即使系统被攻破，攻击者也无法从日志中反推敏感内容。这三者共同构成了机密计算场景下的工程信任根。