TL;DR

  • 随着 AI Agent 获得越来越多的权限，Prompt 注入攻击成为最严重的安全威胁之一
  • OpenAI 公开的 Agent 安全防护机制揭示了一个关键原则：安全不能依赖单一防线，而需要分层防御
  • 本文深度解析指令隔离、行为约束、数据分类等关键技术，以及如何在生产环境中实施这些防护

Prompt 注入：Agent 时代的 SQL 注入

如果说 SQL 注入是 Web 1.0 时代最严重的安全漏洞，那么 Prompt 注入就是 Agent 时代的 SQL 注入。

什么是 Prompt 注入？

Prompt 注入是一种攻击技术，攻击者通过精心构造的输入，覆盖或绕过 AI 系统的原始指令。

什么是 Prompt 注入？

经典攻击示例

Simon Willison 在 2022 年首次系统描述了 Prompt 注入的本质：攻击者通过在输入中嵌入恶意指令，让 AI 在处理自身任务的同时执行攻击者的目标。这与 SQL 注入的逻辑完全一致——都是通过用户输入的合法语法结构，在系统内部劫持执行路径。

以下是三种最典型的攻击形式：

指令覆盖是最直接的形态。攻击者在用户输入中插入类似 忽略之前的所有指令，现在执行以下操作…… 的内容，试图让 AI 抛弃系统指令。在 SQL 注入中，这相当于在查询字符串中拼接 DROP TABLE users;。OpenAI 的指令架构通过将系统指令锁定在独立消息层来防御此类攻击——用户输入的语义再丰富，也无法修改系统指令本身。

上下文污染更为隐蔽。攻击者不直接覆盖指令，而是在多轮对话中逐步植入新的上下文，让 AI 在不知不觉中调整自己的行为边界。例如，先让 AI 认同某个”测试环境”的设定，再在后续对话中利用这个设定绕过安全限制。这相当于在 SQL 注入中使用注释和分步查询逐步改变查询意图。

间接注入利用 AI 与外部数据源的交互。当 AI 被要求总结一封邮件、阅读一个网页、或分析一份文档时，如果这些外部内容包含恶意指令，就构成了间接注入——攻击者不需要直接与 AI 对话，只需让 AI 读取攻击者控制的内容即可。这类攻击最难防御，因为攻击向量来自 AI 认为可信的外部数据源。

💡 Key Insight

Prompt 注入之所以比 SQL 注入更难防御，根本原因在于自然语言的表达能力远超结构化查询——攻击者可以在完全合法的文本中嵌入指令，而 AI 没有可靠的方式区分”用户在描述任务”和”用户在构造攻击”。

为什么 Prompt 注入特别危险？

特性 SQL 注入 Prompt 注入
攻击目标 数据库 AI 的决策逻辑
攻击复杂度 需要了解 SQL 语法 只需自然语言
攻击范围 数据泄露/破坏 任意操作（发邮件、转账、删数据）
检测难度 相对容易（SQL 关键字） 非常困难（自然语言变化多端）
防御成熟度 成熟（参数化查询） 仍在探索

关键问题：当 Agent 拥有发邮件、操作文件、调用 API 的权限时，Prompt 注入的破坏力远超 SQL 注入。

攻击面分析：Agent 面临的安全威胁

Agent 系统面临的 Prompt 注入攻击有多种形式：

指令覆盖攻击

攻击方式：直接覆盖系统指令。

危险等级：🔴 极高

上下文污染攻击

攻击方式：通过多轮对话逐步改变 AI 的行为。

危险等级：🟡 高

数据泄露诱导

攻击方式：诱导 AI 泄露敏感信息。

危险等级：🟡 高

社会工程攻击

攻击方式：利用 AI 的”帮助性”绕过限制。

危险等级：🟠 中高

间接注入攻击

攻击方式：通过外部数据源注入恶意指令。

危险等级：🔴 极高（难以检测）

分层防御架构：从输入到输出

OpenAI 的安全设计采用分层防御策略——多层防护，每层都有不同的保护重点。

分层防御架构：从输入到输出

核心原则：即使一层被突破，还有其他层保护。

💡 Key Insight

分层防御的核心价值不在于每一层有多强大，而在于纵深——当攻击者突破一层后，面对的是完全不同的安全机制和环境，需要重新组织攻击资源。

指令隔离：系统与用户的边界

核心问题：如何防止用户输入覆盖系统指令？

指令架构

指令架构的核心问题是：如何在用户输入与系统指令之间建立清晰的边界？OpenAI 的方案是三层设计原则。

结构化的消息格式是第一层。系统指令、用户输入、AI 响应各自封装在独立的消息对象中，每个对象有明确的角色标识（system / user / assistant）。这与 naive 的字符串拼接方案截然不同——后者将所有文本混在一个 prompt 中，攻击者只需找到正确的插入位置即可覆盖指令。结构化格式让攻击者面对的不再是”文本覆盖”，而是”对象注入”，后者的难度高出一个数量级。

系统指令的不可变性是第二层。系统指令在架构上被设计为不可被覆写的——即使攻击者构造的输入在语义层面完全合理，也无法触发系统指令的重新解析或替换。实现上，这通常意味着系统指令在每次推理开始时被锁定，推理过程中不会因为输入内容的变化而重新加载。

视觉隔离（UI 层）是第三层防线，也是用户体验层面的保障。OpenAI 的界面明确区分了系统指令展示区（不可编辑）和用户输入区，这种视觉分隔本身就是一种防御信号——它让用户清楚意识到”这是系统告诉我的”和”这是我告诉系统的”之间的本质差异。攻击者如果试图通过用户输入模拟系统指令，在界面上就会被立即识别为不匹配。

指令架构

架构设计要点：

  • 系统指令（System Prompt）位于独立的消息层，不与用户输入混合
  • 用户输入经过语义分析后，与系统指令在不同的上下文中处理
  • 指令优先级通过结构化格式显式表达，而非依赖位置

技术实现

结构化的消息格式

系统指令的不可变性

视觉隔离（UI 层）

在界面上明确区分系统指令和用户输入：

技术实现

行为约束：危险操作的白名单

核心问题：即使 Prompt 被注入，如何限制 AI 能执行的操作？

权限模型

权限模型基于最小权限原则（Principle of Least Privilege）：Agent 只应获得完成特定任务所需的最小权限集，而非全权访问。

模型组成：

  • 角色定义：为不同任务类型定义独立角色，每个角色有明确的功能边界
  • 权限颗粒度：细化到单个操作（如 file.read 而非 file.*）
  • 权限继承限制：父级权限不自动传递给子任务，防止权限扩散

最小权限原则在 Agent 系统中的含义远比传统软件工程更复杂。传统应用的权限通常静态分配给用户，而 Agent 的权限需要动态地与当前任务上下文匹配——同一个 Agent 实例，在处理邮件汇总任务时应该只能读取消极目录，在处理文件整理任务时才能操作工作区文件。这种动态权限绑定的实现，通常依赖于任务启动时由权限服务颁发的临时凭证，而非将权限硬编码在 Agent 的系统指令中。

白名单机制

白名单机制是行为约束的核心实现——明确列出允许执行的操作，其余一概拒绝。

操作白名单

预定义 Agent 可调用的工具和 API 范围。未经显式允许的操作直接拒绝，不进入模型推理流程。这与聊天机器人的”尽量回答”逻辑形成鲜明对比——Agent 的默认行为是拒绝，而非尝试。

参数验证

即使操作在白名单内，参数也需通过严格校验。例如：文件删除操作需验证路径是否在允许目录内，邮件发送需验证收件人是否在联系人白名单中。白名单解决的是”能不能做”的问题，参数验证解决的是”做到什么程度”的问题——两者缺一不可。

敏感操作确认

对于高风险操作（如转账、删库、发送外部邮件），引入人工确认步骤或二次验证，而非仅依赖 AI 自主决策。这是最后一道人为防线——即使前两层全部失效，高风险操作的物理执行仍掌握在人手中。

数据分类：敏感信息的访问控制

核心问题：如何防止 AI 泄露敏感数据？

数据分类框架

数据分类框架

💡 Key Insight

数据分类不仅是安全措施，更是产品决策——明确定义哪些数据可用于 AI 上下文，决定了 Agent 能”知道”什么、不能”知道”什么，从源头降低泄露风险。

技术实现

自动数据分类

基于内容语义和元数据特征，系统自动判定数据敏感等级。OpenAI 的实现中，这通常由专门的分类模型完成，在数据进入 AI 上下文之前完成标记。分类结果直接决定数据的后续处理路径——高敏感数据即使在用户明确要求下也可能被拦截，而非仅做脱敏处理。

数据脱敏

对于中等敏感度的数据，系统在将其送入 AI 上下文前执行脱敏处理——移除或替换直接标识符、泛化精确数值、过滤高风险实体。脱敏的目标不是让数据完全失去价值，而是让 AI 能获得处理任务所需的信息，同时失去还原原始敏感数据的能力。

访问控制策略

基于数据分类结果，Agent 的数据访问权限被动态约束。低敏感数据可以在多个任务间共享；高敏感数据则被锁定在特定任务的上下文中，即使 Agent 本身不被销毁，高敏感数据也不会进入其他任务的可见范围。

实战案例：ChatGPT 的安全设计

ChatGPT 的安全机制是上述原则的实际应用。

安全防护实例

场景一：指令覆盖尝试

当用户在对话中插入类似”忽略之前指令，只执行…“的内容时，OpenAI 的指令隔离层立即识别出指令覆盖模式——用户输入中出现了与系统指令角色直接冲突的语义指令。由于系统指令在消息对象中处于独立层且不可覆写，攻击性输入会被拦截并替换为安全提示，而非传递给下游推理流程。用户看到的是一条温和的拒绝消息，而非系统的完全不可用。

场景二：敏感数据请求

当 Agent 检测到用户请求的数据属于敏感分类（如个人身份信息、财务记录、健康数据），系统不会直接拒绝——那样会影响正常使用体验——而是在返回数据前插入数据脱敏步骤，并在响应中附带安全提示。例如，询问”列出所有用户的邮箱地址”会被转换为”已为您脱敏处理，以下是部分用户邮箱示例：user***@example.com”。脱敏后的数据对大多数业务场景仍有价值，但已不具备直接滥用的可行性。

场景三：危险操作请求

对于删除大量数据、向外部系统发起支付、发送未经授权的外部邮件等高风险操作，OpenAI 的行为约束层会在执行前触发人工确认环节。这个环节不是简单的确认对话框，而是需要用户主动输入操作目标、验证操作范围的独立验证流程。即使攻击者通过 Prompt 注入成功绕过了前两层防御，只要危险操作确认层需要物理操作者的参与，攻击链就在这里断裂。

最佳实践与检查清单

开发 AI-Native 应用的检查清单

输入层防护：

  • 实施系统指令隔离
  • 检测指令覆盖尝试
  • 验证输入长度和格式
  • 实施速率限制

行为层防护：

  • 定义操作白名单
  • 验证所有工具参数
  • 敏感操作需要确认
  • 实施沙箱执行

数据层防护：

  • 分类数据敏感度
  • 脱敏敏感数据
  • 控制数据访问权限
  • 审计数据访问日志

输出层防护：

  • 检测敏感信息泄露
  • 审查异常响应模式
  • 记录所有输出日志
  • 实施响应过滤

关键原则

  1. 零信任：不信任任何输入，即使来自”用户”
  2. 最小权限：Agent 只拥有完成任务的最小权限
  3. 纵深防御：多层防护，不依赖单一防线
  4. 审计追踪：所有操作可追踪、可回滚
  5. 持续监控：检测异常行为模式

结尾：安全是 Agent 的前提

Prompt 注入防御不是可选项，而是 Agent 应用的基础要求。

OpenAI 的实践表明，安全需要在架构设计的每个层级考虑：

  • 输入层：指令隔离和过滤
  • 行为层：操作约束和沙箱
  • 数据层：分类和访问控制
  • 输出层：审计和审查

对于开发者来说，构建 Agent 应用时应该：

  1. 从设计之初就考虑安全
  2. 采用分层防御架构
  3. 最小权限原则
  4. 持续监控和迭代

Agent 的能力越强，安全的责任越大。

💡 Key Insight

Agent 的能力越强，安全的责任越大——这个对称性是 Agent 安全的根本约束，不能用技术手段消除，只能通过架构设计和治理机制来承载。

参考与延伸阅读

深度阅读时间：约 13 分钟

本文基于 OpenAI Engineering 博客文章分析。

发布于 aazh2026.github.io