AI agents expose the security checks you never actually wrote
TL;DR · AI 摘要
AI agents expose the security checks you never actually wrote - Stack Overflow June 15, 2026 AI agents expose the securi...
核心要点
- 主题聚焦：AI agents expose the security checks you never a
- 来源：Stack Overflow Blog，建议结合原文判断细节。
- AI 分析暂不可用，本条为保底评分与摘要。
AI代理暴露了你从未真正编写的安全部署 - Stack Overflow
2026年6月15日
AI代理暴露了你从未真正编写的安全部署
攻击者如何通过礼貌地询问Meta的AI，窃取了两万个Instagram账户，以及为什么这种失败即将成为普遍现象。
[
6月初，攻击者在不编写任何漏洞利用代码或猜测任何密码的情况下，控制了超过两万个Instagram账户，包括奥巴马时期白宫账户的休眠账户。他们与Meta的AI客服助手开启了一次聊天，要求它将他们控制的一个电子邮件地址附加到他们并不拥有的账户上，并请求将密码重置到该地址。Meta随后确认了日志中已经显示的内容：助手的行为完全符合设计，而系统中另一个部分本应验证该电子邮件是否属于该账户，但该检查从未执行。
将这种情况称为AI的错误，忽略了真正发生的事情。助手执行了对与其交谈者而言是合法的操作序列。能够阻止这次攻击的是一个人：一名客服人员，他看到一个陌生人将名人的恢复电子邮件重新路由，察觉到事情不对，并拒绝了请求。
现实世界中大量的授权从未以软件的形式编写过。相反，它存在于任何请求与系统之间的人的判断中，而所有后续的内容都假设这种判断始终存在。将代理放置在那个位置时，这种判断就会消失，而下游的任何东西和任何人都不会察觉。代理并没有绕过你的安全模型，它只是暴露了其中原本是人的部分。
一个拥有聊天窗口的困惑副官
安全领域有一个精确的术语来描述Meta所遇到的问题：困惑副官。一个拥有真实权限的进程被一个权限较低的方说服，代表它使用这些权限。不清楚吗？这就像夜班警卫为任何打电话说老板派他们来的人打开金库：他有钥匙，他们只是有一个好故事。1988年的经典案例是一个可以写入受保护账单文件的编译器。一个无法写入该文件的用户请求编译器替他写入，编译器照做了，因为它有权限，而且从未询问它正在服务的是谁的请求。
从结构上讲，一个大型语言模型代理就是其中之一。它的接口是自然语言，这并不涉及谁被授权做些什么，而模型的全部工作就是将听起来合理的一句话转换为工具调用。直接的API请求至少会将调用者的身份一同带入。而一句话不会，因此除非在调用之前重新附加该身份，否则代理将基于自己的权限执行，而请求者的权限从未进入画面。
代理也无法可靠地区分指令和数据。上下文窗口中的所有内容都可能被视为潜在的指令：用户的消息、检索到的文档、代理被要求总结的电子邮件正文。一个因令人信服的聊天而重置密码的支持机器人，同样可能遵循隐藏在它被要求处理的文件中的命令。击败Meta地理位置检查的VPN技巧就是这种攻击的粗略版本。更复杂的版本，其中恶意指令通过代理摄入的内容被秘密传递，已经被记录为代理攻击的主要类别。
爆炸半径即将扩大
Instagram 机器人可以重置密码，这虽然是一种严重的权限越界，但这种越界是有限的。目前部署的代理程序并没有这种限制。就在 Meta 禁用支持工具的同一周，它推出了其商业代理程序，该代理程序可以预订会议、筛选潜在客户、促成销售、收取付款，并连接到 Shopify 和 Zendesk 等系统，代表公司执行操作。将同样的“困惑副官”逻辑运行在支付 API 和客户关系管理（CRM）系统中，失败的结果就不再是一个账户被窃，而是退款发给了错误的一方，订单被重新分配，价格被覆盖，客户记录被修改，每一种情况都是代理程序被授权执行的合法操作，无论请求者是谁。
市场正在超越现有的安全模型。Gartner 预测，到 2026 年底，40% 的企业应用程序将包含特定任务的 AI 代理，而这一比例在年初还不到 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必须恐惧的某种特性。这里的每一个修复措施，都是团队已经知道如何实施的：限制凭证的使用范围、验证主体、对无法撤销的操作进行权限控制，并记录执行了哪些操作。
一个习惯将它们联系在一起。在将代理连接到任何重要的系统之前，请先问一下该循环中的人过去用什么来判断。这种判断是真正的劳动成果，现在必须以代码的形式存在，因为代理不会为你自行发挥。做到这一点，顺从就不再是负担。一个只执行被允许操作的代理，正是你想要的，只要你已经完成了决定它被允许执行哪些操作的工作。