Agent开发系列（六）-安全护栏建设

优先级	风险类别	理由
P0	工具滥用、权限逃逸	Blast Radius 最大，直接决定 Agent 能造成多大的破坏
P0	跨用户数据泄露	隐私合规红线，一旦发生是不可逆的
P1	Prompt 注入（直接/间接）	入口风险，攻击成本低，成功率高
P1	领域幻觉	专业场景下误导性最强，直接影响业务决策
P1	级联失败	多 Agent 架构的核心风险，错误沿链路放大
P2	诱导性输出	需要累积才能造成损失，可通过对话轮次限制缓解
P2	供应链风险	依赖外部依赖管理，属于被动风险
P3	模型后门	当前技术无法检测，只能依赖模型提供方

二、六大风险深度分析

2.1 输入层：攻击者的主战场

为什么输入层风险最多、最难防？

因为输入是 Agent 唯一无法控制的外部入口。传统软件的输入是结构化数据，有明确的类型和边界。Agent 的输入是自然语言——没有任何"正常输入"的定义边界，任何合法的自然语言表达都可以被改造成攻击载体。

注入类型	攻击路径	防御难度	本质问题
直接注入	用户输入直接带指令	低（字符串匹配可拦截）	输入与指令未分离
间接注入	外部数据源（网页/文档）埋入指令	高（数据源不可控）	Agent 缺乏上下文来源识别
递归注入	工具输出作为输入再次处理	高（需要输出清洗）	缺乏输入来源追溯
编码混淆注入	base64/Unicode绕过检测	中（需解码检测）	依赖字符串黑名单
角色扮演注入	改变 Agent 的行为边界定义	高（模型会遵从角色指令）	模型对齐被绕过
指令覆盖注入	"忽略之前所有指令"	中（特定模式可拦截）	指令优先权未固化
隐式注入	在长上下文中稀释关键指令	高（模型注意力有限）	关键指令未结构化锚定
跨语境注入	藏在表格/JSON/图片描述中	高（解析上下文复杂）	非文本内容未做安全扫描

2.2 模型层：护栏的盲区

为什么模型层风险最特殊？

因为这是唯一一个护栏无法从外部解决问题的层级。输入层可以加校验，工具层可以加白名单，输出层可以加过滤——但模型层的幻觉和越狱是模型本身的行为特性，护栏只能在边界做兜底，不能改变模型的决策逻辑。

幻觉类型	触发条件	危险程度	可检测性
高置信度幻觉	模型对错误内容表达得很确定	高（用户会信以为真）	低
领域幻觉	在专业领域（法律、医疗、金融）生成看似专业的内容	极高（直接造成业务损失）	极低
引用幻觉	凭空生成不存在的 URL、文档、论文	中（容易被核实）	中
角色幻觉	Agent 声称拥有自己没有的能力或权限	中（可能导致权限滥用）	低

2.3 工具层：Blast Radius 的边界

工具层的风险为什么最关键？

因为工具层决定了攻击成功后的损失上限。输入层的问题再多，Agent 也只能"想"；工具层的问题一旦出现，Agent 就能"做"。文件读写、网络请求、命令执行——这些是 Agent 改变物理世界的唯一通道。

工具风险的三角结构：

工具暴露范围  ×  工具权限粒度  ×  工具调用控制
     ↓               ↓               ↓
  能调用多少工具    每个工具能干什么   每次调用是否校验

Capability-based access control vs. 白名单：

白名单：只允许调用明确列出的工具。优点是简单清晰，缺点是工具一旦被加入就拥有全部能力。
Capability-based：每个工具的能力被分解为细粒度的能力单元（读文件 vs. 写文件 vs. 删除文件），调用时校验具体能力是否满足。优点是灵活，缺点是实现成本高。

2.4 输出层：看不见的损失

为什么输出层风险最容易被忽视？

因为输出层的问题往往不会立刻被发现。数据泄露、PII 暴露、跨用户串读——这些不会让系统崩溃，但会造成实质性的合规风险和用户信任损失。相比工具层的"灾难性失败"，输出层的问题更像慢性失血。

数据泄露的三条路径：

泄露路径	触发机制	检测难度	后果
无意泄露	Agent 在回答中主动输出了敏感信息	中等	隐私合规风险
诱导泄露	攻击者通过精心设计的提问套取敏感信息	高	定向数据泄露
跨用户泄露	Session 管理不当导致数据串读	低（工程问题）	严重隐私事故

2.5 多Agent系统：级联放大的风险网络

多Agent系统为什么风险更高？

单 Agent 的风险是线性的：输入 → 处理 → 输出，攻击路径清晰。多 Agent 的风险是网络的：Agent A 的输出是 Agent B 的输入，B 的输出又是 C 的输入——任何一个节点的错误都会被后续节点放大，且难以定位责任边界。

级联失败的四种模式：

模式	描述	触发条件	危害程度
无条件信任放大	上游错误被下游直接当作正确输入	缺乏结果可信度验证	高
错误逐级放大	每级 Agent 都会"补充"错误信息	多 Agent 协作链过长	极高
角色混淆	Agent 丢失边界，开始代理其他 Agent 的能力	多轮对话无角色锚定	中
恶意 Agent 注入	攻击者通过任务分发让恶意 Agent 参与协作	缺乏 Agent 身份验证	极高

Agent 间信任的正确设计原则：

1.每个 Agent 的输出必须携带可信度标记，下游 Agent 不能无条件接受

2.跨 Agent 调用必须有一次显式的"结果校验"步骤，不是自动信任

3.任何 Agent 的输出被用于关键决策前，必须经过独立验证 Agent 审查

4.调度器对任务分发路径有完整的审计记录

2.6 系统层：运维失守全盘皆输

系统层风险为什么占比最高（38条，46%）？

因为系统层不是 Agent 特有的安全问题，而是整个系统的工程实践问题。输入层、工具层、模型层可以设计得很安全，但如果运维层有漏洞，前面所有努力白搭。

三类核心系统风险：

A. 上下文与状态管理风险（6条） 上下文污染、状态残留、跨 Session 泄露——这些问题本质上是没有正确实现状态隔离。Session 之间的数据没有彻底清理，导致信息跨 Session 残留。这是最常见的跨用户数据泄露根因。

B. 沙箱与隔离失效（3条） 容器逃逸、权限配置错误、隔离突破——这些是 Agent 运行环境的安全边界问题。如果 Agent 能访问宿主机资源，工具层的白名单控制就形同虚设。沙箱失效是最难检测、最难修复的风险，因为它是系统层面的配置问题，不是在应用层加护栏能解决的。

C. 供应链风险（3条） 依赖投毒、模型 API 劫持、开源模型权重污染——这些是引入外部依赖时带入的风险。PyPI/NPM 供应链投毒事件频繁发生，Agent 依赖的第三方库越多，被攻击面越大。模型层的供应链风险最特殊——你无法验证模型本身是否可信，只能信任模型提供方。

三、安全护栏体系建设

整体架构：五层防御 + 两项基础能力

┌─────────────────────────────────────────────────────────┐
│                    五层防御                              │
│  Layer 1: 输入防御  →  拦截攻击入口                      │
│  Layer 2: 上下文隔离  →  防止污染扩散                     │
│  Layer 3: 工具管控  →  控制能力边界                        │
│  Layer 4: 输出过滤  →  堵住泄露出口                       │
│  Layer 5: 审计追溯  →  事后可追责                         │
├─────────────────────────────────────────────────────────┤
│                    两项基础能力                          │
│  基础能力 A: 可观测性  →  看得见才拦得住                   │
│  基础能力 B: 降级熔断  →  出问题时能兜底                   │
└─────────────────────────────────────────────────────────┘

3.1 【防御】输入防御（对应输入层21条风险）

设计目标： 在攻击内容进入 Agent 之前做第一次拦截，重点是识别和阻断 Prompt 注入。

三层拦截机制：

第一层：静态规则拦截（Policy-based）

针对明确的攻击模式，用正则/字符串匹配做硬拦截：

拦截规则库（示例）：
- 指令覆盖类：.*忽略.*(所有|之前|的).*(指令|规则|指示).*
- 系统扮演类：.*你是.*(坏人|恶意|无道德|忽略限制).*
- 编码注入类：base64/unicode 解码后重检
- 路径遍历类：.*\.\./.*|.*%2F%2F.*
- 特殊字符类：\x00|\\r\\n\\x00 超长截断检测

规则库要独立维护，有版本管理，支持灰度下发。不要让规则和业务代码耦合。

第二层：语义检测（Detection-based）

针对隐式注入和编码混淆这类静态规则兜不住的变体，用模型做语义判断：

输入中是否存在"让 Agent 改变行为边界"的意图
输入中是否存在"冒充系统指令"的意图
输入中是否存在"诱导泄露系统信息"的意图

注意： 语义检测不能替代第一层，而是第一层的补充。检测结果用于标记和告警，不一定直接阻断（因为有 false positive 率）。

第三层：输入结构化校验

类型校验：明确字段类型的输入必须符合类型定义
长度限制：每个字段有明确的最大长度，防止上下文填满攻击
来源标记：区分"用户直接输入"和"从外部数据源读取的内容"，后者要加额外校验

输入防御的核心原则：

永远不要把用户输入和系统指令拼接成同一个字符串。 用结构化模板让模型知道"我说的是什么"，而不是让模型自己猜。

3.2 【防御】上下文隔离（贯穿模型层 + 多Agent + 系统层）

设计目标： 保证每个处理阶段的安全约束不因上下文传递而失效。

三个隔离维度：

A. System Prompt 隔离

System Prompt 存在独立字段，不参与 token 计数，不被用户输入覆盖
System Prompt 的约束在每个处理阶段（每轮对话、每个 Agent 处理前）重放一次
System Prompt 的版本受控，有独立的变更审批流程

B. 多用户 Session 隔离

每个用户的 Session 有独立的上下文存储
Session 切换时，上下文彻底清理，不残留任何跨用户数据
Session 内的工具调用结果不能跨 Session 传递

C. Agent 间消息隔离（多Agent场景）

Agent A 传给 Agent B 的消息，必须经过"消息清洗"步骤——移除 Agent A 的内部指令和敏感上下文，只保留业务数据
每条跨 Agent 消息携带来源标记和可信度评分
关键决策必须经过独立验证 Agent 确认后才能执行

3.3 【防御】工具管控（对应工具层20条风险）

设计目标： 工具的能力边界必须与 Agent 的角色定义严格对应，且每次调用都要校验。

Capability-based 访问控制模型：

工具能力矩阵（示例）：

工具: file_read
├── Capability: read_file
│   ├── Constraint: path ∈ workspace_whitelist
│   ├── Constraint: file_size < 10MB
│   └── Output: 文件内容（截断至前5KB + summary）
│
工具: http_request
├── Capability: get_request
│   ├── Constraint: url_domain ∈ allowed_domains
│   ├── Constraint: timeout = 5s
│   └── Output: response（前2KB）
│
工具: sql_query
├── Capability: read_query
│   ├── Constraint: sql 必须是 SELECT
│   ├── Constraint: 无 JOIN 跨表
│   ├── Constraint: 结果集 < 100 rows
│   └── Output: 结果集（脱敏处理）

工具管控的四项强制规则：

1.白名单制：不在白名单的工具，一律不可调用

2.权限最小化：每个工具只暴露完成业务目标所需的最小能力

3.运行时校验：每次工具调用前，校验参数是否满足该工具的所有 Constraint

4.结果截断：工具返回的内容必须有长度限制，防止上下文污染

危险操作的二次确认机制：

对于高风险工具（删除文件、执行命令、转账等），引入 human-in-the-loop：

Agent 发起调用请求 → 护栏校验参数 → 参数校验通过后，不是直接执行，而是生成确认请求发给用户
用户确认 → 执行 → 返回结果
用户拒绝 → 终止操作 → 记录审计日志

3.4 【防御】输出过滤（对应输出层12条风险）

设计目标： 在 Agent 的输出到达用户或下游系统之前，做最后一次安全检查。

三层过滤机制：

第一层：敏感信息检测

PII 检测：身份证号、银行卡号、手机号、邮箱——用正则 + 实体识别双重检测
凭证检测：API key 格式、token 格式、私钥格式
内部信息检测：内网 IP 段、内部域名、文档路径模式

第二层：内容合规校验

输出内容是否涉及违规领域（仇恨、暴力、色情、金融欺诈）
如果有结构化输出（JSON、表格），校验 schema 是否符合预期
输出中引用的外部链接、文档是否真实存在（针对引用幻觉）

第三层：泄露路径阻断

诱导性输出检测：单次输出没问题，但要看对话历史中是否有多次"套取信息"的模式
跨用户数据隔离检查：当前输出的数据，是否属于当前用户有权访问的范围

输出过滤的降级策略：

检测结果	行为
明确检测到敏感信息	脱敏后输出，触发安全告警
疑似敏感信息	标记但不阻断，通知 human-in-the-loop
内容合规违规	拒绝输出，返回"该内容不符合安全规范"
引用幻觉	标注信息来源不可信，不拒绝但加免责声明

3.5 【防御】审计追溯

设计目标： 所有安全相关操作必须可追溯，出了事能定位到人、时间、原因。

审计日志的必填字段：

每条审计日志：
- 时间戳（精确到毫秒）
- 操作者身份（用户ID / Agent ID）
- 操作类型（输入拦截 / 工具调用 / 输出过滤 / 护栏触发）
- 操作内容（输入内容摘要 / 工具名称+参数 / 输出内容摘要）
- 判定结果（放行 / 拦截 / 标记）
- 判定依据（触发了哪条规则）
- 上下文ID（关联同一会话的所有操作）

重点审计的场景（每个都要单独记录）：

工具调用：每次调用记录 tool_name、参数、调用者、结果
护栏触发：每次触发记录触发的规则、触发时的输入/上下文、最终处理结果
权限提升：任何超出正常权限的操作都要单独记录
降级行为：护栏触发后的降级处理路径

3.6 【基础能力】可观测性

设计目标： 看得见才拦得住。安全护栏如果不能被监控，就等于没有护栏。

三个核心监控指标：

指标	含义	告警阈值
护栏触发率	正常请求中被护栏拦截的比例	过高说明被攻击频率上升或规则过严
False Positive 率	被拦截的请求中，真实恶意请求的比例	过低说明大量正常请求被误拦截
工具调用异常率	单用户短时间内的工具调用次数	过高说明可能有人在探测工具边界

告警分级：

P0 告警（立即处理）：
- 跨用户数据泄露检测到
- 权限逃逸检测到
- 非授权执行命令

P1 告警（2小时内处理）：
- Prompt 注入被触发
- 敏感信息泄露被触发
- 工具调用异常率超过阈值

P2 告警（日常处理）：
- 护栏触发率异常波动
- 规则命中率分布变化
- 监控盲区发现（新工具未覆盖）

3.7 【基础能力】降级与熔断

设计目标： 护栏触发后的行为决定系统的韧性和用户体验。拒绝服务比误放行安全，但完全拒绝会让系统不可用。

降级策略分层：

常态（0级）：护栏正常运作，所有请求正常处理

轻度降级（1级）：护栏触发后，返回脱敏/拒绝版本，继续服务
  → 示例：检测到输出包含 PII，脱敏后返回，不阻断

中度降级（2级）：某些高风险工具被禁用，基础功能继续服务
  → 示例：检测到工具滥用模式，禁用高风险工具，降级到只读模式

重度降级（3级）：Agent 暂停服务，等待 human-in-the-loop
  → 示例：连续触发 P0 告警，Agent 暂停，通知管理员

熔断（4级）：Agent 完全不可用，需要人工介入才能恢复
  → 示例：检测到沙箱失效，Agent 进程终止，需要安全团队排查

熔断触发条件：

P0 告警连续触发 3 次 → 触发重度降级
审计日志链路断裂 → 触发重度降级
检测到沙箱失效 → 直接熔断

降级时的用户交互设计：

不要让用户感知到"护栏"的存在——返回的是业务语言，不是技术报错
拒绝时给出清晰的替代路径："当前无法执行此操作，你可以……"
不要静默失败——用户发了一个请求，没有任何返回，这是最差的用户体验

3.8 整体架构

                    用户输入
                        │
                        ▼
              ┌─────────────────┐
              │ Layer 1 输入防御  │  ← 静态规则 + 语义检测 + 结构化校验
              └────────┬────────┘
                       │ 通过
                       ▼
              ┌─────────────────┐
              │Layer 2 上下文隔离 │  ← System Prompt 隔离 + Session 隔离
              └────────┬────────┘   + Agent 间消息清洗
                       │ 干净上下文
                       ▼
              ┌─────────────────┐
              │ Layer 3 工具管控  │  ← 白名单 + Capability-based + 二次确认
              └────────┬────────┘
                       │ 调用成功
                       ▼
              ┌─────────────────┐
              │ Layer 4 输出过滤  │  ← PII检测 + 合规校验 + 泄露路径阻断
              └────────┬────────┘
                       │ 通过
                       ▼
                    用户响应
                        │
                        ▼
              ┌─────────────────┐
              │ Layer 5 审计追溯  │  ← 全量审计 + 可观测性监控
              └─────────────────┘
                        │
                        ▼
              ┌─────────────────┐
              │基础能力B 降级熔断  │  ← 四级降级 + 熔断条件
              └─────────────────┘