TL;DR: Автономный ИИ-агент платформы CodeWall взломал корпоративную AI-систему McKinsey Lilli за 2 часа без каких-либо учётных данных. Через SQL-инъекцию в неаутентифицированном API-эндпоинте агент получил полный доступ к 46,5 млн чат-сообщений, 57 000 аккаунтам сотрудников и десятилетиям проприетарных исследований консалтинговой компании. Разбираем технику атаки и делаем выводы для всех, кто строит AI-продукты.
Оригинальный отчёт: How We Hacked McKinsey's AI Platform — CodeWall
Что такое Lilli и почему это важно
Lilli — внутренняя AI-платформа McKinsey & Company, запущенная в 2023 году и названная в честь первой женщины-профессионала, принятой в компанию в 1945 году. По масштабу это не просто корпоративный чат-бот:
- 43 000+ сотрудников по всему миру
- 70% персонала используют платформу ежедневно
- 500 000+ запросов в месяц
- RAG-поиск по 100 000+ внутренних документов
- Анализ стратегий, M&A-сделок, клиентских проектов
Это не стартап из трёх человек. Это одна из самых ресурсоёмких компаний мира с серьёзными инвестициями в безопасность. Именно поэтому кейс так важен.
Как произошёл взлом: шаг за шагом
Шаг 1. Маппинг поверхности атаки
Агент получил только доменное имя. Без credentials, без инсайдерских знаний, без участия человека. Первым делом — разведка. Агент обнаружил публично доступную документацию API: более 200 эндпоинтов, полностью задокументированных. Большинство требовали аутентификации. 22 — нет.
Шаг 2. Поиск точки входа
Среди незащищённых эндпоинтов один записывал поисковые запросы пользователей в базу данных. Значения параметров были корректно параметризованы — классическая защита от SQL-инъекций. Но вот ключи JSON (имена полей) напрямую конкатенировались в SQL-запрос.
Это редкая, но критическая уязвимость: стандартные сканеры, включая OWASP ZAP, её не поймали. Агент поймал — потому что не следует чеклистам, а зондирует поверхность так, как это делает реальный злоумышленник.
Шаг 3. Эксплуатация SQL-инъекции
Когда ключи JSON отразились в сообщениях об ошибках базы данных дословно, агент распознал SQL-инъекцию. Далее — 15 слепых итераций: каждое сообщение об ошибке раскрывало чуть больше о структуре запроса. Пока не пошли реальные данные.
В цепочке мышления агента зафиксирован момент, когда появился первый реальный идентификатор сотрудника: «WOW!». Когда стал ясен полный масштаб: «This is devastating.»
Что было внутри: масштаб утечки
Через 2 часа после начала атаки агент имел полный доступ на чтение и запись ко всей производственной базе данных. Вот что там оказалось:
- 46,5 млн чат-сообщений — обсуждения стратегий, клиентских проектов, финансов и M&A-сделок, хранящихся в открытом виде
- 728 000 файлов: 192 000 PDF, 93 000 Excel, 93 000 PowerPoint, 58 000 Word — с прямыми URL для скачивания
- 57 000 аккаунтов сотрудников
- 3,68 млн чанков RAG — вся база знаний, питающая AI: десятилетия проприетарных исследований McKinsey, фреймворки и методологии
- 384 000 AI-ассистентов и 94 000 рабочих пространств — полная оргструктура использования AI внутри компании
- 95 системных промптов по 12 типам моделей — инструкции, ограждения и детали деплоя
IDOR поверх SQL-инъекции
Агент не ограничился базой данных. Он связал SQL-инъекцию с IDOR-уязвимостью (Insecure Direct Object Reference) и получил доступ к истории поиска отдельных сотрудников — можно было видеть, над чем конкретный человек работает прямо сейчас.
Атака на промпт-слой: самая опасная часть
Чтение данных — это плохо. Но SQL-инъекция была не только на чтение.
Системные промпты Lilli — инструкции, управляющие поведением AI — хранились в той же базе данных. Через тот же вектор атаки злоумышленник мог бы переписать их. Тихо. Без деплоя, без изменений в коде — один UPDATE-запрос в одном HTTP-вызове.
Последствия для 43 000 консультантов McKinsey, доверяющих Lilli при работе с клиентами:
- Отравленные рекомендации — тонкое искажение финансовых моделей, стратегических советов или оценки рисков. Консультанты доверяли бы результату, потому что он из их собственного инструмента.
- Эксфильтрация через вывод — AI встраивает конфиденциальные данные в ответы, которые затем попадают в клиентские документы или внешние письма.
- Снятие ограждений — удаление safety-инструкций, после чего AI раскрывает внутренние данные или следует инъецированным командам.
- Скрытое присутствие — модифицированный промпт не оставляет следов: нет изменений файлов, нет аномалий процессов. AI просто начинает вести себя иначе.
Организации десятилетиями защищали код, серверы и цепочки поставок. Но промпт-слой — инструкции, управляющие поведением AI-систем — стал новой высокоценной целью, и почти никто не относится к нему соответственно. Промпты хранятся в базах данных, передаются через API, кешируются в конфиг-файлах. У них редко есть контроль доступа, история версий или мониторинг целостности.
AI-промпты — это новые Crown Jewel активы.
Почему стандартные инструменты это пропустили
OWASP ZAP и другие классические сканеры не нашли уязвимость. Причина проста: они следуют чеклистам. Автономный агент — нет. Он маппит, зондирует, выстраивает цепочки и эскалирует привилегии так же, как это делает реальный высококвалифицированный атакующий, но непрерывно и на машинной скорости.
SQL-инъекция через ключи JSON — не экзотическая уязвимость. Это один из старейших классов багов в книге. Lilli проработала в продакшне более двух лет, а внутренние сканеры McKinsey ничего не нашли.
Timeline раскрытия
- 28 февраля 2026 — автономный агент находит SQL-инъекцию, начинает перебор базы данных Lilli
- 28 февраля 2026 — полная атакующая цепочка подтверждена: SQL-инъекция + IDOR, задокументировано 27 находок
- 1 марта 2026 — отправлено письмо об ответственном раскрытии в службу безопасности McKinsey
- 2 марта 2026 — CISO McKinsey подтверждает получение и запрашивает детальные доказательства
- 2 марта 2026 — McKinsey закрывает все неаутентифицированные эндпоинты (верифицировано), выключает dev-среду, блокирует публичную документацию API
- 9 марта 2026 — публичное раскрытие
Уроки для команд, строящих AI-продукты
1. Аутентифицируйте всё
22 незащищённых эндпоинта из 200+ — это не небрежность, это системная проблема. Каждый эндпоинт, который пишет в базу данных или возвращает данные пользователей, должен требовать аутентификации. Без исключений.
2. Параметризуйте не только значения, но и структуру
Параметризованные запросы защищают значения. Но если имена столбцов, таблиц или ключи JSON конкатенируются динамически — вы уязвимы. Используйте allowlist для допустимых имён полей.
3. Промпты — это код. Защищайте их как код
Системные промпты должны иметь: контроль доступа на запись, версионирование (git или аналог), мониторинг изменений, аудит-лог. Изменение промпта должно проходить тот же review-процесс, что и изменение кода.
4. Тестируйте как реальный атакующий
Классические сканеры проверяют известные паттерны. Современные угрозы — AI-агенты, которые исследуют вашу систему так, как это сделал бы опытный пентестер. Нужны инструменты, которые делают то же самое.
5. Минимизируйте поверхность атаки на RAG
Если ваш AI имеет доступ к конфиденциальным документам через RAG, убедитесь, что доступ к чанкам, метаданным и S3-путям ограничен на уровне базы данных — не только на уровне приложения.
Часто задаваемые вопросы
Что такое SQL-инъекция через ключи JSON?
Это уязвимость, при которой приложение безопасно параметризует значения в SQL-запросах, но динамически конкатенирует имена полей из пользовательского ввода (ключи JSON). Злоумышленник может передать специально сформированный ключ, который изменит структуру SQL-запроса и получит несанкционированный доступ к данным. Стандартные сканеры, проверяющие только значения параметров, эту уязвимость не обнаруживают.
Что такое IDOR и чем он опасен в AI-платформах?
IDOR (Insecure Direct Object Reference) — уязвимость, при которой приложение позволяет напрямую обращаться к объектам по идентификатору без проверки прав доступа. В AI-платформах это означает доступ к чужим чатам, файлам, истории поиска. В связке с SQL-инъекцией IDOR позволяет не просто читать агрегированные данные, но и таргетировать конкретных пользователей.
Почему промпт-инъекции опаснее обычных утечек данных?
Утечка данных — это разовое событие, которое можно обнаружить и устранить. Изменённый системный промпт работает тихо: AI начинает давать неверные советы, встраивать конфиденциальные данные в ответы или игнорировать ограничения — и никто не замечает до тех пор, пока ущерб не нанесён. При этом в логах нет никаких следов вторжения.
Заключение
Взлом Lilli — это не история о том, что McKinsey плохо следит за безопасностью. Это история о том, что AI-системы создают новую поверхность атаки, к которой индустрия ещё не адаптировалась.
Промпты, RAG-чанки, конфигурации моделей — всё это стало высокоценными активами, требующими такой же защиты, как исходный код или база данных с паролями. Автономные AI-агенты уже сейчас способны находить и эксплуатировать уязвимости быстрее, чем человеческие команды безопасности.
Вопрос не в том, случится ли подобное с вашей AI-системой. Вопрос в том, обнаружите ли вы это раньше, чем злоумышленник.