过去，我们讨论账号安全时，最常见的风险通常是密码泄露、钓鱼链接、撞库攻击、短信验证码被劫持，或者某个接口存在越权漏洞。但最近发生在 Instagram 上的一起事件，把问题推向了一个新的方向：攻击者并没有通过传统方式“打穿”系统，而是利用了 AI 客服背后的账号恢复流程，让系统把密码重置链接发送到了不该发送的地方。这件事真正值得警惕的地方，不是“AI 回答错了”，而是当 AI 客服被接入账号恢复、身份验证、密码重置这类高权限业务流程后，它就不再只是一个聊天机器人，而是变成了企业权限体系中的一个新入口。根据公开报道，Meta 的 AI 辅助账号恢复工具 High Touch Support 曾被攻击者利用。问题出现在账号恢复流程中：系统未能正确验证用于接收密码重置链接的邮箱地址是否真的属于目标 Instagram 账号。攻击者因此可以诱导系统把重置链接发送到非账号绑定邮箱，进而接管账号。Meta 后续披露，受影响账号数量为 20,225 个。这不是一个简单的客服事故，而是一个典型的 AI 自动化安全问题。因为在传统流程里，账号恢复通常需要多层校验：账号归属、历史登录环境、绑定邮箱或手机号、二次验证状态、异常行为评分，必要时还会引入人工复核。但当 AI 被放进这个流程后，如果它不仅负责“回答用户问题”，还可以推动密码重置、邮箱变更、账号恢复等动作，那么攻击面就发生了变化。过去攻击者要绕过的是系统漏洞。现在，攻击者可能只需要绕过流程。
一、攻击者没有攻破系统，而是利用了业务流程
SQL 注入、命令执行、文件上传、权限绕过，这些问题通常发生在代码层或接口层。攻击者需要构造恶意参数，让系统执行原本不该执行的逻辑。但 AI 客服相关风险更复杂。攻击者面对的不只是一个接口，而是一套“自然语言交互 + 后端工具调用 + 业务流程执行”的组合系统。在 Instagram 这次事件中，公开报道提到，攻击者通过账号恢复流程与 AI 支持助手交互，并让系统把账号恢复步骤推进到错误的邮箱上。KrebsOnSecurity 报道称，相关利用过程曾在 Telegram 上传播，攻击者使用接近目标常用地区的 VPN 地址，请求密码重置，并与 Meta 的 AI support assistant 进行交互。这说明问题不只是“模型有没有被提示词注入”，也不只是“AI 有没有被说服”。更核心的问题是：AI 背后的业务系统，是否允许它在身份校验不足的情况下继续推动高风险操作。如果一个 AI 客服只是回答“如何修改密码”，风险有限。它最多回答不准确，或者误导用户。但如果它可以触发密码重置、绑定新邮箱、关闭二次验证、恢复账号、修改权限，那它实际上就已经获得了业务执行能力。此时攻击者的目标就不再是“让 AI 说错话”，而是“让 AI 帮他做成事”。这也是 AI Agent、AI 客服、AI 工单系统进入企业后最容易被低估的问题：真正危险的不是 AI 生成了错误文本，而是错误文本背后绑定了真实操作权限。二、AI 客服正在把“社会工程学”自动化
攻击者可能冒充老板、客户、员工、供应商，通过电话、邮件、IM 工具联系人工客服或运维人员，让对方放松警惕，最终执行某个高危动作。比如重置密码、修改绑定手机号、导出敏感资料、发起退款、审批权限变更。这类攻击的关键不是技术漏洞，而是利用信任、紧急感、身份模糊和流程缺口。AI 客服出现之后，攻击对象发生了变化。攻击者不再需要反复打电话说服人工客服，而是可以和 AI 系统反复对话，测试边界，调整话术，直到找到一条能让系统继续执行的路径。第一，攻击成本降低。攻击者可以批量测试不同话术，不需要等待人工客服上线，也不需要承担太多沟通成本。第二，攻击路径更稳定。人类客服的判断有随机性，有人谨慎，有人疏忽。但 AI 工作流如果存在固定缺陷，一旦被找到，就可能被重复利用。第三，攻击更容易规模化。只要某个流程可以被自动触发，攻击者就可以把它写成教程、脚本或半自动化流程，传播给更多人使用。这次事件中，受影响的不只是普通账号。Reuters 报道提到，被波及的包括一些高知名度账号，例如 Obama White House 相关账号、Sephora，以及一名美国太空军官员相关账号。这意味着 AI 客服一旦进入账号恢复这类敏感流程，它面对的就不只是普通用户问题，而是账号资产、品牌资产、组织声誉和身份可信度。对于企业来说，这类风险的损失也不只是一两个账号被盗。更严重的是，攻击者可以利用被接管账号进一步发布虚假信息、开展二次钓鱼、冒充官方通知、诱导用户点击链接，甚至制造舆论影响。三、问题不只是提示词注入，而是权限边界失控
很多人看到这类事件，第一反应会把它归因于“提示词注入”。提示词注入通常是指攻击者通过自然语言指令影响模型行为，让模型忽略原有规则、泄露信息、调用工具或执行不安全动作。OWASP 在 2025 年的 LLM 应用安全风险中，也把 Prompt Injection 列为重要风险之一。()但在真实业务环境里，提示词注入往往只是入口，真正造成损害的是后面的权限设计。如果 AI 没有工具调用权限，攻击者让它“说错话”，影响有限。如果 AI 可以调用内部接口，但接口本身有严格鉴权、参数校验、风控判断和二次确认，攻击也很难真正落地。最危险的情况是：AI 能理解用户意图，也能调用后端工具，而后端又过度相信 AI 的判断。这时，AI 就从一个“文本生成器”变成了“权限代理人”。OWASP 对 LLM 应用中的 Excessive Agency，也就是“过度代理能力”，有过明确描述：当 LLM 在异常、模糊或被操纵的输出下仍能执行有害动作，就会形成风险。企业往往会问：这个 AI 能不能回答用户问题？能不能减少人工坐席？能不能自动处理工单？能不能提高转化率？但安全团队更应该问：这个 AI 到底能调用哪些接口？它能读取什么数据？能修改什么字段？能不能触发密码重置？能不能关闭风控？能不能创建或升级权限？它调用接口时是否需要二次确认？它的每一次工具调用是否有审计日志？这些问题不解决，AI 客服上线得越快，企业暴露的攻击面就越大。四、AI 安全不能靠“写一段提示词”解决
很多企业上线 AI 客服时，会在系统提示词里写上类似规则：这些规则不是没用，但它们只能算软约束，不能当成安全边界。因为提示词本质上仍然是自然语言。自然语言可以被解释，可以被绕过，也可能在复杂上下文里被模型误判。尤其是在客服场景中，用户本来就会描述各种特殊情况：邮箱不能用了、手机号丢了、人在国外、账号被盗、情况紧急、需要马上恢复权限。对 AI 来说，这些请求未必天然恶意。问题在于，它是否有能力区分“真实用户的困难”和“攻击者构造的借口”。更合理的做法是把 AI 放在“意图识别层”，而不是“权限决策层”。AI 可以判断用户想做什么，比如“用户想恢复账号”“用户想修改邮箱”“用户想重置密码”。但是否允许执行，必须由后端确定性规则决定。比如，密码重置链接只能发往账号历史绑定邮箱或经过验证的新邮箱。绑定邮箱变更必须经过旧邮箱、手机号、可信设备或更高等级身份验证。关闭二次验证必须经过额外校验。账号恢复请求如果命中异常地区、异常设备、异常频率，就必须进入人工复核。这些规则不应该因为 AI 判断“用户看起来很着急”就被跳过。换句话说，AI 可以理解业务，但不能代替业务校验。五、第三方 AI 插件也在暴露同类问题
2025 年的一项研究分析了 17 个被超过 1 万个公共网站使用的第三方 AI 聊天机器人插件，发现其中 8 个插件未能保证前端传给聊天机器人的对话历史完整性，攻击者可以伪造对话历史，甚至伪造系统消息，从而增强诱导模型产生非预期行为的能力。研究还指出，15 个插件提供了网页抓取等工具，用于把网站内容加入聊天上下文，但这些工具没有充分区分可信内容和不可信内容，例如商品描述与用户评论。这个案例说明，AI 客服风险不是某一家公司的偶发问题，而是一个更普遍的工程问题。现在很多企业接入 AI 的方式非常快：买一个第三方插件，接入官网，挂上知识库，再连接客服系统、CRM、订单系统或工单平台。上线速度很快，但安全边界往往没有同步建立。尤其是中小企业，很容易把 AI 聊天窗口当成一个营销工具，而不是一个安全入口。但只要 AI 能接触用户数据、订单状态、售后流程、内部知识库，甚至能调用某些后台能力，它就已经不只是一个前端组件。既然是系统的一部分，就必须纳入资产管理、权限管理、日志审计、漏洞测试和应急响应。六、企业真正需要重建的是“AI 权限治理”
这类事件给企业最大的启示，不是“不要使用 AI 客服”。AI 客服、AI 工单、AI 运维助手、AI Agent 都会继续发展，因为它们确实能提高效率，减少重复劳动，也能改善用户体验。真正的问题是，企业不能只从效率视角设计 AI，而要从权限视角重新设计 AI。AI 能访问哪些系统，能读取哪些字段，能调用哪些接口，能不能写入数据，能不能执行高风险动作，都必须形成清单。这个清单应该像账号权限、API 权限、数据库权限一样被管理，而不是散落在产品配置或开发代码里。让 AI 理解用户意图没有问题，但执行操作时必须经过后端规则校验。模型输出不能直接变成接口参数，更不能直接触发敏感动作。对于密码重置、资金操作、权限变更、敏感数据导出等高风险行为，必须引入额外验证或人工审批。传统系统会记录用户登录日志、接口调用日志、操作日志。AI 系统同样需要记录：用户说了什么，AI 判断成了什么意图，调用了哪个工具，传入了哪些参数，后端返回了什么结果，最终产生了什么业务变化。如果没有这些日志，事故发生后就很难复盘。企业甚至无法判断是模型误判、提示词注入、接口漏洞，还是业务流程设计缺陷。过去渗透测试主要测 Web、App、API、服务器、数据库。现在，AI 客服也应该被测试。测试内容不只是“能不能套出系统提示词”，还应该包括能否诱导 AI 调用工具、能否绕过身份校验、能否访问越权数据、能否通过多轮对话触发高危流程。很多 AI 系统刚上线时，为了方便接入，会给过大的权限。比如可以查询大量用户信息，可以调用多个内部接口，可以跨系统处理工单。这种设计短期看方便，长期看风险很高。AI 的权限应该和普通账号一样遵循最小权限原则。它只应该获得完成当前任务所必须的能力，并且每个能力都应该有范围限制、频率限制、参数限制和审计机制。七、未来的漏洞，可能长得不像漏洞
这次 Instagram 事件最值得关注的地方在于，它不像传统漏洞。它不是一个典型的 SQL 注入，也不是一个远程代码执行，更不是某个服务器被爆破。它更像是业务流程、AI 自动化和权限控制之间的一次系统性失配。AI 被设计用来帮助用户解决问题，但账号恢复本身又是一个高风险场景。如果系统没有把“帮助用户”和“验证用户身份”严格分开，那么 AI 越努力完成任务，风险就可能越大。现在，企业还要担心系统被自己的 AI 助手误操作。这种变化对安全团队提出了新的要求。安全团队不能只盯着传统漏洞，也不能只把 AI 当成一个“智能客服项目”。只要 AI 被接入业务流程，它就是新的攻击面。尤其是在账号恢复、支付退款、权限审批、订单修改、数据查询、运维执行这些场景中，AI 的每一次自动化能力，都应该被当作一项需要治理的权限。结语：AI 可以接入业务，但不能接管边界
AI 客服的价值是提高效率，但效率不能替代安全边界。企业可以让 AI 解释流程，可以让 AI 帮助用户提交材料，可以让 AI 总结问题，可以让 AI 辅助人工客服判断。但企业不能让 AI 在缺少强校验的情况下，直接决定账号归属、权限变更、密码重置或敏感操作。这次事件真正提醒我们的是：AI 安全不是单纯的模型安全，而是系统安全。模型、提示词、工具调用、接口鉴权、业务规则、风控策略、审计日志、人工复核，必须作为一个整体来设计。而是它在说错话之后，是否拥有足够的权限，替攻击者完成一件原本不该完成的事。当 AI 开始接入企业核心流程，企业就必须重新回答一个问题：我们到底是在使用 AI 提高效率，还是在不知不觉中，把关键业务边界交给了一个可以被对话影响的系统？
资料来源
KrebsOnSecurity：关于 Meta AI support assistant 被利用接管 Instagram 账号的报道。
The Verge：关于 20,225 个 Instagram 账号受影响、密码重置邮箱校验缺陷及 Meta 后续处置的报道。
TechRadar：关于 Meta 确认 20,000 余个账号受影响，以及 High Touch Support 系统被禁用和后续安全检查的报道。
OWASP：LLM 应用安全风险中的 Prompt Injection 与 Excessive Agency。
夜雨聆风
