AI agents are a confused deputy with the keys to your kingdom
TL;DR · AI 摘要
AI代理可能暴露系统中未明确编码的人工授权检查，导致安全漏洞。
核心要点
- AI代理可能执行用户请求而忽略身份验证，导致安全漏洞。
- Meta的AI助理未验证请求者身份，导致2万Instagram账户被攻击。
- 人工授权检查若未编码，AI代理将无法识别异常请求。
结构提纲
按章节快速跳转。
思维导图
用一张图看清主题之间的关系。
查看大纲文本（无障碍 / 无 JS 友好）
- AI代理与安全漏洞
- 攻击案例
- 2万Instagram账户被攻击
- AI助理未验证身份
- 安全概念
- Confused Deputy
- 人工授权检查缺失
金句 / Highlights
值得收藏与分享的关键句。
攻击者通过与Meta的AI助理对话，控制了2万Instagram账户，包括奥巴马时期的白宫账户。
AI代理执行了用户请求，但未验证请求者身份，导致系统漏洞。
人工授权检查若未编码，AI代理将无法识别异常请求。
AI代理是拥有你王国钥匙的困惑副手 - Stack Overflow
2026年6月17日
AI代理是拥有你王国钥匙的困惑副手
攻击者如何通过礼貌地询问Meta的AI，就控制了两万个Instagram账户，以及为什么这种失败即将成为常见现象。
图片来源：Alexandra Francis
[
6月初，攻击者在没有编写漏洞利用程序或猜测任何密码的情况下，控制了超过两万个Instagram账户，其中包括奥巴马时期白宫账户的休眠账户。他们与Meta的AI客服助手开启了一次聊天，要求它将他们控制的一个电子邮件地址附加到一个他们并不拥有的账户上，并请求将密码重置到该地址。Meta随后确认了日志中已经显示的内容：助手的表现完全符合设计，而系统中另一个部分本应验证该电子邮件是否属于该账户，但该检查从未运行。
将这种情况称为AI的错误，忽略了真正发生的事情。助手执行了对与其交谈的人而言是合法的操作序列。能够阻止这次攻击的是一个人：一位客服人员，他看到一个陌生人将名人的恢复电子邮件重新路由，察觉到事情不对，并拒绝了。
现实中大部分授权从未被编写成软件。相反，它存在于请求者和系统之间的任何人的裁量权中，而系统后面的所有内容都假设这种裁量权始终存在。将代理放在那个位置后，裁量权就消失了，而下游的任何东西和任何人都没有注意到。代理并没有绕过你的安全模型，它只是暴露了其中原本是人的部分。
带有聊天窗口的困惑副手
安全领域有一个精确的术语来描述Meta所遭遇的情况：困惑副手。一个拥有真实权限的进程被一个权限较低的方说服，代表它使用这些权限。就像夜班警卫为任何打电话来说老板派他们来的人打开金库一样：他有钥匙，他们有一个好故事。1988年的经典案例是一个可以写入受保护账单文件的编译器。一个无法写入该位置的用户请求编译器代为执行，而编译器执行了，因为它有权限，而且从未询问它正在服务的是谁的请求。
从结构上讲，一个大型语言模型（LLM）代理就是其中之一。它的接口是自然语言，这不包含谁被授权做某事的概念，而模型的全部工作就是将听起来合理的句子转换为工具调用。直接的API请求至少会将调用者的身份一起带入。而一个句子不会，除非在调用之前重新附加该身份，否则代理将按照自己的权限行事，请求者的权限将不会进入画面。
代理也无法可靠地区分指令和数据。上下文窗口中的所有内容都可能被解读为指令：用户的消息、检索到的文档、代理被要求总结的电子邮件正文。一个因令人信服的聊天而重置密码的支持机器人，同样可能遵循隐藏在它被要求处理的文件中的命令。击败Meta地理位置检查的VPN技巧是这种攻击的粗略版本。更复杂的版本，其中恶意指令通过代理摄入的内容被秘密传递，已经被记录为代理攻击的主要类别。
爆炸半径即将扩大
Instagram 机器人可以重置密码，这虽然是一种严重的安全漏洞，但其影响是有限的。目前部署的代理程序则并非如此。就在 Meta 禁用该支持工具的同一周，它推出了其商业代理程序，该代理程序可以预约会议、筛选潜在客户、促成销售、处理付款，并连接到如 Shopify 和 Zendesk 等系统，代表公司执行操作。如果将同样的“困惑副官”逻辑应用于支付 API 和客户关系管理（CRM）系统，那么失败的结果就不再是一个被盗账户，而可能是将退款发送给错误的一方、重新路由订单、覆盖价格、修改客户记录，每一种情况都是代理程序被授权执行的合法操作。
市场正在超越当前的安全模型。Gartner 预测，到 2026 年底，40% 的企业应用程序将包含特定任务的 AI 代理，而这一比例在 2026 年初还不到 5%。这些部署中的大多数都将继承 Meta 所采用的相同假设，即特权操作的另一端具备判断力。
为什么更好的模型无法解决这个问题
在相同的流程中，一个能力更强的模型可能会以更流畅的语法交付相同的账户信息，这正是为什么模型不能作为授权的存放地，因为攻击者可以控制模型。允许执行某个操作的决定必须在模型之外做出，由一个策略层来检查实际会话背后的用户身份，然后再执行任何操作。Meta 的助手在重新绑定用户的恢复电子邮件之前，从未确认过它对话的用户是否拥有该账户。
用几行代码来看，部署的代码大致如下。代理程序可以调用该函数，而能够调用该函数就是全部的授权：
def add_recovery_email(account, new_email):
account.recovery_email = new_email # 这里没有任何内容与调用者相关
send_reset_link(new_email)修复方法不是更聪明的模型或更好的提示，而是缺少的主控检查，这个检查必须在聊天内容无法影响的任何地方进行决定：
def add_recovery_email(account, new_email, principal):
if not principal.owns(account): # 实际请求者是谁，经过验证
raise Unauthorized("会话未通过账户所有者身份验证")
account.recovery_email = new_email
send_reset_link(new_email)攻击者控制了对话，但 principal 来自经过身份验证的会话，而不是聊天内容，因此无论有多少令人信服的信息，都无法满足这一行代码的条件。
代理程序应持有有限范围和短暂有效期的权限，而不是长期的访问权限。一个用于总结客户开放工单的令牌，不应能用于退还其最近的订单。这是最小权限原则，但必须在每次操作和每个资源上强制执行，而不是在会话开启时一次性授予并从此信任。因为代理程序可能会被说服去使用其凭证允许访问的一切。
任何不可逆的操作都需要一个代理程序无法通过的关卡。模型可以通过生成合适的文字来满足确认，但这并不是真正的控制，只是表面文章。付款、删除、权限更改和账户恢复应置于人工审批或硬性策略规则之后，这些规则应根据其可能造成的损害程度进行分类，而不是像常规查询一样被随意通过。
每个代理执行的操作都应该记录其来源，即产生该操作的主体、会话和提示信息，这样你可以审计发生了什么，并在出现问题时撤销该操作。考虑到Instagram攻击持续了大约六周时间，一个被限制的事件与窃取两万个账户之间的距离，往往只在于是否有人能够近乎实时地看到某个特权操作反复针对毫无关联的账户执行。
将判断转化为代码
以上原因并不是要让代理远离真实系统。它们是值得构建的，而Meta所发生的问题只是一个普通的工程漏洞，并不是我们对AI必须恐惧的某种特性。所有修复措施都是团队已经知道如何实施的：限制凭证的使用范围，验证主体身份，对无法撤销的操作进行权限控制，并记录所有执行的操作。
一个习惯将它们联系在一起。在将代理连接到任何重要系统之前，请先问一下：在这个流程中的人过去是如何进行判断的？这种判断是实际的工作，现在必须以代码的形式存在，因为代理不会为你自行发挥判断。做到这一点，顺从就不再是负担。一个只执行被允许操作的代理，正是你想要的，只要你已经完成了决定它被允许执行哪些操作的工作。