Четыре провала. Четыре слоя. Сама архитектура является уязвимостью.

В недавнем эпизоде подкаста New York Times’ Hard Fork podcast от 10 апреля 2026 года были рассмотрены последствия кибербезопасности для передовых систем искусственного интеллекта и был поставлен вопрос, который отрасль пыталась избежать: что если кибербезопасность не работает неудовлетворительно, а фундаментально неправильно сформулирована?

Эпизод вышел в эфир через несколько недель после серии инцидентов, которые сделали ответ трудно игнорировать. За один месяц автономный агент ИИ проник в внутреннюю платформу ИИ McKinsey за два часа. Атака на цепочку поставок широко используемой открытой библиотеки ИИ привела к тому, что предприятия вниз по цепочке поставок были затронуты. Исследователи показали, что аппаратное обеспечение, предназначенное для того, чтобы быть последней линией обороны, может быть нарушено с помощью деталей, стоимостью менее тысячи долларов. Кроме того, компания Anthropic раскрыла, что передовая модель автономно обнаружила тысячи уязвимостей нулевого дня в коде, который отрасль считала стабильным.

Четыре инцидента. Четыре слоя стека ИИ: приложение, оркестрация, аппаратное обеспечение и операционная система. Каждый из них показал значительные ограничения в контролях, предназначенных для их защиты.

Конец периметральной мысли

Традиционная кибербезопасность основана на одном предположении: с достаточным количеством контролей, мониторинга и инвестиций системы можно защитить. Это предположение сформировало десятилетия архитектуры, включая брандмауэры, управление идентификацией, безопасность конечных точек и платформы SIEM, все из которых построены на идее о том, что видимость и плотное управление равны безопасности.

Сдвиг отрасли в сторону архитектуры нулевого доверия отражает растущее признание того, что традиционные сетевые границы больше не могут быть доверенными. Однако даже когда модели доверия эволюционируют, системы ИИ вводят другое испытание: чувствительные данные постоянно агрегируются, обрабатываются и делятся на нескольких слоях инфраструктуры.

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

Провал на уровне приложения: Lilli от McKinsey

9 марта 2026 года стартап в области безопасности CodeWall опубликовал раскрытие, которое подчеркнуло риски, с которыми сталкиваются организации, развертывающие ИИ внутри себя.

Автономный агент атаки CodeWall, не имеющий учетных данных, внутренних знаний или человеческого руководства, получил доступ для чтения и записи к производственной базе данных за платформой ИИ McKinsey Lilli менее чем за два часа. Lilli используется более чем 40 000 сотрудниками для стратегической работы, исследований клиентов и анализа документов, генерируя hundreds тысяч запросов в месяц.

Точка входа не была сложной. Агент обнаружил публично доступную документацию API, в которой перечислено более 200 конечных точек, 22 из которых не требовали аутентификации. Уязвимости, участвовавшие в этом, отражают риски, выделенные в OWASP Top 10 для приложений LLM, особенно вокруг открытых интерфейсов, не安全ных интеграций и чрезмерного доверия к связанным системам.

Одна из этих конечных точек содержала уязвимость к внедрению SQL, скрытую в именах полей JSON, а не в значениях ввода, где большинство автоматических сканеров ищут. Оттуда агент итерировал через слепое внедрение SQL, пока производственные данные не стали доступными.

Что он получил доступ: десятки миллионов сообщений в чате в открытом тексте, hundreds тысяч файлов, десятки тысяч учетных записей пользователей и миллионы фрагментов документов RAG, представляющих годы проприетарных исследований. Он также определил системные запросы, которые управляли поведением Lilli для каждого пользователя.

Самое тревожное открытие было не объем. Это было то, что системные запросы были доступны для записи. Атакующий мог бы незаметно переписать инструкции, управляющие выводом Lilli, отравляя стратегические советы, встраивая конфиденциальные данные в ответы или удаляя ограничители entirely, с помощью одного обновления базы данных. Никакого развертывания. Никаких изменений в коде. Никаких следов в журналах приложений.

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

Провал на уровне оркестрации: атака LiteLLM

Три недели спустя тот же шаблон появился с другого угла и через другой слой.

LiteLLM — это открытый шлюз ИИ, используемый тысячами компаний для маршрутизации запросов через поставщиков ИИ. Его позиция в стеке критична: он находится на уровне оркестрации, удерживая ключи API для каждого поставщика, к которому он подключается. Любой компромисс на этом уровне подвергает ключи уязвимости во всех интегрированных службах.

Согласно отчету инцидента PyPI, группа угроз TeamPCP эксплуатировала учетные данные, связанные с зависимостью в конвейере CI/CD LiteLLM, и использовала доступ поддержки для публикации двух версий пакета LiteLLM с бэкдором直接 в PyPI. . Зараженные версии были активны менее часа, прежде чем были удалены. Операция была обнаружена только потому, что вредоносное ПО содержало ошибку, которая вызвала сбой машины исследователя.

Цепочка поставок была вектором. Слой оркестрации был целью. Компрометируя одну зависимость вверх по потоку, атакующие достигли слоя, где ключи поставщиков каждой компании жили.

Команда LiteLLM позже подробно описала инцидент и усилия по смягчению в публичном раскрытии GitHub.

Радиус взрыва стал видимым почти сразу. TechCrunch, Fortune и The Register сообщили, что Mercor, стартап в области ИИ с объемом 10 миллиардов долларов, работающий с компаниями, включая OpenAI, Anthropic, Meta и Google, был среди пострадавших организаций. Атакующие заявили, что они получили большие объемы данных, включая профили кандидатов, личную идентификационную информацию, видеоинтервью контрактников, исходный код и ключи API. Meta приостановила работу с Mercor в ожидании расследования. Последующие сообщения указывали на подобные закономерности вредоносного ПО в других инструментах разработчика, что предполагает, что операция могла распространиться за пределы одного проекта.

Инцидент LiteLLM не был аномалией. Это было поведение системы.

Провал на аппаратном уровне: TEE.fail

Если взлом McKinsey показал, что уровень приложения не может быть доверенным, а атака LiteLLM показала, что цепочка поставок не может быть доверенной, исследование TEE.fail показало, что аппаратное обеспечение, предназначенное для компенсации обоих, не может быть полностью доверенным.

28 октября 2025 года исследователи из Georgia Tech, Purdue University и Synkhronix опубликовали TEE.fail, атаку по сторонним каналам, которая извлекает криптографические ключи из доверенных сред выполнения с помощью физического межпроцессорного взаимодействия на серверах DDR5. Атака затрагивает Intel SGX, Intel TDX и AMD SEV-SNP, включая полностью исправленные системы с включенным режимом шифрования AMD. Эти технологии широко продвигаются как основа конфиденциального вычисления.

Исследователи извлекли ключи аутентификации: криптографический материал, используемый для проверки того, что рабочие нагрузки выполняются внутри безопасных сред. С этими ключами скомпрометированная система может представить себя как доверенную, работая полностью вне ожидаемых защит. Исследователи продемонстрировали это напрямую: они подделали аутентификацию TDX на BuilderNet Ethereum, чтобы получить доступ к конфиденциальным данным транзакций, и подделали аутентификацию Intel и NVIDIA, чтобы запустить рабочие нагрузки вне любой среды доверенного выполнения, выглядя законной.

Влияние NVIDIA имеет значение для ИИ в частности. Поскольку аутентификация GPU зависит от аутентификации CPU, скомпрометированная цепочка доверия CPU может подорвать гарантии, предоставляемые конфиденциальными средами вывода ИИ. Аппаратная основа конфиденциального вывода ИИ в этой модели угрозы условна на CPU TEE, которая была демонстративно нарушена.

Производители аппаратного обеспечения ответили официальными рекомендациями. AMD заявила, что атаки с физическим доступом выходят за рамки ее стандартной модели угроз и указала, что она не выпустит обновления микропрограммы. Intel и NVIDIA признали результаты и указали на продолжающуюся работу по смягчению. Эти ответы разумны в рамках их моделей угроз. Они также подчеркивают важную границу: гарантии безопасности, основанные на аппаратном обеспечении, зависят от предположений, включая физический контроль, который суверенные, регулируемые и враждебные развертывания не могут всегда сделать.

TEE.fail не делает изоляцию аппаратного обеспечения нерелевантной. Он демонстрирует, что она условна.

Провал на уровне ОС: раскрытие Mythos

Если первые три инцидента поставили под сомнение уровень приложения, уровень оркестрации и уровень аппаратного обеспечения, четвертое раскрытие в апреле 2026 года поставило под сомнение слой под всеми ними: операционные системы и основные библиотеки, на которых работает каждый другой слой.

7 апреля 2026 года Anthropic объявила о предварительном просмотре Claude Mythos, передовой модели, которую она отказалась выпустить публично из-за ее возможностей по безопасности, и одновременно запустила проект Glasswing, консорциум с AWS, Apple, Broadcom, Cisco, CrowdStrike, Google, JPMorgan Chase, Linux Foundation, Microsoft, NVIDIA и Palo Alto Networks. Anthropic сообщила, что за несколько недель Mythos автономно выявил тысячи ранее неизвестных уязвимостей в основных операционных системах и веб-браузерах и был способен производить рабочие эксплойты для многих из них.

Конкретные результаты труднее игнорировать, чем любой обзор предполагает. 27-летняя ошибка в OpenBSD. 17-летняя уязвимость удаленного выполнения кода в сервере NFS FreeBSD, теперь отслеживаемая как CVE-2026-4747, которая предоставляет доступ к корню неавторизованному атакующему. 16-летняя уязвимость в FFmpeg, одной из наиболее широко развертываемых медиабиблиотек в Интернете. В одном случае инженер Anthropic без формальной подготовки по безопасности попросил модель найти уязвимости удаленного выполнения кода за ночь и проснулся с полным рабочим эксплойтом.

Это результаты на уровне операционной системы. OpenBSD и FreeBSD — это ядра. NFS — это подсистема сетевого ядра. FFmpeg — это системная библиотека, которая поставляется с большинством дистрибутивов Linux и лежит в основе медиапайплайнов по всему Интернету. Слой ОС считался безопасным не потому, что он был доказан безопасным, а потому, что обнаружение глубоких ошибок в нем требовало редкой и дорогой человеческой экспертизы. Это предположение было лучшей доступной эвристикой. Это никогда не было гарантией.

Это ограничение теперь ослаблено. Anthropic сама сформулировала это как двойной сдвиг: те же возможности, которые позволяют передовой модели обнаруживать и исправлять уязвимости в масштабе, также позволяют ей, в неправильных руках, обнаруживать и эксплуатировать их в масштабе. Решение Anthropic ограничить доступ через проект Glasswing отражает эту реальность. Это не решает ее. Аналогичные возможности, по оценке компании, будут распространяться. Стоимость аудита устаревшего кода рухнула, и с ней неявная защита, что такой код был слишком неясным, слишком старым или слишком широко рассмотренным, чтобы все еще содержать критические ошибки.

Это также то место, где четыре инцидента складываются. Три предыдущих инцидента описывают, как системы ИИ нарушаются сегодня. Mythos описывает скорость, с которой все, что находится под ними, включая операционные системы, модули ядра и системные библиотеки, скоро будет переоценено машинами. Взлом McKinsey использовал класс уязвимости внедрения SQL, который существовал более двух десятилетий. Уязвимости такого возраста являются именно тем, что модели класса Mythos демонстративно способны находить в промышленных масштабах.

Шаблон

В каждом случае данные были в открытом тексте в момент, когда это имело значение.

Уровень приложения обрабатывал его в открытом виде. Уровень оркестрации маршрутизировал его в открытом виде. Уровень аппаратного обеспечения, несмотря на свои защиты, в конечном итоге требовал расшифровки в момент выполнения. Слой ОС под всеми тремя работал с ним в открытом виде по определению. Четыре слоя, четыре провала, и на каждом слое то же условие выполнялось: когда произошел взлом, данные были читаемыми.

Это не коллекция изолированных провалов. Это архитектура сама по себе.

Современные системы ИИ предназначены для работы с читаемыми данными. Каждый слой, включая извлечение, маршрутизацию, вывод и выполнение инструментов, требует доступа к открытым данным, чтобы функционировать. Этот выбор дизайна означает, что любой взлом на любом слое подвергает данные, находящиеся за ним, опасности.

Вопрос не в том, будет ли скомпрометирован слой. Это то, что атакующий находит, когда он компрометируется.

От предположения о взломе к нулевому воздействию

Отрасль уже начала сдвигаться от «предотвращения взлома» к «предположению взлома». Но большинство архитектур не последовали за последствиями.

Если взлом неизбежен, то реальный вопрос не в том, как giữ атакующих вне системы. Это то, что происходит, когда они попадают внутрь. Сейчас ответ прост: они получают данные. Потому что, несмотря на все инвестиции в инфраструктуру безопасности, данные все еще подвергаются воздействию в тот самый момент, когда они становятся ценными, когда они используются.

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

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

Прогресс в полностью гомоморфном шифровании и других методах сохранения конфиденциальности делает архитектуры, которые минимизируют или исключают воздействие открытого текста, все более практичными для реальных рабочих нагрузок ИИ. Хотя остаются значительные проблемы с производительностью, масштабируемостью и реализацией, цель фундаментально отличается от традиционных средств контроля безопасности: снижение ценности успешной компрометации, а не просто снижение вероятности компрометации.

Сдвиг не от одного средства безопасности к другому. Это от защиты систем к снижению воздействия. От доверенной инфраструктуры к нулевому доверию к данным. От управления рисками к минимизации самой поверхности атаки.

Что дальше

Обсуждение Hard Fork подняло вопрос о том, является ли кибербезопасность фундаментально неправильно сформулированной. Доказательства за последние несколько недель предполагают, что ответ — да, по крайней мере для ИИ.

Старая модель предполагала, что системы можно защитить, взломы можно сдержать, а воздействие можно управлять. Возникающая реальность заключается в том, что взломы должны быть предположены, а воздействие минимизировано. Инциденты, описанные здесь, предполагают, что безопасность систем ИИ может все больше зависеть от снижения количества чувствительных данных, доступных при сбое контроля.

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

Безопасность ИИ больше не заключается в том, чтобы держать атакующих вне системы. Это заключается в том, чтобы гарантировать, что, когда они попадают внутрь, и они попадут, нет ничего читаемого для них, чтобы найти.