AI安全攻防与治理之十三：如何设计一套大模型应用攻防演练，从资产盘点到风险复现

很多企业开始做大模型安全测试时，第一步通常是收集一批越狱提示词：

• 忽略之前的指令；
• 进入开发者模式；
• 假设没有任何限制；
• 要求输出系统提示词；
• 用角色扮演绕过安全规则。

这些测试可以作为起点，但不能代表一套完整的大模型应用攻防演练。

因为企业真正需要防护的，不只是模型输出内容，还包括：

• 用户和租户数据；
• RAG 知识库；
• 会话记忆；
• 工具和插件；
• 业务 API；
• 生产数据库；
• 云平台和代码仓库；
• 自动化审批、退款、发信和配置变更。

因此，一套成熟的演练目标应当是：

在模拟真实业务和真实攻击条件的前提下，验证攻击者能否影响模型判断、突破数据和权限边界，最终改变业务系统状态。

可以将整个演练概括为：

资产盘点
  ↓
威胁建模
  ↓
信任边界识别
  ↓
攻击用例设计
  ↓
隔离环境验证
  ↓
风险复现与证据保全
  ↓
整改、回归与持续监控

一、先明确演练目标，而不是先写提示词

攻防演练开始前，必须先明确演练要回答什么问题。

常见目标包括：

1. 模型行为安全

• 是否会泄露系统提示词；
• 是否会被直接或间接提示词注入；
• 是否会生成违规或危险内容；
• 是否会把外部文档当成系统指令；
• 是否会在多轮对话中逐步放宽边界。

2. 数据安全

• 是否存在跨用户或跨租户访问；
• RAG 是否会检索越权文档；
• 向量库和会话记忆是否隔离；
• 敏感字段是否被最小化；
• 日志、缓存和备份是否残留数据。

3. 工具和权限安全

• 模型是否可以调用不应调用的工具；
• 工具参数是否可以被篡改；
• 服务端是否独立校验权限；
• 是否可以绕过二次确认和审批；
• 是否可以通过多个低风险工具组合出高风险结果。

4. 业务安全

• 是否能修改订单、工单、客户等级或配置；
• 是否能发起退款、付款或转账；
• 是否能对外发送敏感信息；
• 是否能执行生产环境命令；
• 是否能影响真实业务决策。

如果没有清晰目标，演练很容易变成：

找到几个模型回答异常的问题
→ 截图
→ 标记为越狱
→ 演练结束

这对企业实际风险的解释能力非常有限。

二、第一步：资产盘点

大模型应用的资产远不止模型 API。

建议至少盘点以下对象。

1. 模型资产

• 基础模型；
• 微调模型；
• 嵌入模型；
• 重排序模型；
• 内容安全模型；
• 模型版本；
• 部署区域；
• 模型服务商；
• 推理接口；
• 备用模型和降级模型。

2. 提示词与上下文资产

• 系统提示词；
• 开发者指令；
• Agent 规划模板；
• 工具描述；
• 输出格式模板；
• 安全规则；
• 会话记忆；
• 长期用户画像；
• Prompt 缓存。

3. 数据与知识资产

• 原始文件；
• 文档解析服务；
• RAG 知识库；
• 向量数据库；
• 搜索索引；
• 文档元数据；
• 权限标签；
• 训练和评测数据；
• 日志、缓存和备份。

4. 工具与业务资产

• 内部 API；
• 数据库查询；
• CRM；
• 工单系统；
• 财务和支付接口；
• 邮件和消息系统；
• 代码仓库；
• 云平台；
• 运维平台；
• 生产环境脚本；
• 第三方插件。

5. 身份和权限资产

• C 端用户；
• B 端客户；
• E 端员工；
• 管理员；
• 服务账号；
• Agent 身份；
• API Key；
• OAuth 应用；
• 云角色；
• 供应商运维账号。

6. 监控与审计资产

• API 网关；
• WAF；
• DLP；
• SIEM；
• EDR；
• 链路追踪；
• 工具调用日志；
• 业务审计日志；
• 告警和响应平台。

资产盘点的核心不是列出产品名称，而是明确：

谁可以访问它
它可以访问什么
它会把数据传给谁
出现异常后能否追踪

三、第二步：绘制数据流和信任边界

演练必须建立在真实架构上。

一个常见的 AI 应用数据流可能是：

用户输入
   ↓
前端和 API 网关
   ↓
身份认证与租户识别
   ↓
输入检测与上下文编排
   ↓
RAG 检索和会话记忆
   ↓
模型推理
   ↓
工具网关
   ↓
业务 API、数据库和云平台
   ↓
输出、日志、缓存和审计

在这条链路上，要标记信任边界：

• 用户输入是否可信；
• 上传文档是否可信；
• 知识库内容是否可信；
• 工具返回结果是否可信；
• 模型输出是否可信；
• Agent 是否拥有独立身份；
• 服务端是否重新执行权限校验；
• 哪些系统具有真实业务副作用。

尤其要找出以下危险连接：

不可信输入 → 高权限工具
低权限用户 → 共享管理员身份
RAG 文档 → 系统指令
模型输出 → 生产 API
工具结果 → 无过滤上下文
缓存内容 → 跨用户复用

这些位置通常比模型本身更值得优先测试。

四、第三步：建立威胁模型

可以从几个角色出发：

1. 外部匿名用户

目标可能是：

• 获取内部提示词；
• 访问其他用户数据；
• 诱导客服 Agent 违规操作；
• 利用上传文件注入恶意指令；
• 试探系统工具和内部流程。

2. 普通注册用户

目标可能是：

• 越权访问其他订单；
• 绕过退款或售后限制；
• 利用多轮对话获取更多上下文；
• 污染公开知识库；
• 组合低风险工具完成数据外传。

3. 低权限员工

目标可能是：

• 访问其他部门文档；
• 读取高密级知识库；
• 调用未授权内部工具；
• 导出客户或员工数据；
• 利用 Agent 横向访问业务系统。

4. 恶意供应商或外部内容提供方

目标可能是：

• 上传被投毒的文档；
• 影响 RAG 回答；
• 插入工具调用指令；
• 污染训练、评测或标注数据；
• 获取其他客户信息。

5. 被盗用的服务账号

目标可能是：

• 利用 Agent 的高权限工具；
• 批量查询或导出；
• 执行生产变更；
• 隐藏真实操作者；
• 绕过人工审批。

威胁模型最终要形成：

攻击者
→ 可控制的输入
→ 可影响的模型行为
→ 可调用的工具
→ 可突破的权限
→ 可能造成的业务后果

五、第四步：设计高价值攻击用例

高价值用例不能只写一句提示词，而应描述完整场景。

建议每条用例至少包含：

示例：间接提示词注入导致越权退款

场景：

• 客服 Agent 支持订单查询和退款申请；
• 用户可以上传售后凭证图片；
• 图片会经过 OCR；
• OCR 内容会进入模型上下文；
• 退款接口由 Agent 调用。

攻击步骤：

上传含恶意指令的图片
   ↓
OCR 识别出恶意文字
   ↓
模型将文档内容当成任务指令
   ↓
模型尝试查询其他订单
   ↓
模型把自然语言“确认”视为退款授权
   ↓
调用退款工具
   ↓
观察服务端是否校验订单归属和确认凭证

风险是否成立，不取决于模型是否理解了恶意文字，而取决于：

• 是否读到了越权数据；
• 是否生成了越权工具调用；
• 工具网关是否拦截；
• 业务服务是否独立校验；
• 是否改变了真实退款状态。

六、攻击用例应覆盖哪些类别

1. 输入与提示词注入

• 直接提示词注入；
• 间接文档注入；
• 网页和邮件注入；
• 多轮对话注入；
• 多语言和编码绕过；
• 图片、音频和二维码注入；
• 工具返回结果注入。

2. 系统提示词与配置泄露

• 套取系统提示词；
• 提取工具名称和参数；
• 暴露内部数据源；
• 暴露审批逻辑；
• 暴露调试配置；
• 推断模型和插件架构。

3. RAG 与知识库安全

• 跨租户检索；
• 文档权限撤销后仍能召回；
• 知识库投毒；
• 版本冲突；
• 低可信文档覆盖正式制度；
• 向量索引残留；
• 过量字段返回。

4. Agent 与工具调用

• 未授权工具调用；
• 工具参数篡改；
• 高风险工具绕过确认；
• 状态机绕过；
• 工具组合攻击；
• 批量调用；
• 重复执行；
• 通过外部邮件和文件实现数据外传。

5. 身份和多租户

• 用户冒充管理员；
• 会话串线；
• 缓存跨租户复用；
• 服务账号权限过大；
• Agent 使用统一管理员身份；
• 供应商运维越权；
• 离职账号仍可访问。

6. 输出与业务执行

• 敏感字段泄露；
• 模型输出直接进入数据库；
• 自动生成 SQL；
• 自动执行生产命令；
• 自动发信；
• 自动审批；
• 错误退款、付款和配置变更。

七、第五步：准备隔离演练环境

大模型攻防演练应尽可能在可控环境中完成。

建议准备：

1. 测试租户

使用专门的演练租户，避免与真实客户数据混用。

2. 脱敏和模拟数据

模拟：

• 客户；
• 订单；
• 合同；
• 退款；
• 供应商；
• 员工；
• 生产配置。

不要为了追求“真实效果”直接将真实客户数据放进演练环境。

3. 受控工具

工具应使用：

• 测试 API；
• 沙箱数据库；
• 模拟付款；
• 可回滚配置；
• 只允许有限范围的脚本；
• 防止访问真实生产秘密。

4. 完整日志

至少记录：

• 原始输入；
• 模型版本；
• 系统提示词版本；
• 检索结果；
• 工具调用；
• 权限判定；
• 业务结果；
• 告警和拦截；
• 测试人员和时间。

5. 清理和回滚机制

演练前确认：

• 可以删除测试数据；
• 可以回滚工具状态；
• 可以撤销测试权限；
• 可以恢复知识库；
• 可以清理缓存和会话；
• 可以关闭临时接口。

八、第六步：执行演练并保全证据

演练执行时，不应只记录“成功”或“失败”。

每次测试都要保存：

测试时间
测试账号
测试租户
输入内容
上传文件
会话 ID
模型版本
检索文档
工具调用
权限结果
业务状态
日志和告警

证据应能够复现完整链路：

攻击入口
→ 输入载体
→ 模型响应
→ 检索或工具调用
→ 权限控制
→ 业务执行
→ 最终结果

例如，不能只写：

模型被越狱，存在高风险。

应写成：

普通客户账号通过上传含恶意文本的图片，诱导客服 Agent 生成客户资料查询请求。工具网关未验证目标客户与当前账号的对象归属，查询接口返回了其他客户的联系方式。模型将返回结果输出给攻击者，构成跨对象数据越权。

这才是能够推动整改的结论。

九、如何给风险定级

风险定级不应只依据“模型是否被绕过”。

建议至少考虑：

• 攻击门槛；
• 是否需要登录；
• 是否需要特定文件或账号；
• 是否可以稳定复现；
• 是否影响一个用户还是多个租户；
• 是否涉及敏感数据；
• 是否可以调用高风险工具；
• 是否改变真实业务状态；
• 是否可以批量利用；
• 是否容易被发现；
• 是否存在审计证据；
• 是否可以撤销和恢复。

可以将结果分为：

内容层风险
数据层风险
权限层风险
工具层风险
业务执行风险
生产环境风险

例如：

• 输出一句违规内容，可能是内容层风险；
• 返回其他客户资料，是数据和权限层风险；
• 诱导退款接口执行，是业务执行风险；
• 执行生产命令，是生产环境高风险。

十、整改要优先修复哪些控制点

1. 将授权移出模型

模型不应独立判断：

• 用户身份；
• 租户归属；
• 对象权限；
• 审批状态；
• 交易确认。

这些应由服务端和确定性业务规则完成。

2. 工具最小权限

不要给 Agent：

execute_any_action()

应拆分为：

query_order_status()
reate_refund_request()
submit_refund_for_review()

3. 高风险操作增加独立确认

退款、付款、删除、发信、生产变更等操作，应具备：

• 二次确认；
• 一次性凭证；
• 审批人；
• 金额和范围限制；
• 幂等控制；
• 完整审计。

4. 建立输入、检索、工具和输出四道控制

输入层：识别不可信内容
检索层：执行权限和来源过滤
工具层：校验能力、参数和身份
输出层：脱敏、阻断和审计

5. 修复后必须回归

回归测试应覆盖：

• 原始攻击用例；
• 同义改写；
• 多语言版本；
• 多轮对话；
• 不同用户角色；
• 不同租户；
• 不同模型版本；
• 不同工具组合；
• 不同缓存和会话状态。

十一、演练后的复盘与持续机制

大模型攻防不是一次性项目。

每次以下变化都应触发重新评估：

• 更换基础模型；
• 修改系统提示词；
• 新增工具；
• 扩大工具权限；
• 接入新的知识库；
• 开启网页抓取；
• 增加文件和多模态输入；
• 调整租户或角色；
• 修改缓存和记忆策略；
• 接入新的供应商；
• 将 Agent 推向生产。

演练结果应沉淀为：

• AI 资产清单；
• 攻击用例库；
• 风险登记册；
• 修复任务；
• 回归测试集；
• 监控和告警规则；
• 事件响应手册；
• 业务方风险接受记录。

结语

一套真正有效的大模型应用攻防演练，不是让模型回答几句违规内容，也不是收集越狱截图。

它应该完成一条完整验证链：

资产盘点
→ 数据流和信任边界
→ 威胁建模
→ 攻击用例
→ 隔离复现
→ 证据保全
→ 风险定级
→ 工程整改
→ 回归验证
→ 持续监控

最终要回答的不是：

模型会不会被诱导？

而是：

当模型被诱导之后，企业的身份、数据、权限、工具和业务控制，是否仍然能够阻止攻击继续向下游扩散？

只有从资产盘点一直做到风险复现和业务影响验证，AI 红队才真正成为企业安全体系的一部分。