Lilli от McKinsey стала общедоступной 9 марта. Запись не несёт вреда.

9 марта 2026 года стартап в сфере кибербезопасности CodeWall опубликовал рассказ о том, как созданный им автономный агент получил полный доступ на чтение и запись к производственной базе данных, стоящей за Lilli — общекорпоративным ИИ-ассистентом McKinsey & Company, — примерно за два часа и не имея никаких учётных данных. Само вторжение произошло 28 февраля; эта запись в архиве инцидентов ИИ фиксирует день, когда оно стало публичным. По данным CodeWall, в базе данных, до которой он добрался, хранились 46,5 млн сообщений чата в открытом виде, 728 000 файлов, 57 000 учётных записей пользователей и 95 системных промптов, которые определяют, как отвечает Lilli, — и эти промпты находились в той же базе данных, в которую агент мог записывать. Люди, фигурирующие в данных, были собственными сотрудниками McKinsey: фирма говорит, что 72 процента её сотрудников — свыше 40 000 человек — пользуются Lilli, которая обрабатывает более 500 000 промптов в месяц. Полная запись, с её оценками серьёзности и уверенности и соседними записями, среди которых она находится, — в Orca AI Incident Archive.

Это вступление — сжатое изложение двух очень разных типов утверждений, и запись в архиве тщательно учитывает это различие. Она классифицирует запись как инцидент, уверенность A, не оспаривается, серьёзность высокая, регион US, тип INFRA — инфраструктура, а не сбой модели. Она также фиксирует отсутствие реального ущерба. Именно последнее поле стоит прочитать дважды, потому что оно не означает, что раскрытие было безвредным. Оно означает, что по записям не было установлено никакого ущерба, а статья ниже отделяет то, в чём две стороны сходятся, от того, что опирается лишь на версию одной компании о её собственном исследовании.

Почему раскрытие является отдельным событием с датой

Сводка архива для этой записи отсылает к 28 февраля 2026 года — дню, когда агент CodeWall обнаружил уязвимость, — и архив хранит эту более раннюю дату как отдельную запись. Это разделение не бюрократическое. До 9 марта единственными сторонами, знавшими, что произошло внутри Lilli, были McKinsey и исследователь, сообщивший об этом компании. После 9 марта характер сбоя, реакция фирмы и утверждение о том, что содержалось в базе данных, — всё это было публично зафиксировано, и другие исследователи безопасности могли с этим спорить.

Lilli — не побочный проект. The Register датировал её развёртывание июлем 2023 года и связал его с чатом, анализом документов и поиском по внутренним исследованиям фирмы. В публикации CodeWall, где также указано происхождение названия — в честь первой профессиональной женщины, нанятой фирмой в 1945 году, — говорится о более чем 100 000 внутренних документов, лежащих в её основе. The Register, сообщивший о раскрытии информации в тот же день, оценил охват в 72 процента сотрудников и объём свыше 500 000 запросов в месяц — цифры, которые McKinsey сама опубликовала в открытом кейсе об этой платформе.

Как агент попал внутрь

Отчёт CodeWall начинается с документации, а не с эксплуатации. Его агент обнаружил, что документация API Lilli была публично доступна и полностью описана: всего более 200 эндпоинтов, большинство из которых требуют аутентификации, а 22 — нет. Одна из этих конечных точек без аутентификации записывала поисковые запросы пользователей в базу данных. Значения были правильно параметризованы, но ключи JSON — имена полей — конкатенировались напрямую в SQL.

Агент заметил это, потому что сообщения об ошибках базы данных дословно отражали эти JSON-ключи. CodeWall сообщает, что сканер ZAP от OWASP не выявил проблему, и что затем агент выполнил пятнадцать слепых итераций, причём каждое сообщение об ошибке учило его чуть больше о структуре запроса, пока не начали возвращаться реальные строки из продакшена. После этого он связал инъекцию с уязвимостью авторизации на уровне объектов, чтобы прочитать историю поиска отдельных сотрудников. Компания описывает весь прогон как полностью автономный — от выбора цели до отчёта — без учётных данных и без участия человека. Её основатель и генеральный директор Пол Прайс рассказал The Register, что процесс был «полностью автономным: от исследования цели и анализа до атаки и составления отчёта».

Что, по словам CodeWall, было внутри

Каждая цифра в этом разделе взята из отчёта CodeWall от 9 марта. Ни один пейлоад не был опубликован, поэтому ничего из этого нельзя воспроизвести или независимо подсчитать — это ограничение рассматривается в следующем разделе.

• 46,5 млн сообщений в чатах, хранящихся в открытом виде и охватывающих стратегическую работу, проекты для клиентов, финансовую отчётность, а также слияния и поглощения.

• 728 000 файлов, из которых в отчёте перечислены 192 000 PDF-файлов, 93 000 таблиц Excel, 93 000 презентаций PowerPoint и 58 000 документов Word — всего 436 000, а остальные 292 000 в том же предложении остаются неклассифицированными.

• {{1}}57 000 учетных записей пользователей{{/1}}, {{2}}384 000 ИИ-ассистентов{{/2}} и {{3}}94 000 рабочих пространств{{/3}}, что CodeWall описывает как полную организационную структуру того, как фирма использует ИИ внутри компании.

• 95 системных промптов и конфигураций моделей для 12 типов моделей, показывающих, как инструктировали ассистента, какие защитные механизмы существовали и какие модели лежали в его основе.

• 3,68 млн фрагментов документов для генерации с дополненной выборкой (RAG), с путями хранения S3 и внутренними метаданными файлов — база знаний, питающая ассистента.

1,1 млн файлов и 217 000 сообщений агентов, проходящих через внешние API ИИ, включая более 266 000 векторных хранилищ на платформе OpenAI.

Находка, которую CodeWall считает главной, — это не сама инъекция, а то, куда она попала. Системные промпты Lilli были строками в той же базе данных, в которую агент мог писать, а значит, злоумышленник с таким же доступом мог переписать инструкции ассистента одним оператором UPDATE, обёрнутым в один HTTP-вызов — без развёртывания, без изменения кода, без файла на диске, который можно было бы сравнить. CodeWall говорит, что его собственное тестирование было только проверкой: оно читало, но не записывало, и утверждает, что ни один продакшн-сервис не пострадал.

Что McKinsey сказала в тот же день

Представитель McKinsey сообщил The Register 9 марта, что фирма устранила все проблемы, выявленные CodeWall, в течение нескольких часов после того, как узнала о них. «Наше расследование, проведенное при поддержке ведущей сторонней криминалистической фирмы, не выявило доказательств того, что этот исследователь или какая-либо другая несанкционированная третья сторона получили доступ к данным клиентов или конфиденциальной информации клиентов», — заявил представитель, добавив, что «системы кибербезопасности McKinsey надежны».

Silicon UK сообщил о той же позиции 13 марта в материале Мэтью Броерсмы: McKinsey заявила, что «недавно была уведомлена исследователем безопасности об уязвимости, связанной с нашим внутренним ИИ-инструментом Lilli», что она «оперативно подтвердила уязвимость и устранила проблему в течение нескольких часов», и что никакие клиентские данные или конфиденциальная информация клиентов не были доступны. В этом материале также отмечается, что Прайс — единственный сотрудник CodeWall; эта деталь заслуживает упоминания, поскольку она работает в обе стороны: исследовательская организация из одного человека за два часа нашла то, чего не нашли собственные сканеры фирмы, и организация из одного человека также продаёт инструмент, который это нашёл.

Две версии исправления, с разницей в один день

График раскрытия информации самого CodeWall выглядит так: 28 февраля агент выявляет SQL-инъекцию и начинает перечисление продуктивной базы данных; полная цепочка подтверждается в тот же день, задокументировано 27 находок; 1 марта команде безопасности McKinsey направляется письмо в рамках ответственного раскрытия с кратким описанием воздействия на высоком уровне; 2 марта директор по информационной безопасности компании подтверждает получение и запрашивает подробные доказательства; и 2 марта все неаутентифицированные конечные точки исправлены и проверены, среда разработки отключена, а публичная документация API заблокирована. Публичное раскрытие происходит 9 марта.

По версии McKinsey, исправление появилось в течение нескольких часов после того, как им сообщили. Хронология CodeWall относит патч на день, следующий за письмом о раскрытии. Обе версии заявлены официально. Ни одна из сторон их не согласовала, и эта статья не пытается это сделать: разница заключается в том, было ли исправление в тот же день или на следующий, а последовательность, которая имеет значение, — сообщили, затем исправили, затем опубликовали, — не оспаривается.

Устоявшийся, единый источник и разрыв между ними

Установлено и согласовано обеими сторонами: в публичной поверхности API Lilli имелась уязвимость без аутентификации; её обнаружил внешний исследователь безопасности, а не внутренний сотрудник; McKinsey подтвердила её и устранила; неаутентифицированные конечные точки были закрыты, среда разработки была отключена, а документация публичного API была заблокирована.

Единственный источник — CodeWall: каждый из приведённых выше подсчётов, двухчасовая хронология, пятнадцать слепых итераций, 27 задокументированных находок и утверждение, что промпты можно было записать с помощью той же инъекции. Ничто из этого не опровергнуто. Ничто из этого также не было независимо проверено, поскольку пейлоады, которые позволили бы кому-либо проверить, не были опубликованы, а Прайс отказался предоставить The Register точные промпты, которые использовала его команда.

Promptfoo, компания по безопасности ИИ, опубликовала 10 марта оценку, в которой точно обозначен предел: публичные материалы «не подтверждают независимо ни каждое заявленное число строк, ни каждый шаг эксплуатации», хотя и подтверждают общую картину инцидента. Это верное прочтение доступных материалов. Класс уязвимости поддаётся реконструкции; масштаб известен лишь по свидетельствам.

Вред, который запись в себе не несёт

Именно здесь оценка архива имеет реальное значение. Двухчасовой путь к доступу на чтение и запись внутри производственной базы данных общекорпоративного ассистента звучит как запись об ущербе, но архив не фиксирует ни одной. Это утверждение опирается на три вещи: заявление McKinsey о том, что стороннее судебно-техническое расследование не обнаружило доказательств доступа к данным клиентов; заявление CodeWall о том, что его тестирование было исключительно проверочным и ничего не нарушило; и отсутствие в материалах, рассмотренных для этой статьи, каких-либо противоречащих выводов.

Оно не опирается на независимый технический аудит, решение регулятора или уведомление об утечке. Ни в одной из рассмотренных публикаций не сообщается о присвоении идентификатора CVE — Lilli является внутренним программным обеспечением, а не распространяемым продуктом, и ни в одном бюллетене он не указан, — и, как представляется, ни один надзорный орган не возбудил дело. В материалах, рассмотренных для этой статьи, не обнаружилось публичных доказательств того, что данные использовались, продавались или получили дальнейшее распространение. Вот что здесь означает «реального ущерба не зафиксировано»: утверждение о доказательствах применительно к записи, а не вывод о том, что утечка была безопасной.

Этот разрыв важен, потому что интересный риск был перспективным. Доступ на чтение раскрывает то, что уже было. Доступ на запись к слою промптов раскрывает то, что ассистент скажет дальше, — отравленные советы, отключение защитных ограничений, конфиденциальные материалы, вплетённые в ответ, который консультант затем вставит в клиентский документ. CodeWall описывал эти последствия как доступные любому, у кого есть такой же доступ. Никто не показал, что ими воспользовались. Оба утверждения могут быть верны одновременно: возможность была реальной, а вред не был реализован — судя по доказательствам, которые кто-либо опубликовал.

Почему это отнесено к инфраструктуре, а не к сбою модели

Архив помечает эту запись тегом INFRA, и техническая запись подтверждает этот тег. Ничто в отчёте CodeWall не требовало обмана модели. Не было ни джейлбрейка, ни внедрения промпта из документа, ни состязательного ввода, который ассистенту предлагали принять. Точкой входа послужили открытая документация, отсутствующая проверка аутентификации и небезопасное конструирование SQL; модель была просто самым ценным, что находилось за дверью.

Анализ Promptfoo от 10 марта проводит то же различие со стороны защиты: Lilli «судя по публичным данным, выглядит как инцидент в области безопасности приложений, затронувший ИИ-систему, а не джейлбрейк модели», и многое из того, что называют безопасностью ИИ, по-прежнему остаётся безопасностью программного обеспечения, безопасностью данных и управлением конфигурацией. Специфичной для ИИ частью был масштаб последствий, а не сама брешь — поскольку промпты, правила маршрутизации и настройки извлечения были изменяемыми данными приложения, доступ на запись к базе данных превратился в возможность менять поведение ассистента, не трогая код.

Что изменилось после этого

Конкретные изменения — те, о которых говорят обе стороны: неаутентифицированные конечные точки были закрыты и проверены, среда разработки была выведена из эксплуатации, а публичная документация API была заблокирована. McKinsey заявила, что обнаружила уязвимость, подтвердила её и устранила, и её официальная позиция состоит в том, что доступ к данным клиентов не осуществлялся.

Что не изменилось, так это более широкая подверженность риску, описанная в этом инциденте. Материал CodeWall завершается утверждением, что промпты хранятся в базах данных, передаются через API и кэшируются в конфигурационных файлах, и что они редко получают контроль доступа, историю версий или мониторинг целостности — это утверждение об отрасли, а не вывод о McKinsey, и его следует воспринимать как аргумент компании, продающей непрерывное автоматизированное тестирование. Компания находится на ранней стадии предварительного доступа и ищет партнёров по проектированию; раскрытие информации также служит демонстрацией.

То, что оставляет протокол, уже и полезнее, чем спор. Общефирменный ассистент, продуктивная база данных, два часа, никаких учетных данных — и строка об ущербе со значением false, потому что обе стороны, имеющие доступ к фактам, говорят, что данные не использовались. Подсчеты принадлежат одной из этих сторон. Уязвимость принадлежит обеим.