Agent安全别再只靠“AI防火墙”：OpenAI给了更现实的防护框架

摘要

Agent 越能干，安全问题就越不像传统 prompt 技巧题。一个能浏览网页、读取邮件、调用工具、发送信息、修改文件的 Agent，面对的攻击不再只是“忽略之前指令”这种显眼字符串，而是更接近社会工程：外部内容伪装成合理上下文，诱导 Agent 执行用户没有授权的动作。

OpenAI 在《Designing AI agents to resist prompt injection》中明确指出，真实 prompt injection 攻击正在向社会工程演化。单靠一个“AI 防火墙”去判断输入是否恶意，很难覆盖所有场景。更现实的工程策略，是承认有些操纵可能成功，然后通过 source-sink 分析、权限分层、敏感动作确认和纵深防御，把成功攻击的影响限制住。

背景：prompt injection 不是简单字符串过滤

早期 prompt injection 常被理解为网页、文档或邮件里出现一句“忽略之前所有指令”。随着模型变强，这类直白攻击更容易被识别。但 OpenAI 观察到，攻击者也会升级：把恶意目标包装在看似正常的业务语境里，让 Agent 在上下文压力下做出错误判断。

例如，邮件可能假装是一个正常工作请求，夹带“读取员工数据并保存供后续使用”之类动作。单看文本，很难像传统恶意代码一样精准分类。因为判断它是否恶意，需要知道用户真实意图、业务流程、数据权限和动作后果。

这就是为什么仅靠输入过滤不够。过滤器面对的不是固定模式，而是“这段话是不是在骗 Agent”的语义判断，本质上接近识别谎言、误导和社会工程。

技术要点一：从“识别坏输入”转向“限制坏后果”

OpenAI 的核心思路是，不要把安全目标限定为完美识别恶意输入。因为在真实世界里，外部内容足够复杂，永远可能有攻击绕过检测。更可靠的问题是：即使 Agent 被误导，它最多能造成什么后果？

这个视角和传统企业安全一致。公司不会指望员工永远不被钓鱼邮件欺骗，而是通过权限最小化、转账审批、数据访问审计、反钓鱼提示、异常行为检测来降低损失。Agent 也应该这样设计。

所以，Agent 安全不是在 prompt 前面加一层“是否恶意”的判断就结束。它需要系统级边界：哪些数据可以读，哪些动作必须确认，哪些工具不能自动调用，哪些外部内容只能作为资料不能作为指令。

技术要点二：source-sink 分析是实用框架

OpenAI 提到，他们结合社会工程模型和传统安全工程中的 source-sink analysis。source 是攻击者影响系统的入口，例如网页、邮件、文档、第三方插件输出、搜索结果；sink 是在错误上下文里会变危险的能力，例如发送信息、上传文件、调用支付、修改数据、访问敏感内容。

真正危险的不是 source 或 sink 单独存在，而是二者被 Agent 串起来。一个网页包含误导内容本身未必造成损失；一个发送邮件工具本身也正常。问题是 Agent 读取了不可信网页，然后根据网页里的指令把敏感信息发送出去。

研发团队可以直接用这个框架做威胁建模：列出所有不可信输入源，再列出所有高风险输出能力，重点防护 source 到 sink 的路径。只要某条路径可能导致敏感信息传输、不可逆操作或权限升级，就必须增加确认、隔离或阻断。

技术要点三：高风险动作不能静默发生

OpenAI 文章强调的一个用户安全期望是：潜在危险动作，或潜在敏感信息传输，不应在没有适当保护的情况下静默发生。这个原则非常适合落到产品设计。

Agent 可以自动总结网页，但不应自动把私密数据发给外部地址；可以草拟邮件，但发送前应让用户确认；可以读取公开资料，但涉及私有文件、账号数据、支付、删除、邀请、权限变更时，需要更强控制。

这不是降低 Agent 体验，而是让用户保持控制权。真正可用的 Agent 不是所有动作都自动做，而是能区分低风险自动化和高风险授权。

技术要点四：工具权限要按能力拆分

很多 Agent 系统的问题是工具权限过粗。一个“邮箱工具”如果同时能读邮件、搜索联系人、写草稿、发送邮件、下载附件，那么一旦 Agent 被外部内容误导，风险面会非常大。

更好的做法是按能力拆分工具权限：读和写分开，草稿和发送分开，内部域和外部域分开，公开数据和敏感数据分开。这样即使 Agent 在某一步被影响，也不一定能直接触达高风险 sink。

工具权限拆细之后，产品还能按上下文做策略：默认只允许只读工具；写操作需要显式用户意图；跨域发送需要二次确认；包含敏感字段的内容需要额外审查。

研发视角：Agent 安全是产品架构问题

这篇 OpenAI 文章对研发团队最重要的提醒，是不要把 prompt injection 当成模型团队或安全模型单独能解决的问题。它是产品架构问题。

模型层可以提高识别能力，分类器可以过滤一部分攻击，红队可以发现模式，但最终决定风险上限的是系统设计：权限模型、工具边界、确认流程、日志审计、数据流隔离、默认策略。

如果一个 Agent 拥有过大的权限，再聪明的模型也会形成高风险单点。反过来，如果系统把危险 sink 控住，即使模型偶尔被误导，损失也能被限制。

实践建议：上线 Agent 前检查 7 个问题

1. 列出所有不可信 source：网页、邮件、文档、搜索结果、用户上传文件、第三方工具输出。
2. 列出所有高风险 sink：发送消息、上传文件、删除数据、改权限、执行命令、支付或调用外部 API。
3. 明确哪些 source 不能直接影响哪些 sink，必要时在代码层阻断。
4. 把工具权限拆小，避免一个工具同时拥有读、写、发送和删除能力。
5. 对敏感数据传输和不可逆操作增加用户确认。
6. 记录 Agent 的 source、工具调用和最终动作，便于审计和追责。
7. 用红队和 eval 覆盖社会工程型攻击，而不只是测试直白 prompt injection。

这些检查比“再加一句不要泄露信息”更可靠，因为它们改变的是系统可达状态。

风险与限制

OpenAI 的方法不是说模型防护没用，也不是说所有 Agent 都必须重到企业安全平台级别。不同场景风险不同：只读总结类 Agent 和能发邮件、改数据库、执行命令的 Agent，安全要求显然不同。

但核心原则通用：不要把安全寄托在完美识别恶意输入上。外部内容越复杂，越要假设检测会漏掉一部分攻击，然后用权限、隔离、确认和审计限制后果。

结语

Agent 安全的难点，不是给模型一句“不要被 prompt injection 攻击”。真实攻击会伪装成正常上下文，利用任务压力和工具权限把 Agent 引向危险动作。

OpenAI 这篇文章给研发团队的关键信号是：Agent 安全要从输入过滤升级为系统设计。识别攻击当然重要，但更重要的是，即使识别失败，系统也不允许敏感信息静默外流，不允许高风险动作无确认发生。

参考来源

• OpenAI: Designing AI agents to resist prompt injection
  https://openai.com/index/designing-agents-to-resist-prompt-injection/