Agent 安全会遇到一个老问题：谁能看见运行中的秘密

Agent 一旦进入企业系统，就会开始碰到密钥、凭证、客户数据、内部文档、代码仓库、数据库查询结果和审批状态。过去很多 AI 安全讨论集中在提示注入、越权工具调用和输出审查上，这些都重要，但还不够。

更底层的问题是：Agent 在执行任务时，谁能看见它正在处理的秘密。

如果 Agent 跑在云端，它的上下文、工具回执、记忆片段和临时凭证可能经过宿主机、容器、GPU、日志系统、调试工具和运维面。企业可以用访问控制和审计降低风险，但这些措施大多仍然在软件栈里。遇到高权限攻击者、被攻破的云主机、错误配置或内部运维风险时，软件边界并不总是足够硬。

这就是机密计算重新上桌的原因。它不是新概念，但 Agent 把它推回了 AI 架构中心。

Agent 的秘密是一条执行链

《When Agents Handle Secrets》这篇综述把 Agentic AI 的威胁面拆得很清楚：LLM-driven agents 会规划、调用工具、维护持久记忆，还会通过 MCP 和 A2A 这类协议把任务交给别的 Agent 或服务。它们积累敏感上下文，持有凭证，并跨多个 pipeline 工作。

这和传统模型推理不一样。一次普通推理里，敏感输入进入模型，输出回来，风险主要集中在输入、模型服务和日志。Agent 的问题更长：它先读资料，再调用工具，再写记忆，再把中间结果交给另一个组件，再根据结果继续执行。秘密会沿着执行链移动。

这条链越长，越难只靠提示词和权限配置兜住。一个凭证可能出现在工具返回里，一个客户名可能被写进长期记忆，一个内部文档片段可能进入下游 Agent 的上下文。只要链路里某个运行环境不可信，秘密就可能被看见或被篡改。

所以 Agent 的安全边界要比模型 API 更厚。它不只保护输入输出，还要保护计划、记忆、工具调用、临时文件、凭证、审计轨迹和跨 Agent 消息。

TEE 解决的是「高权限也看不见」

机密计算的核心是可信执行环境，通常叫 TEE。它希望在硬件层隔离代码和数据，让宿主机、hypervisor、云平台管理员这类高权限主体，也不能直接读取受保护工作负载里的明文。

Intel TDX 面向虚拟机级隔离。Intel 官方资料把它描述为一种帮助提升 VM 级保密性和隐私控制的 confidential computing 技术。NVIDIA H100 则把 Confidential Computing 列为 Hopper 架构的重要能力，官方页面称 H100 是第一款带有这类能力的数据中心加速器。

这些技术放到 Agent 场景里，意义很具体。企业不是只想知道「模型会不会泄密」，还想知道「运行这段 Agent 工作流的基础设施能不能被证明是可信的」。远程证明可以让调用方确认：当前工作负载运行在预期代码、预期硬件、预期安全配置里，而不是被替换过的环境。

如果 Agent 要处理财务凭证、医疗数据、源代码密钥或客户合同，TEE 和远程证明就不再是锦上添花。它们会变成「能不能把这类任务交出去」的前置条件之一。

MCP 让授权边界变得更具体

MCP 的出现，让 Agent 工具接入更标准，也让安全边界更具体。MCP 安全最佳实践强调 token audience validation，明确禁止 token passthrough，并要求结合授权规范和 OAuth 2.0 安全最佳实践理解。

这类规则解决的是协议层问题：谁能代表谁访问哪个资源，token 应该发给谁，客户端和服务端之间如何避免令牌被错误转发。它们很必要，但它们假设运行环境本身能守住边界。

机密计算补的是另一层：如果 MCP 客户端、Agent runtime 或工具代理处理敏感 token，运行它的环境是否也可信。协议授权回答「这个请求是否被允许」，TEE 和远程证明回答「处理这个请求的环境是否就是它声称的环境」。

这两个问题不能互相替代。只有 OAuth，没有运行时隔离，密钥仍可能被高权限环境读取；只有 TEE，没有细粒度授权，Agent 仍可能拿到过大的工具权限。企业 Agent 安全要把两层合在一起看。

机密计算也不能被写成万能答案

这篇不能写成「TEE 一上，Agent 就安全了」。机密计算解决的是部分威胁，不是全部威胁。

第一，它不自动阻止 Agent 自己犯错。Agent 如果被提示注入诱导，把本来有权访问的数据发给错误工具，TEE 只会保护这段错误执行不被外部看见，并不会替你判断动作是否合理。

第二，TEE 本身也需要持续修补。硬件信任边界不是魔法。越是把安全押在硬件证明上，越要保留补丁、吊销、版本检查和 defense-in-depth。

第三，GPU 规模化仍有成本和性能问题。《When Agents Handle Secrets》把 GPU TEE performance at LLM scale 和 multi-hop agent chains 的 compound attestation 列为开放挑战。换成工程话就是：一个 Agent 调多个工具、多个 Agent 互相委托、CPU 和 GPU 之间传数据，这些环节都要能证明和保护，系统会变复杂。

机密计算更适合被看作底座，而不是单点产品功能。它能把一类基础设施风险压低，但仍要和权限、审计、检测、数据脱敏、记忆治理和人工确认一起使用。

哪些 Agent 最先需要这层底座

不是所有 Agent 都需要机密计算。写公开博客摘要、整理开源 issue、生成普通代码片段，可能不值得引入这层复杂度。最先需要它的，是处理高价值秘密、强监管数据和跨组织协作的 Agent。

几类场景会更早进入这条路线：

  • 企业内部代码 Agent：需要读私有仓库、CI 密钥、部署日志和安全扫描结果。
  • 金融与法务 Agent：会处理合同、交易材料、客户身份信息和审计底稿。
  • 医疗与科研 Agent：会接触病历、实验数据、受限数据集和多机构协作材料。
  • 安全运营 Agent：会读告警、凭证暴露、漏洞细节和内部资产拓扑。
  • 跨公司协作 Agent：任务链经过多个组织，必须证明每一跳的运行环境。

这些场景共同点重点是错误和泄露代价更高。企业不会因为 Agent 好用，就自动放弃对数据位置、运行环境和凭证链路的控制。

Agent 基础设施会多一条信任链

接下来 Agent 平台如果继续往企业深处走，安全架构里大概率会多一条信任链。

第一层是身份和授权：谁发起任务，Agent 代表谁，能访问哪些 MCP server 和内部 API。第二层是运行证明：这段 Agent runtime 是否运行在可信硬件和预期镜像里。第三层是行为检测：工具调用、记忆写入、外发动作是否符合策略。第四层是审计和撤销：出了问题能不能追到哪条记忆、哪个 token、哪个工具调用影响了结果。

机密计算只覆盖其中一层，但这一层很关键。没有它，很多企业只能相信云平台和运行时供应商不会看见敏感执行过程；有了它，至少可以把一部分信任从「相信人和流程」转成「验证硬件、镜像和配置」。

Agent 越像真实员工，越会接触真实秘密。到了这一步，安全就不能只问「模型会不会泄密」，还要问「运行这个 Agent 的机器，凭什么值得信任」。