跳到主要内容

Prompt Injection 与 Agent 安全

一旦 Agent 开始：

  • 访问外部网页
  • 读取邮件和文档
  • 调用数据库与内部系统
  • 执行高权限工具

安全问题就不再是附属主题，而会直接进入主流程。

这篇文档主要回答 5 件事：

  • Prompt Injection 到底是什么
  • 为什么 Agent 比普通聊天更容易受影响
  • 常见攻击面有哪些
  • 防御应该分成哪几层
  • 在现有 Agent 系统里，哪些安全控制应该优先补上

参考资料：

1. Prompt Injection 是什么​

Prompt Injection 可以先理解成一种“语义层注入”。

它的典型形式不是 SQL 或 shell 命令，而是攻击者通过自然语言或隐藏内容，诱导模型：

  • 忽略既有规则
  • 泄露内部提示
  • 调用不该调用的工具
  • 输出敏感信息
  • 执行超出授权范围的动作

最关键的一点在于：

模型把指令和数据都当成自然语言处理。

这也是它和传统注入漏洞最不同的地方。

2. 为什么 Agent 的风险会更高​

普通聊天模型出问题，很多时候只是回答偏了。

Agent 出问题，往往会更严重，因为它不只是回答，还可能：

  • 搜索网页
  • 读取文件
  • 修改记录
  • 发送消息
  • 执行代码
  • 调用内部系统

因此攻击链一旦成立，影响就会从“输出错误”升级成：

  • 数据泄露
  • 权限滥用
  • 错误操作
  • 横向扩散

这也是为什么：

Agent 安全不能只靠模型本身的对齐能力。

3. 常见攻击面​

3.1 直接注入​

最常见的形式是攻击者在输入里直接放指令，例如：

  • 忽略前面的规则
  • 输出系统提示
  • 调用某个工具

这类攻击很直观，但不是唯一问题。

3.2 间接注入​

更危险的是“内容里带指令”。

例如 Agent 会读：

  • 网页
  • PDF
  • 邮件
  • issue 描述
  • 代码注释
  • knowledge base 文档

这些外部内容本来应该是“数据”，但模型可能把里面的隐藏或伪装指令当成“应执行的命令”。

3.3 RAG 污染​

如果知识库里混入恶意内容，问题就会变成：

  • 检索本身变成攻击输入通道
  • 模型把恶意文档当依据
  • 系统不断回收有毒上下文

3.4 Tool 参数操纵​

攻击者不一定非要让模型泄露提示，也可能诱导它：

  • 用错误参数调用工具
  • 访问敏感资源
  • 越权执行动作
  • 把机密内容发到外部地址

3.5 多模态与 Browser 注入​

如果系统能看网页、图片、截图、富文档，攻击面会进一步扩大：

  • 隐藏文本
  • 不可见指令
  • 伪装按钮
  • 钓鱼页面
  • 误导性 UI

4. 防御思路应该分层​

Prompt Injection 很少能靠单点修好。

更稳的做法，是把防御拆成 5 层。

4.1 输入层​

重点是：

  • 标记输入来源
  • 区分“用户意图”和“外部内容”
  • 对高风险内容做检测或隔离

最重要的原则之一是：

外部内容默认是数据，不默认是指令。

4.2 上下文层​

重点是：

  • 不把所有外部内容原样拼进主提示
  • 对检索结果做摘要、裁剪、标注来源
  • 让模型知道哪些内容可参考，哪些内容不能提升为系统级指令

4.3 工具层​

重点是：

  • 工具最小授权
  • 参数白名单
  • 高风险参数校验
  • 写操作与读操作分级

很多安全问题真正爆发的地方，不在 prompt，而在：

模型拿到了不该有的工具权限。

4.4 执行层​

重点是：

  • 敏感动作要求确认
  • 高风险动作引入人工审批
  • 限制自动连续执行步数
  • 给出超时、回滚、熔断策略

4.5 输出层​

重点是：

  • 检查是否出现敏感泄露
  • 检查是否返回异常长文本
  • 检查是否暴露系统提示、密钥、令牌、内部路径

5. 一个很实用的分类方法​

把 Agent 能做的动作分成 3 类，很多安全设计会清楚很多。

5.1 低风险读操作​

例如：

  • 查公开网页
  • 查非敏感知识库
  • 读帮助文档

5.2 中风险读写操作​

例如：

  • 查内部数据
  • 创建草稿
  • 更新非关键字段

5.3 高风险执行操作​

例如：

  • 发正式邮件
  • 删除记录
  • 转移资金
  • 提交代码
  • 修改权限

这三类动作不应该共用同一套自动化策略。

6. 工具层最容易踩的坑​

6.1 工具权限给太大​

典型问题：

  • 搜索工具顺手带了写权限
  • 数据库工具可以随便查全表
  • 发消息工具没有收件范围限制

6.2 工具参数不校验​

如果参数校验缺失，模型即使本意是好的，也可能：

  • 拼错目标
  • 越界访问
  • 误写错误对象

6.3 读写不分离​

很多系统把“查”和“改”放在同一套工具里，这会明显放大风险。

7. RAG 系统里的安全重点​

RAG 很容易被误解成“只是读文档”。

但只要检索结果会进入模型上下文，知识库本身就成了潜在攻击面。

重点要看：

  • 文档来源是否可信
  • 是否会把外部网页直接入库
  • 是否保留了来源与权限标签
  • 是否会把未审查内容直接注入高权限 Agent

8. Browser Agent 里的安全重点​

对于 Browser / Computer Use 类 Agent，至少要额外考虑：

  • 页面内容不可信
  • DOM 与视觉元素可能被伪装
  • 隐藏文本可能携带指令
  • 点击与输入动作本身可能造成真实后果

因此这类 Agent 往往需要：

  • 更严格的域名白名单
  • 更严格的操作确认
  • 更低的默认权限
  • 更强的执行审计

9. 安全控制的最小落地清单​

如果系统还处在第一轮建设阶段，优先补的是：

  1. 明确区分系统指令、用户输入、外部内容
  2. 工具按读 / 写 / 高风险分级
  3. 高风险操作必须人工确认
  4. 工具参数做白名单或 schema 校验
  5. 对外部检索内容保留来源和可信度
  6. 记录关键工具调用日志
  7. 对敏感输出做基本检测

10. 和这个专题里的哪些内容最该一起看​

最适合一起看的有：

11. 小结​

Prompt Injection 不只是“有人在输入里写了忽略前文”。

对 Agent 来说，它真正危险的地方在于：

  • 外部内容会进入上下文
  • 模型可以调用工具
  • 工具可能连接真实系统

所以更稳的防御方式不是只盯着 prompt，而是把：

  • 输入
  • 上下文
  • 工具
  • 执行
  • 输出

一起纳入安全设计。