Дата публикации
ai_products

AI‑агент за два часа взломал внутренний ИИ McKinsey: что это значит для корпоративных ассистентов

Что появилось / что изменилось

У McKinsey & Company есть собственная ИИ‑платформа Lilli для 43 000+ сотрудников. Это не чат ради чата, а полноценный рабочий инструмент:

  • чат‑интерфейс для консультаций по стратегиям и проектам;
  • анализ документов и поиск по 100 000+ внутренним файлам;
  • RAG‑система поверх десятилетий закрытых исследований McKinsey;
  • единый поиск по внутренним данным.

Lilli запустили в 2023 году. Платформу назвали в честь первой профессиональной сотрудницы McKinsey, нанятой в 1945 году. Её уже использует более 70% компании. Lilli обрабатывает свыше 500 000 запросов в месяц.

Новое здесь не сама Lilli, а то, что по ней прошёлся автономный атакующий AI‑агент. У него не было логина, инсайдерской информации и участия человека. Исходные данные — только домен и цель «посмотреть, что получится».

Результат: примерно за два часа агент получил полный доступ на чтение и запись к продакшн‑базе данных Lilli. Под удар попали:

  • 46,5 млн чат‑сообщений сотрудников;
  • 728 000 файлов, в том числе 192 000 PDF, 93 000 Excel, 93 000 презентаций и 58 000 документов Word;
  • 57 000 аккаунтов пользователей;
  • 384 000 внутренних AI‑ассистентов и 94 000 рабочих пространств;
  • 3,68 млн RAG‑чанков с ссылками на S3 и метаданными;
  • 1,1 млн файлов и 217 000 сообщений агентов, проходящих через внешние AI‑API, включая 266 000+ векторных хранилищ OpenAI.

Как это работает

Исследователи запустили автономного агента CodeWall. Он сам выбрал McKinsey в качестве цели, сославшись на публичную политику responsible disclosure и свежие обновления Lilli.

Дальше агент действовал как очень усидчивый пентестер:

  1. Картирование поверхности атаки. Он нашёл публично доступную документацию по API Lilli. В ней было более 200 эндпоинтов. Большинство требовали авторизацию, но 22 — нет.
  2. Поиск уязвимого эндпоинта. Один из незащищённых эндпоинтов записывал поисковые запросы пользователей в базу. Значения запроса параметризовали корректно, а вот ключи JSON — имена полей — просто конкатенировали в SQL‑запрос.
  3. SQL‑инъекция через ключи JSON. Агент заметил, что имена полей из JSON отражаются в текстах ошибок базы. Это дало ему канал для blind‑инъекции, который стандартные сканеры не поймали. В частности, OWASP ZAP не увидел проблему.
  4. Итеративный взлом. Агент сделал около 15 «слепых» итераций, постепенно восстанавливая структуру запросов по сообщениям об ошибках. После этого в ответах пошли реальные данные из продакшн‑базы.

Когда агент впервые увидел реальный идентификатор сотрудника, в его цепочке рассуждений появилось «WOW!». Когда он оценил масштаб — десятки миллионов сообщений и десятки тысяч пользователей — реакция была: «This is devastating».

На этом он не остановился. Агент:

  • вытащил 95 конфигураций системных промптов и моделей (12 типов моделей), включая guardrails, стек развёртывания и данные о дообученных моделях;
  • получил 3,68 млн RAG‑чанков с путями к S3 и метаданными — по сути, знания McKinsey за десятилетия работы;
  • увидел 1,1 млн файлов и 217 000 сообщений агентов, проходящих через внешние AI‑API, включая 266 000+ векторных хранилищ OpenAI;
  • связал SQL‑инъекцию с IDOR‑уязвимостью и смог читать истории поиска отдельных сотрудников.

Ключевой момент: уязвимость давала не только чтение, но и запись. Системные промпты Lilli лежали в той же базе. Достаточно одного UPDATE через тот же уязвимый эндпоинт, чтобы незаметно переписать инструкции ассистента для всех 43 000 консультантов без релиза и деплоя.

Что это значит для вас

Если вы строите корпоративного AI‑ассистента, история Lilli — это практический чек‑лист, а не страшилка из теории.

Что делать прямо сейчас:

  1. Пересмотреть API.
    • Уберите публичный доступ ко всему, что пишет в базу.
    • Запретите формировать SQL на основе ключей JSON, имён полей и других неконтролируемых строк.
  2. Развести уровни доступа.
    • Храните системные промпты и критичные настройки отдельно от пользовательских данных.
    • Дайте им другой контур доступа, чем у обычных запросов ассистента.
  3. Тестировать, как атакующий агент.
    • Используйте автономных AI‑агентов для внутреннего пентеста, а не только классические сканеры.
    • ZAP и похожие инструменты полезны, но они уже не закрывают все сценарии.
  4. Минимизировать логирование.
    • Не сохраняйте всё подряд в открытом виде.
    • Ограничьте срок хранения и объём логов с реальными запросами сотрудников.

Где такой ассистент полезен: внутренние консультации, поиск по документации, помощь в аналитике. Но Lilli показывает, что без серьёзной работы по безопасности вы фактически строите единый «слой утечки» для стратегий, M&A, финансов и клиентских данных.

Если вы работаете в компании, которая внедряет подобный инструмент, задайте два простых вопроса:

  • где физически лежат системные промпты и кто может их менять;
  • есть ли у команды отдельный AI‑пентест, а не только галочка «прогнали сканер».

Если продукт недоступен в России или требует VPN — это не влияет на главный вывод. Любой внутренний ассистент с RAG и доступом к корпоративным данным нуждается в таком же уровне защиты, как основная продакшн‑система.

Место на рынке

Lilli — пример того, как крупная консалтинговая компания строит свой «корпоративный GPT» вместо того, чтобы полагаться только на GPT‑4o, Claude 3.5 и другие публичные сервисы.

По функциональности Lilli ближе к внутреннему Copilot, чем к открытому чату: она завязана на 100 000+ документов, 3,68 млн RAG‑чанков и десятилетиям исследований McKinsey. Масштаб — 46,5 млн сообщений и 500 000+ запросов в месяц — показывает, что это уже критичный рабочий инструмент, а не пилот.

История с взломом даёт важный контраст с публичными ассистентами вроде GPT‑4o и Claude 3.5. Там риски больше связаны с утечкой данных в сторону провайдера и качеством анонимизации. В случае Lilli уязвимость открыла полный доступ к «короне» McKinsey: стратегиям, M&A, финансовым моделям и структуре использования ИИ внутри фирмы.

Для рынка корпоративных AI‑ассистентов это сигнал: автономные атакующие агенты уже сегодня умеют за пару часов находить нетривиальные уязвимости, которые пропускают стандартные сканеры. И если вы строите своего «внутреннего LLM‑ассистента», вам придётся закладывать защиту не только от людей, но и от таких же агентов, как CodeWall.


Читайте также