agent-tee-">AI Agent 机密计算部署：TEE 与远程证明落地实践

一、部署概述

本文讨论的部署对象，是面向 AI Agent 系统的机密计算安全底座。具体来说，是在 Agent 运行环境（包括模型推理服务、工具调用网关、记忆存储、凭证管理组件）中引入可信执行环境（TEE）与远程证明机制，使 Agent 处理敏感数据与高权限操作时，其计算过程处于可被验证的硬件隔离边界内。

部署完成后应达到的效果包括：

• Agent 的核心计算组件运行在 TEE 保护的内存区域中，宿主操作系统、虚拟化层与云平台运维人员无法直接读取其中的明文数据与密钥；
• 服务启动时生成可验证的度量证据，由上游调度方或密钥服务通过远程证明校验其完整性，校验通过后才下发解密密钥或放行敏感接口；
• API Token、数据库凭证、长期记忆中的敏感内容在”使用中”状态下同样受到加密与隔离保护，而不只是传输加密与静态加密；
• 形成可审计的证明日志，为安全事件溯源提供基础设施层证据。

本文适合以下读者：负责 Agent 平台部署的开发者与运维工程师、设计 Agent 安全架构的架构师、以及需要评估 Agent 上线合规性与数据安全边界的技术负责人。

部署前需要理解的基本背景：机密计算并非单一软件开关，而是依赖特定硬件能力（如 CPU 提供的可信执行环境扩展）、配套的固件与虚拟化支持、证明服务与密钥管理体系的协同。不同硬件代际、不同虚拟化形态对 TEE 的支持程度存在差异，部署方案必须先确认底层环境能力，再设计上层组件拆分。

二、部署场景

机密计算在 Agent 系统中的典型适用场景包括：

1. 企业知识库 Agent：Agent 检索内部文档、合同、财务数据并生成回答。文档内容与检索结果进入上下文窗口，属于高敏感数据，需要在处理阶段隔离。
2. 金融与政务 Agent：Agent 持有数据库凭证、调用审批接口、执行多步业务操作，凭证与业务数据不能被基础设施层读取。
3. 多 Agent 协作系统：主 Agent 向子 Agent 委派任务时传递令牌与上下文片段，需要确保委派链路中每一跳的执行环境可信。
4. 研发环境 Agent：Agent 读取代码仓库、执行构建与脚本，代码与密钥属于核心资产。

需要明确的是，机密计算解决的是”基础设施信任”问题，即不信任宿主与运维路径的前提下仍能保护数据。它不能替代提示注入防护、输出审核、工具调用白名单等软件层护栏，二者是分层关系而非替代关系。

三、架构与组件拆解

一个可落地的 Agent 机密计算部署通常包含以下模块：

层次	组件	职责
硬件层	支持 TEE 的计算实例	提供内存加密与隔离执行环境
虚拟化层	机密虚拟机或机密容器运行时	将 Agent 工作负载封装进受保护边界
证明层	证明生成组件 + 证明验证服务	产出度量证据并校验环境完整性
密钥层	密钥管理服务（KMS）	依据证明结果决定是否释放密钥
应用层	Agent 推理服务、工具网关、记忆存储	在 TEE 内处理敏感数据
网络层	负载均衡、内网访问控制、mTLS	保障跨组件通信安全
可观测层	日志、指标、审计	记录证明结果与异常事件

关键设计原则是：敏感组件尽量集中到同一个可信边界内。如果 Agent 推理服务在 TEE 内，但记忆存储和凭证服务在 TEE 外，则敏感数据仍会在边界外暴露。常见做法是将推理服务、工具调用网关与短期凭证缓存部署在同一机密实例或同一机密容器组内，持久化存储则通过加密后落盘、密钥受证明保护的方式衔接。

四、前置准备

部署前需完成以下准备项：

1. 硬件与实例能力确认
确认目标计算实例支持所需的 TEE 能力，包括 CPU 代际、固件版本、是否支持机密虚拟机或机密容器。可通过云平台文档与实例规格说明核对，避免在部署中途发现能力缺失。

2. 账号与权限规划
准备资源创建、密钥管理、证明服务访问三类权限，按最小权限原则分配给部署账号与运行账号。运行账号不应具备修改证明策略的权限。

3. 网络规划
划分子网，明确证明服务、密钥服务、Agent 服务之间的访问路径；为跨组件通信准备证书；确认 TEE 实例的出网策略，避免敏感服务暴露在公网。

4. 镜像与依赖准备
构建包含 Agent 运行时、依赖库、启动脚本的容器镜像或系统镜像。镜像需固定版本并记录构建指纹，因为镜像度量值将参与远程证明校验。

5. 证明策略定义
提前定义”什么是可信环境”：允许的镜像摘要、允许的启动参数、允许的固件版本。策略应写入证明验证服务的配置，作为后续放行依据。

6. 密钥体系设计
规划密钥层级：根密钥由密钥管理服务托管，数据密钥由根密钥派生或封装，数据密钥仅在证明通过后释放给 TEE 内组件。明确密钥轮换周期与吊销流程。

7. 数据准备
对需要进入 Agent 上下文的敏感数据分类分级，明确哪些数据必须只在 TEE 内解密，哪些可以留在外部存储。准备测试用的脱敏数据集用于上线验证。

五、部署流程

步骤一：初始化基础环境

创建支持 TEE 的计算实例或机密容器集群，配置子网、安全组与访问策略。此步骤的作用是建立受保护的运行底座；注意点是实例规格必须与前置确认的能力一致，安全组默认拒绝所有入站，仅按需放行。

步骤二：构建并固化应用镜像

将 Agent 推理服务、工具网关、证明生成组件打包为镜像，构建过程记录依赖版本与构建指纹。伪代码示意构建清单：

image:
  base: runtime-base-fixed-version
  components:
    - agent-inference-service
    - tool-gateway
    - attestation-agent
  artifacts:
    - build-manifest.json   # 记录各组件版本与哈希

镜像固化是远程证明的前提：度量值随镜像变化而变化，任何未登记的变更都会导致证明校验失败。

步骤三：部署证明验证服务与密钥服务

证明验证服务独立部署在受控环境中，负责接收 TEE 内组件上报的度量证据，按预定义策略校验，并向密钥服务返回放行/拒绝结果。密钥服务配置访问策略：仅接受来自证明验证服务的放行凭证。此步骤将”环境可信”转化为”可获取密钥”的因果链。

步骤四：配置 TEE 内应用启动参数

在机密实例或机密容器中配置启动参数，包括证明服务地址、密钥服务地址、密钥请求超时、证明失败时的降级策略（建议默认拒绝而非放行）。示意配置：

attestation:
  verifier_endpoint: internal-verifier:8443
  evidence_refresh_interval: 300s
  on_failure: deny
key_management:
  endpoint: internal-kms:8443
  key_release_mode: attested_only

on_failure: deny 是关键配置：证明失败时服务应拒绝启动或拒绝解密，而不是带病运行。

步骤五：启动服务并完成证明握手

按”证明生成 → 证据上报 → 策略校验 → 密钥释放 → 服务解密启动”的顺序执行。启动日志中应能看到证明校验通过的时间戳与度量摘要。若证明失败，服务应停留在未就绪状态并输出可诊断的错误码。

步骤六：开放访问与流量接入

将负载均衡指向已就绪实例，配置健康检查。健康检查端点应区分”进程存活”与”证明通过”两个状态，只有证明通过的实例才纳入流量。

步骤七：建立可观测与审计链路

采集证明结果日志、密钥释放记录、服务错误日志与资源指标，接入监控告警。审计日志建议独立存储并设置写保护，防止被运行环境篡改。

六、上线验证

部署完成后按以下清单验证：

1. 服务可访问性：通过内网调用 Agent 接口，确认响应正常、时延在预期范围；
2. 证明链路验证：在测试实例上故意修改镜像或启动参数，确认证明校验失败、密钥不释放、实例不纳入流量——这是最重要的负向验证；
3. 数据隔离验证：从宿主侧尝试读取 TEE 内进程内存，确认无法获取明文（该操作需在受控测试环境进行）；
4. 日志与审计：确认证明通过/失败事件均有记录，且日志中不含明文密钥与敏感数据；
5. 资源状态：观察 CPU、内存、网络指标是否稳定，TEE 带来的性能开销是否在可接受区间。

七、常见问题与排查

• 证明校验持续失败：多为镜像摘要与策略登记不一致、固件版本升级后度量变化、或证明服务与实例间网络不通。排查顺序为：核对策略登记 → 核对镜像指纹 → 检查网络与证书。
• 服务启动后无法获取密钥：检查证明验证服务返回码、密钥服务访问策略是否仅允许放行凭证、时钟偏差是否导致凭证过期。
• 性能明显下降：TEE 的内存加密与上下文切换存在开销，需评估是否将非敏感组件移出可信边界以缩小保护范围，或调整实例规格。
• 多实例证明结果不一致：检查是否混用了不同代际硬件或不同镜像版本，统一基线后重新登记策略。

八、运维与优化

稳定性：为证明服务与密钥服务设置多副本与健康检查，避免单点导致全量实例无法启动；配置证明失败告警并预设降级预案。

安全：定期轮换密钥并吊销旧凭证；收紧证明策略，禁止宽泛的镜像通配；审计日志与业务日志分离存储；对工具网关的出站访问设置白名单，降低敏感数据外传风险。

性能与成本：按组件敏感度划分可信边界，只把真正处理秘密的组件放进 TEE，避免全量上机密实例导致成本与性能双重压力；对闲置实例设置弹性伸缩下限，控制资源开销。

可维护性：将镜像构建、策略登记、证明配置纳入版本管理，形成”镜像变更 → 策略更新 → 证明验证 → 灰度发布”的闭环流程；每次变更后执行负向验证，确保防护未失效。

九、总结

Agent 进入企业真实环境后，其安全边界不再只由提示词规则与软件沙箱决定，而是下沉到基础设施层。本文给出的部署路径是：先确认 TEE 能力与信任边界，再将敏感组件收敛到同一可信范围，通过远程证明把”环境可信”转化为”密钥可释放”，最后以上线验证与负向测试确认防护真实生效。部署重点在于证明策略的严格性、失败默认拒绝的启动逻辑，以及密钥释放链路的端到端可审计。后续运维应持续围绕策略登记、密钥轮换、性能开销与成本控制迭代，使机密计算成为 Agent 安全体系中稳定可靠的一层底座。