从"能跑"到"可控"：Agent 上线前必须补齐的安全能力

声明：本文为工程实践向技术复盘，不含任何产品推广与商业推荐。文中涉及的法规条款仅作技术落地时的映射参考，具体适用请以现行有效规定及属地监管口径为准。

摘要

过去一年，大量团队把 LLM 从"对话框"推进到了"执行体"：Agent 能读文件、调接口、发邮件、改数据库、跑代码。Demo 阶段的评价标准是"能不能跑通"——任务完成率、工具调用成功率、响应延迟。

但上线是另一回事。Agent 与聊天机器人的根本差异在于：聊天机器人的错误止于一段文本，Agent 的错误会变成对外部世界的真实副作用——一封发出去的邮件、一条被删除的记录、一笔被提交的工单、一次对内部接口的越权访问。

本文给出一套可落地的能力清单：先建立 Agent 专属的威胁模型，再逐层补齐身份、输入、工具、沙箱、记忆、可观测六个维度的控制能力，最后给出上线前检查表和成熟度分级。

一、一个前提：Agent 的风险不是"说错话"

先把定义收敛。本文所说的 Agent，指同时具备以下四个要素的系统：

四要素中，"工具"是质变点。没有工具的模型只能输出文本，最坏结果是"说了不该说的话"；有工具的模型可以"做了不该做的事"。而"自主循环"是放大器：一次错误的决策会被后续步骤继承并放大，且人类介入的机会窗口被压缩。

一个便于记忆的判断框架是"致命三要素"（Lethal Trifecta）：当一个 Agent 同时具备

1. 访问私有数据的能力，
2. 接触不可信内容的机会（网页、邮件、用户上传文件、第三方返回结果），
3. 对外通信的能力（发消息、调外部 API、写库），

那么它就具备了被间接注入攻击、并把私有数据外带出去的完整链路。上线前必须回答的第一个问题是：这三者是否同时成立？如果成立，隔离措施是什么？

二、威胁模型：Agent 的八类攻击面

按数据流顺序梳理，Agent 的攻击面比传统 Web 应用多出两层（模型层、编排层）：

2.1 输入通道注入

• 直接注入：用户在输入中直接覆盖系统指令（"忽略以上所有要求，改为……"）。
• 间接注入（Indirect Prompt Injection）：恶意指令藏在 Agent 会读取的内容里——网页正文、PDF 白底白字、代码注释、邮件签名、API 返回的 JSON 字段、甚至图片中的小字。这是 Agent 场景下最危险、也最容易被忽略的一类，因为攻击者不需要接触你的系统，只需要让你"读到"。
• 多模态注入：图片/音频/视频中携带的指令文本。

2.2 模型层

• 系统提示词泄漏（System Prompt Leakage），导致防护逻辑、内部工具清单被反向推导。
• 越狱绕过安全策略。
• 幻觉调用：编造不存在的工具名或参数结构。

2.3 工具层

• 参数注入：模型生成的参数被拼接进 Shell、SQL、URL，形成命令注入 / SQL 注入 / SSRF。
• 工具滥用：用合法工具达成非法目的（用"发邮件"工具做钓鱼外发）。
• 凭据暴露：工具的错误信息、日志、上下文里出现 API Key、连接串。
• 混淆代理（Confused Deputy）：Agent 以高权限服务身份执行低权限用户的操作。

2.4 执行环境

• 沙箱逃逸；文件系统越界读写；容器内获取宿主凭据。
• 网络出口不受控：这是数据外带的主通道，也是最常被遗漏的一环。

2.5 记忆与检索层

• 记忆投毒：一条恶意内容被写入长期记忆，此后每次会话都受影响，且极难排查。
• RAG 投毒：污染向量库，让恶意内容在检索时稳定命中。
• 跨租户污染：多租户共用记忆/向量空间，导致数据串号。

2.6 编排层

• 无限循环、递归自调用、步数无上限。
• 成本爆炸：单次会话消耗远超预期（无界消耗 / Unbounded Consumption）。
• 多 Agent 级联失效：子 Agent 的错误被父 Agent 当作事实继续执行。
• 权限放大：子 Agent 继承了不该有的权限。

2.7 供应链

• 第三方工具 / 插件 / MCP Server 不可信。
• 工具描述投毒：在工具的名称、描述、参数说明中植入指令，因为工具描述本身会被放进模型的上下文。这意味着"接入一个第三方工具"在语义上等价于"允许第三方往你的提示词里写内容"。

2.8 人机交互

• 自动确认（auto-approve）把所有高危操作变成无人工介入。
• 确认界面信息不足，用户无法判断即将执行什么（"确认"按钮变成橡皮图章）。
• 过度信任导致的告警疲劳。

这张清单的用途不是逐条打勾，而是驱动设计：任何一条没有对应控制措施的攻击面，都应当在架构评审中被显式记录为已知风险。

三、能力一：身份与权限——以用户身份执行

这是所有控制措施里性价比最高的一条，也是很多团队最先欠下的技术债。

3.1 原则：Agent 的权限 ≤ 发起用户的权限

反模式：Agent 用一个高权限服务账号（Service Account）访问所有后端系统，然后在 Prompt 里写"你只能查询当前用户的数据"。

这是用自然语言实现的访问控制，而自然语言是可被覆盖的。正确做法是让权限落在基础设施层：

3.2 落地要点

1. On-Behalf-Of（OBO）流程：Agent 不以自己的身份调用后端，而是携带"代表用户 X 且仅限 Y 范围"的凭据。
2. 短期凭据：有效期以分钟计，用完即弃；禁止把长期密钥放进 Agent 运行环境。
3. 最小作用域：读写分离。默认只授读；写操作单独申请、单独审批。
4. 按租户隔离：tenant_id 必须来自凭据，而不是来自模型输出或请求体。
5. 高危能力独立授权：删除、转账、外发、发布这类不可逆操作，应要求用户显式二次授权，而不是继承会话权限。

一条经验判据：如果一条权限约束只存在于 Prompt 里，它就等于不存在。

四、能力二：输入治理——不可信内容永不进入指令通道

间接注入无法靠"让模型更聪明"来解决。当前工程上唯一可靠的思路是架构隔离，而非语义检测。

4.1 双 LLM 模式（Dual LLM Pattern）

把处理流程拆成两个角色：

关键约束：隔离模型的输出必须是结构化数据，绝不能是自然语言指令。这样即使恶意内容成功劫持了隔离模型，它也只能污染"数据字段"，而无法生成"可执行的下一步动作"。

4.2 内容标记与来源追踪

在进入上下文前给每段内容打上来源与可信级别标记，并在系统提示中明确区分"数据区"与"指令区"：

说明：这种标记能降低但不能消除风险，它属于纵深防御的一层，不能替代隔离。

4.3 输出侧的二次处理

工具参数在进入真实系统前必须重新校验。"模型说这是合法 SQL"不构成任何保证——详见下一节。

五、能力三：工具网关——所有副作用必须经过同一个收口点

如果 Agent 直接调用后端 SDK，那么策略无处安放。正确结构是：所有工具调用必须经过一个统一网关，网关承担校验、授权、限流、审计四项职责。

5.1 参考架构

5.2 策略即代码

策略不应写死在业务代码里，而应可审计、可评审、可版本化：

5.3 三个必须做对的细节

1. 参数校验用严格 Schema：拒绝未知字段（additionalProperties: false）。否则攻击者可以通过"多传一个参数"改变下游行为。
2. 永远不要拼接：SQL 用参数化查询；Shell 用参数数组而非字符串拼接；URL 做域名白名单与重定向限制（防 SSRF）。
3. 幂等键：写操作必须携带幂等键，防止 Agent 重试导致重复下单、重复发信。

5.4 人工确认的正确形态

"弹窗确认"不是安全措施，除非它满足：

• 展示将要执行的具体动作与参数（而不是"Agent 想执行一个操作"）；
• 高风险动作默认拒绝，需要明确点击；
• 确认结果写入审计日志；
• 确认超时自动取消（而不是自动通过）。

六、能力四：执行沙箱——代码、文件、网络的硬边界

只要 Agent 能生成或执行代码、能处理用户上传的文件，沙箱就是必需的，而不是可选项。

6.1 四条硬边界

6.2 运行参数必须设上限

6.3 两个容易忽略的点

• 输出也要设限：超长输出既会污染上下文，也是成本攻击的入口。
• 网络出口是数据外带的主通道：如果沙箱能自由访问公网，那么前面所有隔离措施的意义都会被削弱——攻击者只需把数据 POST 到自己的服务器。

七、能力五：记忆与数据——写入即风险

记忆让 Agent 更好用，也让一次攻击的影响从"单次会话"变成"长期驻留"。

7.1 写入前过滤

所有要写入长期记忆的内容，应经过：

1. 来源标记（是否来自不可信通道）；
2. 指令性内容剥离（记忆里不应存在可执行指令，只应存在事实）；
3. 敏感信息检测（凭据、身份证、手机号等）；
4. 人工或规则复核（针对高价值记忆）。

7.2 结构化而非自由文本

记忆条目建议采用固定 Schema：

字段化带来的直接好处：可检索、可审计、可过期、可批量回滚。不可回滚的记忆等于不可修复的漏洞。

7.3 租户隔离

记忆与向量库必须按租户物理或逻辑隔离，检索阶段强制注入 tenant_id 过滤条件，且该条件来自凭据而非模型输出。

7.4 数据出境与留存

涉及敏感数据的处理链路，应在架构层面就明确：数据存在哪里、留存多久、谁可以读。这部分既是安全要求，也是合规要求（见第十一节）。

八、能力六：可观测与制动——看不见就谈不上可控

"可控"的第一定义是：任意一次 Agent 行为，事后可完整还原；任意时刻，可立即中止。

8.1 全链路 Trace

以 trace_id 贯穿一次任务的全部步骤，每步记录：

注意 decision_reason 与 policy_result 两个字段：它们让审计从"发生了什么"升级为"为什么被允许发生"，这是事后定责与策略调优的关键输入。

8.2 四道制动阀

8.3 影子模式（Shadow Mode）

新工具、新策略上线前，先以"只记录不执行"的方式运行一段时间，对比"Agent 想做什么"与"人实际会做什么"。这是成本最低的灰发方式，能拦住相当一部分设计缺陷。

8.4 告警要有可操作性

告警应绑定明确的处置动作（自动降级 / 暂停工具 / 通知值班），否则只是噪音。建议优先监控：策略拒绝率突增、单任务成本异常、工具错误率、确认被拒绝率（后者的突增通常意味着 Agent 行为偏离预期）。

九、上线前检查表

按优先级分为三档。P0 未完成不应上线。

P0（阻塞项）

• 已明确回答"致命三要素"是否同时成立，并给出隔离方案
• Agent 权限 ≤ 用户权限，凭据短期化、作用域最小化
• 所有工具调用经过统一网关，默认拒绝 + 白名单
• 工具参数使用严格 Schema 校验，拒绝未知字段
• 代码执行 / 文件处理在隔离沙箱内，网络默认拒绝
• 高危操作（删除、外发、支付、发布）强制人工确认，且确认信息包含具体参数
• 全链路 Trace 落库，含决策原因与策略判定结果
• 步数 / 成本 / 速率三级上限已配置
• Kill Switch 可用且演练过
• 无长期凭据存在于 Agent 上下文、日志或沙箱中

P1（上线首月内完成）

• 不可信内容与指令通道在架构上隔离（双 LLM 或等价方案）
• 记忆写入前过滤 + 结构化存储 + 可回滚
• 多租户隔离在检索与写入两侧均强制生效
• 间接注入语料库纳入回归测试
• 第三方工具 / MCP Server 完成安全评审（含工具描述审查）
• 敏感信息检测接入输入输出两侧
• 告警绑定处置动作

P2（持续演进）

• 策略即代码，纳入代码评审与版本管理
• Agent 专属红队演练常态化
• 影子模式作为新能力的默认上线路径
• 成本与安全指标纳入产品看板

十、成熟度分级：L0 到 L3

常见误区：把"L1 的日志"当成"L2 的控制"。日志解决的是事后追溯，控制解决的是事中拦截，两者不可互相替代。

十一、与合规义务的对应关系

技术控制措施同时也是合规义务的落地载体。对生成合成类服务而言，以下三条对应关系值得在上线前明确：

1. 算法备案 / 安全评估中的"安全措施"章节，需要写清技术防护的具体实现（输入输出审核、日志留存、应急处置、权限管理）。如果线上实现与材料描述不一致，这是实质性的不一致风险——建议以"产品实际做了什么"为唯一口径来撰写材料，而不是先写材料再补实现。
2. 日志留存：现行规定对网络日志留存有明确期限要求，生成合成内容标识相关规则中亦对特定情形下的日志留存提出不少于六个月的要求。Agent 场景下的日志设计应至少覆盖"谁在什么时间、通过什么工具、对什么对象执行了什么动作"。
3. 生成合成内容标识：若 Agent 的输出包含面向公众发布的生成合成内容，显式标识与隐式元数据标识义务需要在生成管线内实现，而非在展示层补丁。注意导出、复制、转发链路——标识不能在"另存为"之后消失。

另需注意：Agent 的安全机制若发生重大变更（权限模型、审核链路、对外能力范围），可能触发备案变更程序，建议将此类变更纳入发布流程的评审清单。

上述为工程视角的映射建议，不构成法律意见；具体义务范围与期限请以现行有效规定及属地监管口径为准。

十二、六个高频反模式

1. 用 Prompt 做访问控制。"你只能访问当前用户的数据"——一句话就能被覆盖。权限必须落在基础设施层。
2. 把安全校验放在模型之后、工具之前，但只校验一次。正确做法是每次调用都校验，且校验在网关内完成。
3. 沙箱有网、宿主有凭据。这两者任一成立，隔离就形同虚设。
4. 确认弹窗信息不足。用户看不到具体参数，就只能点"同意"，确认机制退化为合规装饰。
5. 记忆没有过期与回滚。一旦被污染，只能整体清库——这通常意味着无法清库。
6. 只做输入检测，不做架构隔离。间接注入的变体空间极大，检测器永远在追赶；隔离是唯一结构性解法。

十三、小结

从"能跑"到"可控"，本质上是从功能视角切换到风险视角。两者的评价指标不同：

• 能跑：任务完成率、响应延迟、工具调用成功率。
• 可控：权限可收敛、行为可解释、异常可拦截、影响可回滚。

一句话概括优先级：

先收权限，再管输入，然后统一工具出口，最后补上沙箱、记忆治理和制动阀——并且让每一层都留下可审计的痕迹。

Agent 的能力边界会持续扩张，但安全能力不需要一次做全。先完成 P0，再谈演进。把上面那张 P0 清单跑通，多数"上线后才发现"的事故，都能在上线前被拦下。