机密计算从CPU扩展到GPU与智能体：企业部署AI如何评估可信执行边界？

企业把大模型接入内部知识库、业务系统和自动化工具后，保护对象已经不只是“上传的数据”。用户输入、检索结果、模型权重、推理中间态、长期记忆、服务凭证以及智能体执行动作，都可能进入同一条处理链路。机密计算的价值，正在从保护 CPU 内存中的数据，扩展到 GPU 计算、容器运行时和智能体权限控制。对于技术负责人和采购者而言，关键问题不是“是否采用机密计算”，而是要确认：可信执行边界究竟覆盖了哪些组件，哪些数据在什么时刻仍可能暴露，以及部署复杂度是否与业务风险相匹配。

机密计算首先改变的是信任模型

传统加密主要保护静态数据和传输中的数据。数据进入推理服务后，仍需要在内存、处理器寄存器、运行时上下文或加速器显存中以可计算形式存在。机密计算通过硬件支持的可信执行环境（Trusted Execution Environment，TEE），对计算中的数据提供隔离和保护，目标是降低云平台、宿主机管理员、同一基础设施上的其他租户或被攻陷的系统组件读取明文的可能性。

这并不意味着所有数据自动获得保护。一个更准确的判断方式是把系统拆成四类资产：

• 数据资产：用户对话、企业文档、数据库记录、检索结果和工具返回值。
• 模型资产：模型权重、微调参数、提示模板、系统指令和推理策略。
• 运行时资产：KV Cache、内存中的中间结果、智能体记忆、任务状态和日志。
• 控制资产：解密密钥、API Token、OAuth 凭证、工具权限和远程证明策略。

只有当这些资产都处在可验证的保护路径中，企业才能说系统具有相对完整的机密计算能力。如果模型在 GPU 中受到保护，但密钥在普通主机内存中长期明文保存，或者智能体可以把敏感内容写入未受保护的日志，那么“GPU安全”并不能等同于端到端安全。

从 CPU TEE 到 GPU TEE：可信边界向计算链路延伸

CPU 机密计算解决了什么

CPU TEE通常以虚拟机或受保护的执行域为基础，对客户虚拟机内存进行硬件隔离和加密，并通过远程证明让外部验证者确认运行环境的身份、启动状态和关键软件测量值。

在企业AI场景中，CPU可信域可以保护：

• 推理服务进程及其配置；
• 用户请求和检索数据；
• 模型加载过程中的权重；
• 密钥代理与证明验证逻辑；
• 智能体的会话状态和工具调用编排。

CPU TEE的局限也很明确：当推理任务把数据或模型交给GPU时，CPU侧的保护不会自动覆盖GPU显存、GPU计算上下文以及CPU与GPU之间的数据传输。因此，CPU TEE只能说明主机侧获得了保护，不能单独证明整条AI推理链路都处于可信边界之内。

GPU TEE保护的是“使用中的加速计算”

GPU机密计算的核心变化，是将保护范围延伸到GPU侧的数据和执行过程。以公开的异构机密计算方案为例，CPU TEE与GPU机密计算能力组合后，可以同时关注：

1. 数据从CPU可信域传输到GPU的过程；
2. 模型权重和输入数据在GPU显存中的状态；
3. GPU执行期间的计算上下文；
4. 推理结果从GPU返回CPU后的继续保护；
5. CPU与GPU之间的证明、密钥释放和生命周期管理。

这对大模型推理尤其重要，因为模型权重和中间状态可能长时间驻留在加速器相关内存中。企业在评估方案时，应要求供应商明确回答以下问题：

• GPU是否支持硬件级的机密执行，而不是仅对主机侧磁盘或内存加密？
• GPU侧是否有独立的证明材料，还是只证明了CPU虚拟机？
• 模型密钥是否只有在CPU和GPU环境均通过验证后才释放？
• CPU到GPU、GPU到CPU的数据通道是否包含在保护范围内？
• 任务结束后，显存、缓存和临时文件如何清理？
• 驱动、固件、容器运行时和编排组件是否纳入测量与更新机制？

阿里云关于异构机密计算环境的公开文档将CPU TDX与GPU机密计算结合，并以验证GPU机密计算功能为例说明CPU与GPU共同构成保护链路。这个思路可以作为架构评估的参考，但不应直接推导出所有云平台或所有GPU型号都具有相同能力。参考：阿里云异构机密计算环境文档

多GPU部署不是简单复制一份可信环境

单卡推理关注的是一条CPU—GPU数据路径，多GPU部署则会增加新的信任和故障边界。模型可能被切分到多个GPU，输入和中间状态可能在卡间交换，调度器还需要处理节点、设备、网络和任务生命周期。

企业应把多GPU可信边界拆成四个层次进行审查。

设备身份与证明覆盖

每张GPU都可能具有独立的安全状态。系统需要明确：

• 是否逐卡验证GPU身份和安全状态；
• 多张GPU的证明结果是否绑定到同一个任务；
• 当某一张GPU重启、降级或被替换时，密钥是否会重新验证；
• 调度器是否可能把任务迁移到未通过证明的设备上。

如果系统只验证了宿主机或虚拟机，而没有验证实际参与计算的GPU，证明结论就不能覆盖完整的推理拓扑。

卡间通信与中间状态

分布式推理可能涉及张量并行、流水线并行或其他模型切分方式。无论采用哪种方式，采购者都不应只询问“模型是否在机密GPU上运行”，还应追问：

• 卡间通信是否经过受保护的通道；
• 跨设备传输的数据是否可能落入普通主机内存；
• 中间激活、缓存和临时张量是否会被调试接口或监控组件读取；
• 网络交换设备、通信库和驱动是否属于供应商承诺的保护范围。

这些问题往往决定了多GPU环境的实际边界。硬件支持本身并不能替代通信路径和软件栈的验证。

调度和故障恢复

机密计算会给弹性调度带来额外条件。任务迁移、GPU故障、节点扩缩容和滚动升级都可能改变执行环境。可行的设计通常需要在任务启动前重新完成环境验证，并由密钥服务根据新的证明结果决定是否允许恢复。

因此，企业应将以下情况纳入演练：

1. 单张GPU异常退出；
2. 节点被重新调度；
3. 驱动或固件升级；
4. 模型服务滚动发布；
5. 证明服务或密钥服务暂时不可用；
6. 推理任务中断后的状态恢复。

这里的目标不是保证系统永不失败，而是确保失败时不会通过“降级到普通环境”来换取可用性。

容器安全决定机密能力能否进入生产

裸机或虚拟机中的TEE只是基础设施能力。企业真正部署AI服务时，通常还会使用容器、Kubernetes、服务网格、模型仓库和可观测性组件。若容器编排层没有纳入可信边界，TEE的安全收益可能在运维环节被削弱。

机密容器的基本思路，是把容器工作负载放入具有硬件隔离能力的轻量虚拟机中，使应用可以在较少修改的情况下获得更强的运行时隔离。NVIDIA公开的机密AI架构资料将CPU TEE、机密GPU、硬化的微型客户机、Kubernetes集成、远程证明和密钥代理组合在一起，并明确提示机密容器主要解决数据机密性和执行完整性，并不自动覆盖应用漏洞、可用性攻击和网络安全问题。参考：NVIDIA机密AI零信任架构

容器部署至少要验证五个环节

容器安全还需要处理“观测与保护”的矛盾。普通监控往往希望读取请求、响应、资源和进程状态，但机密AI服务又不应把完整提示词、模型中间态或工具凭证暴露给监控系统。更稳妥的做法是进行数据分级，只输出必要的指标和经过脱敏的事件，并将调试权限设计为短时、审批和可审计的操作。

智能体让可信边界从“数据”扩展到“行为”

与单次模型推理相比，智能体会持续处理对话、长期记忆、外部工具、服务凭证和多步任务状态。公开的智能体机密部署资料也将用户对话、智能体记忆与状态、服务凭证列为需要保护的核心资产，并强调运行时策略沙箱对高风险命令和敏感路径访问的作用。参考：阿里云机密AI Agent部署资料

因此，TEE不能替代智能体的权限设计。它可以减少宿主机或基础设施读取运行中数据的机会，却不能阻止一个拥有过大权限的智能体主动调用工具，也不能自动识别恶意提示词、错误规划或不安全的业务操作。

企业应将智能体权限拆成三层：

模型层权限

模型可以读取哪些上下文、记忆和检索结果？哪些内容需要脱敏？模型是否能够看到完整的系统提示词、密钥标识或内部网络拓扑？

工具层权限

智能体可以调用哪些API、数据库、文件系统和命令？每个工具是否具有独立身份、最小权限和参数校验？高风险操作是否需要人工确认或二次授权？

数据流层权限

工具返回的数据能否进入长期记忆？对话内容能否写入日志？模型输出是否可以直接触发外部动作？跨租户、跨项目和跨会话的数据是否有明确隔离？

一个更可操作的设计，是把“能否执行”与“能否读取”分开授权，并为每次工具调用绑定任务、用户、数据范围和有效期。对于支付、生产变更、删除数据或发送外部消息等动作，模型输出不应直接等同于执行指令。

不同部署架构的安全收益与实施条件

这张表不代表从上到下必然更好。架构选择取决于威胁模型、数据敏感等级、模型规模、可接受的性能影响、GPU兼容性和团队运维能力。对于低敏感度、完全由企业自有基础设施管理的任务，普通隔离机制可能已经足够；对于多方互不完全信任、模型和数据都具有高价值的场景，CPU与GPU共同构成的可信边界才更值得评估。

如何建立企业自己的评估边界

第一步：明确不信任对象

至少要列出以下主体：

• 云平台和宿主机管理员；
• 集群控制面和节点运维人员；
• GPU驱动、固件及设备管理组件；
• 模型服务提供方；
• 数据提供方和最终用户；
• 智能体所调用的外部工具；
• 日志、备份、监控和供应链服务。

如果威胁模型没有明确“不信任谁”，远程证明和密钥隔离就很难形成可验证的安全目标。

第二步：画出数据和密钥流

不要只画网络拓扑，还要标注每类资产的生命周期：

1. 数据从哪里进入；
2. 何时解密；
3. 何时进入CPU内存；
4. 何时进入GPU显存；
5. 是否经过卡间通信；
6. 是否写入缓存、日志或记忆；
7. 何时删除；
8. 谁能决定释放密钥。

这一步通常会暴露出“TEE只保护了推理容器，但检索服务、日志系统或凭证代理仍在普通环境运行”的断点。

第三步：验证证明能否驱动密钥释放

远程证明不应只是展示在控制台中的状态，而应成为密钥管理的前置条件。企业应要求方案说明：

• 证明由谁发起、谁验证；
• 验证哪些硬件、固件、内核、镜像和运行时测量值；
• 证明结果与哪个任务或租户绑定；
• 镜像更新后是否需要重新授权；
• 多GPU任务是否需要同时验证多个设备；
• 证明失败时系统是否拒绝启动或拒绝解密；
• 证明服务本身如何获得信任。

一种典型流程是：工作负载启动，提交硬件和软件证明，验证服务检查测量值，密钥代理确认策略后释放模型或数据密钥。任何“先解密、后证明”的设计，都应被视为需要额外解释的风险点。

第四步：用真实工作负载做验收

验收不应只运行一个推理示例，而应覆盖完整链路：

• 私有数据检索；
• 多轮对话和长期记忆；
• 模型加载和热更新；
• 多GPU推理；
• 容器扩缩容；
• 工具调用和凭证轮换；
• 节点故障与任务恢复；
• 日志、监控和备份；
• 密钥服务不可用；
• 远程证明失败。

验收结果也不能只看吞吐量。应同时记录启动时间、模型加载时间、资源利用率、任务失败后的恢复方式、兼容性限制、运维操作数量和性能波动。公开资料通常可以证明某项能力存在，但不能替代企业针对自身模型、数据和网络环境的实测。

机密计算不等于完整的AI安全

机密计算主要解决的是运行环境中的数据机密性和执行完整性问题。它不能自动解决以下风险：

• 模型本身存在的漏洞或后门；
• 提示词注入和间接提示词注入；
• 智能体错误调用高权限工具；
• 数据投毒、模型投毒和供应链污染；
• 网络层拒绝服务；
• 输出内容违规或业务决策错误；
• 应用自身的认证、授权和输入校验缺陷；
• 已获授权用户对敏感数据的滥用。

因此，企业应把机密计算放在纵深防御体系中，而不是作为“合规开关”或安全承诺的替代品。应用层权限、数据分级、网络隔离、密钥轮换、镜像签名、漏洞管理、审计和人工审批仍然不可缺少。

哪些场景值得优先采用

以下场景通常更值得评估机密计算：

• 数据提供方、模型提供方和基础设施提供方相互不完全信任；
• 企业需要在公有云上处理医疗、金融、研发或内部经营数据；
• 模型权重本身属于核心知识产权；
• 推理过程包含高价值检索内容、专有提示词或敏感中间状态；
• 智能体需要长期保存会话记忆并调用企业工具；
• 多方希望共同使用模型，但不希望彼此直接读取原始数据；
• 组织希望通过远程证明验证服务是否运行在约定的软件和硬件环境中。

相反，如果数据本身不敏感、模型可公开获取、运行环境完全由企业控制，或者现有应用无法承受硬件兼容性和运维复杂度，那么先完善普通容器安全、权限治理和密钥管理，可能比直接引入完整机密AI架构更合理。

最终的评估边界可以归纳为一句话：企业要保护的不是某一台CPU或某一块GPU，而是从数据进入、模型加载、推理执行、工具调用到结果输出的完整信任链。只有硬件TEE、GPU保护、容器编排、远程证明、密钥释放和智能体权限彼此衔接，机密计算才可能从基础设施特性转化为可验证的企业AI安全能力。