麦肯锡内部 AI 平台被黑了，4650 万条聊天记录全部暴露

有这么一个场景。

一个 AI Agent，什么都不知道——没有账号、没有内部文档、没有任何人的帮助。只有一个域名：lilli.mckinsey.com。

两小时后，它坐拥 4650 万条员工对话记录、72.8 万份内部文件、5.7 万个用户账户。

更夸张的是：它还修改了 Lilli 的系统提示词。从那以后，任何问 Lilli 问题的员工，得到的都是被篡改过的回答。

这不是电影情节。这是 2025 年底，安全公司 CodeWall 的研究团队对麦肯锡 AI 平台 Lilli 做的一次真实测试，结果写在他们的博客上。

攻击链：五步，两小时

我仔细看了原报告，这次攻击没有黑魔法，就是五步。

第一步：公开文档。 Lilli 有对外可见的 API 文档——很多企业内部工具都有，方便集成嘛。CodeWall 的 Agent 从文档里拿到了系统端点列表。

第二步：未授权端点。 扫了一圈，Agent 发现几个接口没有认证检查。直接发请求就能拿到数据，不用登录。

第三步：JSON Key SQL 注入。 这是整个链条里最容易被忽视的漏洞类型。普通 SQL 注入大家都知道，很多系统也做了防护。但 JSON Key 注入不一样——当 JSON 对象的键名本身被拼进 SQL 查询时，大多数 WAF 扫不到，ORM 框架也不管，漏掉是常态。

第四步：拿数据。 注入成功，Agent 获得了数据库读写权限。4650 万条聊天记录、72.8 万份文档、5.7 万个账户——全部可读可写。

第五步：劫持 AI 行为。 这一步是整个报告里最让我在意的。Agent 找到了 Lilli 的系统提示词配置，直接改了它。

黑客不只偷走了你的数据，还悄悄改变了你的 AI 在想什么。

数据泄露是一次性损失：信息被拿走，损失固定。

系统提示词被篡改是持续性的：之后每一个向 Lilli 提问的员工，都会得到被污染的回答。误导性的策略建议、错误的客户信息、针对特定问题的偏向性输出——员工完全不知道他们信任的 AI 已经不是原来那个了。

这比数据库泄露难发现，影响也可能蔓延更久。

麦肯锡不是特别粗心的公司。全球顶级咨询机构，有专门的安全团队，有完善的 IT 政策。Lilli 也不是小工具，据说是他们全球数万名顾问都在用的知识平台。

但还是被攻破了。

原因是结构性的，不是执行层面的。

弱点一：快速部署。 企业内部 AI 工具上线很快，通常是"先跑起来，安全后面再说"。这不是批评，是现实——AI 竞争窗口太窄，慢一步就落后了。传统软件上线前有安全测试流程，AI 工具通常没有。

弱点二：公开的 API 文档。 为了方便集成，很多内部工具的文档可以外网访问，或认证要求宽松。在没有自动化攻击的年代，这是可接受的风险。现在不是了——AI Agent 几秒内读完文档，直接找可攻击入口。

弱点三：内网信任假设。 很多系统的逻辑是"能访问这个端点，说明你在内网了，我信任你"。但 API 端点一旦有一点暴露，这个假设就失效了。

这三个条件，麦肯锡有。你的公司在部署 AI 工具的时候，大概率也有。

这次攻击，CodeWall 的 Agent 全程自主执行——不是人盯着屏幕操作，而是 Agent 自己完成了从侦察到入侵的完整链路。

攻击已经有了自动化的执行方式，可以大规模复制。

大多数公司的安全响应还是人工的：有人发现异常，有人分析，有人处理。中间有时间差，有排班，有工单流程。

AI Agent 攻击不需要等你的安全工程师上班。

我的看法是：这件事正在发生，而且窗口期很短。第一批被攻击的不是最粗心的公司，是最快部署 AI 但没有同步更新安全实践的公司。麦肯锡不是特例，是预演。

认证不能靠假设。 不管是"内部工具"还是"需要登录才能访问首页"，API 端点的认证要单独验证，不能依赖上层访问控制。未授权端点是这次攻击的入口，也是最常见的 AI 平台漏洞类型。

API 文档不是越公开越好。 真正的内部工具，文档的访问权限值得单独检查。你不需要让所有人都能在外网看到你的接口结构。

AI 行为要有审计。 系统提示词是 AI 工具的"大脑配置"，被篡改的影响覆盖所有用户。这个配置应该有版本管理、变更审计，异常修改要有告警。这不是多余的工作，是基本的治理。

你们公司在用什么内部 AI 工具？有没有做过安全评估？欢迎评论区聊聊。