麦肯锡的 Lilli 于 3 月 9 日公开亮相。该记录不含有任何损害。

2026 年 3 月 9 日，安全初创公司 CodeWall 发布了其说明，讲述它构建的一个自主智能体如何在大约两小时内、且未使用任何凭据的情况下，获得对 Lilli 背后生产数据库的完整读写权限；Lilli 是 McKinsey & Company 的全公司 AI 助手。入侵本身发生在 2 月 28 日；这条 AI 事件档案条目所记录的，是它被公开的那一天。据 CodeWall 称，其访问到的数据库包含 4650 万条明文聊天消息、728,000 个文件、57,000 个用户账户，以及 95 条决定 Lilli 如何回答的系统提示词——而这些提示词就位于该智能体能够写入的同一个数据库中。数据中的人是 McKinsey 自己的员工：该公司表示，其 72% 的员工（超过 40,000 人）使用 Lilli，而 Lilli 每月处理超过 500,000 条提示词。完整条目及其严重性和置信度评级，以及与之相邻的记录，收录于 Orca AI Incident Archive。

这个开头把两类截然不同的主张压缩在了一起，而档案条目对二者的区别很谨慎。它把该记录评定为一起事件，置信度为 A，未受争议，严重程度高，地区为美国，类型为 INFRA——即基础设施问题，而非模型故障。它还记录称没有实际危害。最后一个字段值得再读一遍，因为它并不意味着此次暴露无害。它的意思是，记录中并未确立任何危害；下文将区分双方一致认同的内容，与仅依据某家公司对自身研究的说法所成立的内容。

为什么披露本身就是一个有日期的事件

该条目的档案摘要指向2026年2月28日，即CodeWall的智能体发现该漏洞的那一天，档案还将这个更早的日期作为单独记录保存。这种拆分并非官僚程序。3月9日之前，唯一知道Lilli内部发生了什么的是McKinsey和那位向其告知此事的研究员。3月9日之后，故障的形态、公司的回应以及关于数据库内容的说法都已进入公开记录，其他安全研究人员可以在那里与这些说法争辩。

Lilli 不是一个副业项目。The Register 称其于 2023 年 7 月推出，功能涵盖聊天、文档分析以及对公司内部研究资料的检索。CodeWall 的文章还记录了该名称的由来——公司于 1945 年聘用的首位职业女性——并称其背后有超过 10 万份内部文档。The Register 同日报道这一披露时称，采用率达到员工的 72%，每月提示量超过 50 万次——这些数字是 McKinsey 自己在关于该平台的公开案例研究中发布的。

代理是如何进入的

CodeWall 的叙述始于文档，而非漏洞利用。其代理发现 Lilli 的 API 文档被公开暴露，而且内容完整：总共有 200 多个端点，其中大多数需要身份验证，另有 22 个不需要。其中一个未认证端点会将用户搜索查询写入数据库。值都已正确参数化，但 JSON 键——也就是字段名——被直接拼接进 SQL。

该智能体之所以注意到这一点，是因为数据库错误消息会逐字回显那些 JSON 键。CodeWall 表示，OWASP 的 ZAP 扫描器并未标记该问题，随后该智能体进行了十五次盲迭代，每条错误消息都让它进一步了解查询的结构，直到开始返回生产环境中的实时数据行。此后，它将注入与对象级授权缺陷串联起来，读取个别员工的搜索历史记录。该公司称整个运行过程从目标选择到生成报告完全自主，无需凭据，也没有人工介入。其创始人兼首席执行官 Paul Price 告诉 The Register，该过程“从研究目标、分析、攻击到报告完全自主”。

CodeWall 说里面有什么

本节中的每一个数字都来自 CodeWall 3 月 9 日的那篇报告。由于没有公布任何载荷，因此这些内容都无法复现，也无法独立核算——这一局限将在下一节中讨论。

• 4650万条聊天消息以明文存储，涵盖战略工作、客户合作、财务以及并购。

• 728,000 个文件，其中该文稿逐项列出 192,000 个 PDF、93,000 个 Excel 电子表格、93,000 个 PowerPoint 演示文稿和 58,000 个 Word 文档——合计 436,000 个，同一句话中其余 292,000 个文件则未作分类。

• 57,000 个用户账户、384,000 个 AI 助手和 94,000 个工作区，CodeWall 将其描述为该事务所内部使用 AI 的完整组织架构。

• 涵盖 12 种模型类型的 95 条系统提示和模型配置，展示了助手是如何被指示的、存在哪些防护措施，以及其底层使用了哪些模型。

• 368 万个检索增强生成文档块，附带 S3 存储路径与内部文件元数据——即支撑该助手运行的知识库。

• 110 万个文件和 21.7 万条智能体消息经由外部 AI API 流转，其中包括 OpenAI 平台上超过 26.6 万个向量存储。

CodeWall 视为头条的发现并非注入本身，而是注入落到了哪里。Lilli 的系统提示词是同一个数据库中的行，而智能体可以写入这个数据库，这意味着拥有相同访问权限的攻击者只需一条包裹在单次 HTTP 调用中的 UPDATE 语句，就能重写助手的指令——无需部署、无需更改代码、磁盘上也没有可对比差异的文件。CodeWall 表示其自身测试仅用于验证：只读取，未写入，并称没有生产服务受到干扰。

麦肯锡当天说了什么

麦肯锡的一位发言人于3月9日对《The Register》表示，公司在得知CodeWall所识别出的所有问题后的数小时内就已将其全部修复。该发言人称：“我们的调查在一家领先的第三方取证公司支持下进行，未发现任何证据表明该研究人员或任何其他未经授权的第三方访问了客户数据或客户机密信息。”他还补充说，“麦肯锡的网络安全系统是稳健可靠的。”

Silicon UK 于3月13日报道了同一立场，在 Matthew Broersma 的叙述中：麦肯锡表示，它“最近被一名安全研究员告知存在一个与我们内部 AI 工具 Lilli 相关的漏洞”，它“迅速确认了该漏洞并在数小时内修复了该问题”，并且没有客户数据或客户机密信息遭到访问。该报道还指出，Price 是 CodeWall 的唯一员工，这一细节值得保留，因为它具有两面性——一个单人研究团队在两小时内发现了该公司自己的扫描工具未能发现的问题，而一个单人团队也在销售发现该问题的工具。

关于该修复的两种说法，相隔一天

CodeWall 自身的披露时间线如下：该智能体于 2 月 28 日识别出 SQL 注入并开始枚举生产数据库；完整攻击链于同日得到确认，并记录了 27 项发现；3 月 1 日，一封负责任披露邮件发送至 McKinsey 安全团队，附有高层级影响摘要；3 月 2 日，该公司首席信息安全官确认收到并索要详细证据；同日（3 月 2 日），所有未认证端点均已修补并验证，开发环境已下线，公共 API 文档被屏蔽。随后于 3 月 9 日进行公开披露。

麦肯锡的说法是，修复是在被告知后数小时内完成的。CodeWall 的时间线则将补丁定在其披露邮件发出后的第二天。两者均有公开记录。双方都未对二者作出调和，本文也不打算这样做：分歧只在于当日修复还是次日修复，而真正重要的顺序——先被告知、再打补丁、然后公布——并无争议。

既有的、单一来源的，以及两者之间的差距

已确认，双方同意：Lilli 的公开 API 表面存在一个未认证漏洞；该漏洞是由外部安全研究人员而非内部人员发现的；麦肯锡已确认并修补了该漏洞；未认证的端点已被关闭，开发环境已下线，公开 API 文档已被屏蔽。

单一信源，来自 CodeWall：上文的每一个计数、两小时时间线、十五次盲迭代、27 项有记录的发现，以及这些提示词可通过同一注入方式写入的说法。这些都没有被证伪。也没有任何一项得到独立验证，因为那些能让别人核查的载荷并未公布，而且 Price 拒绝向 The Register 提供其团队所使用的确切提示词。

AI安全公司Promptfoo于3月10日发布了一份评估，精确指出了这一局限：公开记录“并不能独立证明每一个已报告的记录行数或利用过程的每一步”，尽管它确实支撑了该事件的大致形态。这是对现有材料的正确解读。该漏洞类别是可重建的；其规模则只是证词。

记录未承载的伤害

这正是档案评级真正发挥作用的地方。在面向全公司的助手的生产数据库中，存在一条两小时内取得读写权限的路径，听起来像一份危害记录，而档案中没有记录任何此类危害。这一字段依据三点：McKinsey 的声明称，第三方取证调查未发现客户数据被访问的证据；CodeWall 的声明称，其测试仅为验证性质，未造成任何干扰；以及本文所审阅的报道中不存在任何相反发现。

它并不基于独立的技术审计、监管机构的裁定或数据泄露通知。在审阅过的任何报道中，均未分配 CVE 标识符——Lilli 是内部软件，而非分发产品，也没有任何公告点名它——并且似乎没有任何监管机构已立案。在本文章所审阅的报道中，没有公开证据表明这些数据曾被使用、出售或进一步暴露。这就是此处“未记录到实际损害”的含义：关于记录的证据陈述，而非认定此次暴露是安全的。

这个差距之所以重要，是因为真正值得关注的风险是前瞻性的。读访问暴露的是已经存在的内容。对提示层的写访问则暴露了助手接下来会说什么——被投毒的建议、护栏被移除、机密材料被塞进一个回答里，然后顾问将其粘贴到客户文档中。CodeWall 将这些后果描述为任何拥有相同访问权限的人都能造成。没有人证明这些后果真的被利用了。两种说法可以同时成立：能力确实存在，而根据任何人已公布的证据，危害并未成为现实。

为什么它被归类为基础设施问题，而不是模型故障

归档系统给这条记录打的标签是 INFRA，技术记录也支持这一标签。CodeWall 的叙述中没有任何环节需要靠欺骗模型来实现。其中没有越狱，没有来自文档的提示注入，也没有要求助手照单全收的对抗性输入。入口是一份对外暴露的文档、一处缺失的身份验证检查，以及不安全的 SQL 构造；模型不过是那扇门后最有价值的东西而已。

Promptfoo 3月10日的分析从防御侧作出了同样的区分：Lilli“从公开记录来看，像是一起波及 AI 系统的应用安全事件，而不是模型越狱”，而许多被称为 AI 安全的内容，仍然是软件安全、数据安全和配置治理。AI 特有的部分在于影响范围，而非入侵本身——因为提示词、路由规则和检索设置都是可变的应用程序数据，数据库写入权限就变成了无需改动代码即可改变助手行为的能力。

之后发生了什么变化

具体变化正是双方所描述的那些：未认证端点已被关闭并经过验证，开发环境已下线，公开的 API 文档已被屏蔽。麦肯锡表示，它发现并确认了该漏洞，并已将其修复，其公开立场是没有客户数据被访问。

没有改变的是这一事件所描述的更广泛的暴露面。CodeWall 的文章在结尾论证说，提示词被存储在数据库中、经由 API 传递并缓存在配置文件里，而它们很少获得访问控制、版本历史或完整性监控——这是一个关于整个行业的论断，而不是关于 McKinsey 的发现，并且应被解读为一家销售持续自动化测试的公司的论点。该公司正处于早期预览阶段并正在寻找设计合作伙伴；此次披露同时也是一场演示。

记录留下的内容比争论更狭窄，也更有用。一个全公司范围的助手、一个生产数据库、两个小时、没有凭据，以及一条读起来为“假”的危害判断，因为能够接触事实的双方都说数据未被使用。计数属于其中一方。漏洞则属于双方。