agent-">一、Agent 开始碰“秘密”：安全假设已经改变

大模型应用正从对话问答走向自主执行。今天的 Agent 在生产环境中调用内部接口、查询业务数据库、操作工单与消息系统、整理客户资料——这意味着它不可避免地要接触真正的“秘密”：API 密钥、数据库凭证、用户隐私数据、未公开的商业信息。

安全假设随之改变。过去泄露一条对话记录，多数情况下只是体验问题；而今天 Agent 被操纵一次，可能意味着一批数据被越权导出、一套凭证被间接滥用。安全边界需要重新划定，而划定之前，必须先看清 Agent 与传统云服务在安全模型上的本质差异。

二、为什么不能把 Agent 当普通微服务来防护

传统云安全体系建立在确定性之上：微服务的控制逻辑写在代码里，代码经过评审、测试、镜像扫描后才部署，运行时的每一条分支都可预期。凭证交给密钥管理服务托管，网络用私有网络与访问控制隔离，权限按最小授权收敛。这套体系隐含一个前提——“行为逻辑”是静态、可审计的。

Agent 打破了这个前提。它的控制逻辑有相当一部分来自上下文：用户输入、检索回来的文档、工具的返回结果、系统提示、历史对话、其他 Agent 发来的消息，全部汇入上下文窗口。模型基于这些内容决定下一步调用什么工具、检索什么数据、委派什么任务、是否继续执行。

换句话说，在 Agent 系统中，LLM 本身就是控制平面，而这个控制平面由数据语义驱动，业界研究对此已有明确表述：控制平面会被数据语义操纵。一段被检索进上下文的恶意文档，即使没有突破任何认证边界、没有利用任何系统漏洞，也可能改变 Agent 的工具调用与任务委派行为。攻击面从“网络与系统层”迁移到了“数据与语义层”——这是传统防护清单上没有的一行。

三、提示注入为何在 Agent 场景中格外危险

间接提示注入是 Agent 场景最具代表性的攻击方式，典型路径如下：

1. 投毒：攻击者在 Agent 可能检索的外部内容中埋入指令，公开网页、工单评论、协作文档、第三方接口返回的字段都可能成为载体；
2. 入窗：Agent 执行正常检索，恶意指令随文档一起进入上下文窗口；
3. 混淆：模型在机制上无法可靠区分“系统指令”与“数据中夹带的指令”，将恶意内容当作当前任务的合理组成部分；
4. 滥用：Agent 以合法身份调用工具，读取数据、发起请求，甚至把上下文中的敏感信息编码进外发内容，传到攻击者控制的服务器。

这类攻击的可怕之处在于：攻击者不需要偷取访问凭证，也不需要攻破任何服务器。Agent 的每个动作在权限系统看来都是“合法的”，因为发起调用的正是持有凭证的 Agent 本身。防火墙、入侵检测、访问控制监控的是系统层异常，而在这里，系统层的一切都“正常”。防御思路必须从“拦住非法请求”转向“保护控制平面不被伪造指令劫持”。

四、机密计算：把信任根从软件与运维下沉到硬件

机密计算承认一个现实：无论流程多么完善，运行中的明文数据总是暴露在“能看到它的人”面前——云平台运维人员、虚拟化层漏洞、宿主机内核被入侵的相邻租户。它给出的答案，是用可信执行环境（TEE）把信任根下沉到处理器：

• 内存加密与强隔离：TEE 内的代码与数据位于硬件加密保护的内存页中，加密密钥随处理器生成，宿主机、虚拟化层、运维通道均无法读取明文；
• 远程证明：TEE 可生成可验证的度量报告，向外部证明“运行的确是这版镜像、配置未被篡改”，外部系统据此决定是否交付秘密；
• 证明与密钥绑定：密钥管理服务可配置为只向通过远程证明的 TEE 实例发放凭证，发放后凭证仅存在于加密内存中。

对 Agent 而言，这带来三重价值：其一，上下文窗口的明文，包括用户隐私与检索内容，只在 TEE 内存在，平台侧不可见，收敛了运维与侧信道类泄露路径；其二，工具调用的凭证注入 TEE 后即被封存，即使上层编排组件被入侵，凭证也难以被导出重放；其三，模型权重与私有知识库同样可在 TEE 内解密使用，实现“保护用户数据”与“保护模型资产”的双向安全。

一个示意性的密钥交付流程如下：

# 示意：基于远程证明的凭证发放
enclave = launch_tee(runtime_image)            # 启动机密计算实例
report  = enclave.attest(image_hash, nonce)    # 生成远程证明报告
if verifier.verify(report, policy):            # 校验镜像度量与证明策略
    creds = kms.release(agent_id, report)      # 证明通过才发放凭证
    enclave.inject(creds)                      # 凭证仅存在于加密内存

五、机密计算不是银弹：分层的 Agent 安全架构

必须澄清边界：TEE 防的是“平台层攻击者”，它无法阻止模型“心甘情愿地”执行一段恶意指令，提示注入是语义层问题，硬件隔离解决不了语义层。因此正确做法是纵深防御，机密计算是底层边界而非全部：

• 语义层，上下文治理：对上下文做指令与数据的来源标注与信任分级，外部检索内容默认降权；在输入侧与输出侧增加敏感信息与可疑指令检测，缩小可被注入的面；
• 权限层，工具最小授权：为每个工具配置独立凭证，按任务动态发放短时效权限，高危操作（外发数据、批量导出、资金相关动作）强制人工确认；
• 运行时层——机密计算承载：将 Agent 运行时与推理服务部署在 TEE 实例中，凭证、上下文、中间产物不出加密内存；
• 基础设施层，常规云安全：私有网络隔离、镜像签名校验、全链路审计日志（注意日志本身需脱敏，避免成为新的泄露源）。

六、落地建议

1. 先画“秘密流”：梳理 Agent 会接触哪些凭证与数据、流经哪些组件、在哪些环节以明文存在，再决定哪些环节必须进入 TEE；
2. 优先收紧凭证发放边界：让密钥管理服务只信任通过远程证明的实例，这是性价比最高的一步；
3. 上下文最小化：不把全部历史与全部检索结果塞进窗口，按需检索、及时清理，可被注入的内容越少，攻击面越小；
4. 按“必然被注入”设计：为每个工具预判最坏情况下的越权动作，据此收紧授权范围；
5. 关注平台能力成熟度：目前百度智能云等主流云厂商已将基于可信执行环境的机密计算实例纳入通用计算产品体系，选型时重点验证远程证明流程的开放性、与密钥管理服务的集成方式，以及推理场景下的性能开销。

七、结语

当 Agent 开始处理秘密，安全重心必须从“保护服务器”转向两件事：保护控制平面所在的执行环境，同时承认控制平面本身可能被语义操纵。机密计算把“平台不可信”变成一个可工程化防御的假设，为 Agent 提供了不依赖运维自律的底层安全边界；在此边界之上，语义层的上下文治理与权限层的最小授权同样不可或缺。三者叠加，Agent 才能真正走出演示环境，进入承载真实秘密的生产系统。