目录
[2.1 输入层：攻击者的主战场](#2.1 输入层：攻击者的主战场)
[2.2 模型层：护栏的盲区](#2.2 模型层：护栏的盲区)
[2.3 工具层：Blast Radius 的边界](#2.3 工具层：Blast Radius 的边界)
[2.4 输出层：看不见的损失](#2.4 输出层：看不见的损失)
[2.5 多Agent系统：级联放大的风险网络](#2.5 多Agent系统：级联放大的风险网络)
[2.6 系统层：运维失守全盘皆输](#2.6 系统层：运维失守全盘皆输)
[3.1 【防御】输入防御（对应输入层21条风险）](#3.1 【防御】输入防御（对应输入层21条风险）)
[3.2 【防御】上下文隔离（贯穿模型层 + 多Agent + 系统层）](#3.2 【防御】上下文隔离（贯穿模型层 + 多Agent + 系统层）)
[3.3 【防御】工具管控（对应工具层20条风险）](#3.3 【防御】工具管控（对应工具层20条风险）)
[3.4 【防御】输出过滤（对应输出层12条风险）](#3.4 【防御】输出过滤（对应输出层12条风险）)
[3.5 【防御】审计追溯](#3.5 【防御】审计追溯)
[3.6 【基础能力】可观测性](#3.6 【基础能力】可观测性)
[3.7 【基础能力】降级与熔断](#3.7 【基础能力】降级与熔断)
[3.8 整体架构](#3.8 整体架构)
一、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 降级熔断 │ ← 四级降级 + 熔断条件
└─────────────────┘