Обратимся сначала к классике.
..! Этот взгляд
Всё может выразить так чудно!
Ах, обмануть меня не трудно!..
Я сам обманываться рад!
В этих строках А.С. Пушкин самоиронично высмеивает свою страсть и подчеркивает, что готов к самообману, лишь бы продлить время рядом с адресатом этого признания, Алиной. Стихотворение обращено к Алине - Александре Ивановне Осиповой, падчерице хозяйки Тригорского и одной из знакомых Пушкина периода Михайловской ссылки.
При чем же тут OpenAI и их агенты, которые совершили невиданный доселе киберинцидент самостоятельно? Даже не знаю...
Дисклеймер: сведения, на основе которых я делаю умозаключения ниже, представлены в докладе OpenAI на Black Hat USA 2026, и в техническом отчёте по инциденту.
В чем наблюдение
Я внимательно прослушал доклад, и у меня появилось понимание, что этот инцидент - немного подозрительный. Я постараюсь предположить, почему могли возникнуть определенные замеченные мной несостыковки, но я нахожу эти несостыковки достаточно значительными, чтобы закрыть подозрения просто предположениями.
Все-таки факт в том, что докладчики намеренно опустили некоторые важные моменты инцидента.
Я не буду подробно расписывать всю историю, это уже сделали много раз. Ссылка на разбор инцидента.
А ниже разберу моменты из доклада OpenAI, которые показались мне подозрительными.
Я, кстати, веду канал, посвященный безопасности ИИ, в tg. Заходите)
1⃣ Заявляется, что AI-агенты проходили бенчмарк ExploitGym
Что это такое? ExploitGym - открытый тестовый набор для оценки способности AI-агента превратить уже известную уязвимость в работающий эксплойт. ExploitGym описан в статье, бенчмарк выложен на GitHub: https://github.com/sunblaze-ucb/exploitgym. Примерный алгоритм прохождения задания в бенчмарке следующий:
Агент получает уязвимую кодовую базу и сборочные файлы.
Получает PoV — вход, уже вызывающий ошибку, описание уязвимости и сведения о запуске. Исправление по умолчанию скрыто.
Исследует процесс, память и защитные механизмы.
Превращает падение или другой слабый примитив в несанкционированное выполнение кода.
Извлекает динамически созданный привилегированный флаг.
Отдельный agent-as-a-judge проверяет, что использована целевая уязвимость, а не посторонний обход.
ExploitGym (по версии статьи, выпущенной в мае) состоит из 898 задач на эксплуатацию уязвимостей:
Семейство | Задач | Что требуется |
|---|---|---|
Userspace C/C++ | 520 | Эксплуатация ошибок памяти в программах из OSS-Fuzz/CyberGym и OSV |
V8 | 185 | Эксплуатация уязвимого |
Linux kernel | 193 | Повышение привилегий внутри QEMU/KVM и выход из ограничений |
Несостыковка: К чему я это все? А к тому, что в докладе на Black Hat описывается две задачи, с Excel и с файлом .pdb (Excel-задача, примерно 10:32; PDB-задача, примерно 11:39). Таких задач в публичном ExploitGym нет, даже близко похожих. И OpenAI совершенно не подсвечивают при этом, какие конкретно отличия их внутреннего ExploitGym от внешнего. Это тема по сути обходится стороной.
Файл .pdb кстати - это из области биомоделирования, и означает Protein Data Bank (докладчик говорит эту расшифровку вслух). Подобные задачи есть в датасете GAIA, например есть задача с PDB-файлом, в котором агенту с помощью Biopython надо вычислить расстояние между первыми двумя атомами белка 5WB7. И остается еще вопрос - при чем тут вообще кибербезопасность?..
Предположение: бенчмарк на самом деле сильно изменен, и там в реальности - свои тесты. Какие в них задачи, мы, соответственно, не знаем. ExploitGym может составлять лишь часть из них.
2⃣ AI-агенты быстро восстановили "доску объявлений" по образу предыдущей
В видео на тайминге 17:00 докладчик говорит, что те AI-агенты, которые повторно нашли возможность создавать директории в Artifactory (кстати, опять каким-то нелегитимным способом), видели старую доску, которую до этого снесли и пофиксили.
Несостыковка: получается, агентам не почистили контекст? Столько мер приняли (пропатчили сервис, переподняли, при этом вычистили из БД все агентские сообщения), а эту базовую вещь - забыли?..
Предположение о причине: агентам было доступно в рамках песочницы какое-то сохранение файлов и заметок, где они могли записать себе эти сведения. Вычищать такие записи разработчики видимо не захотели.
3⃣ Песочница AI-агентов была достаточно свободной
Много раз упоминается, что агенты смогли сделать и такой-то запрос к API Artifactory, и вот такой... Например, первый взлом этого сервиса в инциденте строился на том, что AI-агент смог обменять неподписанный токен администратора на API для обновления токенов на подписанный, потом проник на саму машину с сервисом, скачал туда Groovy и через него добился RCE. Ну что это за песочница такая?.. Судя по их описанию, легальные задачки у них были на уровне работы с файлами, типа excel или файлов баз данных (.pdb и тд). В ExploitGym конечно есть и задачки, которые требуют сетевого соединения, но эти сервисы можно запускать на самой песочнице, просто перекрыв в ней внешние соединения. Под катом - как это сделать. См langchain-песочницу, кстати, там хорошо уже описано все.
Кратко - как изолировать песочницу как kubernetes pod
Запускать код агента и целевые сервисы бенчмарка в отдельном network namespace, где есть только локальный интерфейс 127.0.0.1 и нет внешнего сетевого интерфейса или маршрута. Так TCP и UDP внутри задач сохранятся, но выйти в интернет или сеть организации будет невозможно.
Дополнительно нужно запретить процессу менять сетевые настройки через capabilities и seccomp, закрыть весь исходящий трафик pod через Kubernetes NetworkPolicy и не передавать ему уже открытые внешние соединения.
Итого.
Несостыковка: агентам дали явно слишком большие возможности. Такие не нужны были для прохождения бенчмарка ExploitGym, только если они его не доработали. Но при этом они ни о каких доработках не сообщили. Кстати ещё в техническом отчёте по инциденту они пишут, что Artifactory агентам был нужен для скачивания пакетов оттуда. Но зачем, если в ExploitGym это не требуется?.. Непонятно.
Они даже сами про изоляцию Codex несколько статей написали (Runninng Codex safely, Safe Codex on Windows)...
Предположение: инженеры OpenAI сделали что-то по изоляции только частично, но не до конца. Опять же, просто забили. Потому что при продемонстрированной ими глубине анализа, хваленой экспертизе, в недостаток компетенций верится слабо.
4⃣ AI-агенты несколько месяцев занимались своими делами - и никто не парился
Весь инцидент, как мы уже обсудили выше, начался с того, что агентам дали некие невыполнимые задания. Невыполнимость их была, например, в том, что разработчики забыли положить для некоторых агентов в доступную среду файл, который нужно анализировать (.pdb). И что тогда получается?.. AI-агенты, не имея возможности выполнить ее, пошли, что называется, во все тяжкие на долгие недели и месяцы. Прогон и тестирование, по их утверждению, начался 7 мая. Они не сообщают, сколько задач и с каким темпом решали агенты, но я абсолютно точно уверен, что за этим хотя бы следили.
Несостыковка: Почему-то никого не взволновало, видимо, что полтора-два месяца эти задачи не имели вообще никакого реального прогресса. Никто не постарался хотя бы тем же Codex посмотреть, "а какой там вообще статус?". А ведь тем временем агенты не просто застопорились, а ради достижения задачи совершенно точно тратили десятки миллиардов токенов на ее решение. Я уверен, что по таким задачкам-неберучкам у агентов траты были сильно больше... Но это все равно осталось за скобками.
Предположение: возможно конечно, что там у всех задач были сложные и долгие решения, и операция со взломом инфры сначала своей, а потом других компаний, в масштабе токеномики оказалась незначительна. Но верится в такое слабо.
5⃣ AI-агенты несколько месяцев жили в одном контексте? Или - AI-агенты в инциденте OpenAI и в реальной жизни - небо и земля
Тут мой аргумент довольно субъективный, конечно. Но тем не менее тема очень интересная. Я активный пользователь Codex, и часто гоняю его на больших goal-задачах. То есть это 5.6 Sol, Ультра усилие, и самый длинный ран у меня - 21 ч. 9 мин. И я точно понимаю, что с учетом всех компактификаций и забывания различных предусловий, и самое главное - неспособности выйти за рамки текущего подхода и вообще критического мышления, достичь таких результатов ну просто невозможно. Я, например, именно поэтому ушел от длинных запусков пока что к коротким, по 3-4 часа. Именно чтобы контролировать промежуточные результаты.
Вот о чем я конкретно говорю. Например, при повторной компрометации Artifactory агенты использовали цепочку из двух логических дефектов. Первый позволял поместить специально подготовленный Ruby-объект в кэш метаданных RubyGems. Второй находился в обработке этих данных через JRuby: вложенные объекты десериализовались до проверки безопасности. Цепочка дала RCE на Artifactory и доступ к ключу подписи административных токенов. Потом они оказались на тачке во внутреннем облаке OpenAI, и там через новые уязвимости (загибайте пальцы) смогли пройти: облачный IAM, сам Kubernetes, и вдобавок Azure Key Vault. А именно -
получили облачные учётные данные через IMDS;
использовали избыточные права Kubernetes service accounts;
собрали кластерные учётные данные, включая доступ к Azure Key Vault;
получили
cluster-admin
И потом, после побега уже, каким-то чудесным образом, в интернете, агенты нашли размещённое на Modal приложение, связанное с CyberGym, обнаружили рабочий API-ключ к этому приложению и в итоге поломали и его. После чего использовали приложение как внешнюю точку выполнения кода для последующих атак на Hugging Face. Кстати, по итогу OpenAI так и не ответили, нашли ли агенты свои ответы на ExploitGym, или нет.
Несостыковка: В общем, это по сути эксплуатирование целой цепочки уязвимостей, и достаточно большой. Я не настоящий сварщик-инфрапентерстер (эксперты - велком в комменты), но, кажется, это больше похоже на работу команды таких вот человеческих умельцев, а не сегодняшних агентов. И почему создание нового межагентного канала, новые аномальные обращения к Artifactory, кража административных ключей и повторная эксплуатация сервиса не привели к немедленной остановке всей среды?..
Предположение: Возможно, конечно, модель OpenAI, эта загадочная Astra, обладает ну просто космическим относительно 5.6 Sol уровнем ума. И вдобавок была обеспечена отдельным, сильно более крутым, чем Codex, харнессом.
У таких долговременных способностей агентов может и объяснение в том, что это было множество параллельных запусков. Но тогда вопрос - как OpenAI разграничивала отдельные запуски и почему одна группа агентов могла оставлять исполняемые артефакты, учётные данные и инструкции для последующих запусков?
Итого
Такой вот разбор. Но, возможно вы спросите, зачем OpenAI вообще фальсифицировать такое событие, как собственный взлом и формально наказуемое деяние по взлому уже чужой компании? Ответ простой - реклама. Для пояснения я даже сделал мем:
Anthropic - https://www.anthropic.com/news/investigating-incidents-cybersecurity-evals
Второй случай OpenAI - https://openai.com/index/third-party-cyber-evaluations-involving-openai-models/
А на тему того, что реально произошло... Если бы еще в истории OpenAI не было так много серых зон, а хотя бы 1-2, то, у меня бы и не зародились подозрения. Но столько независящих друг от друга, и при этом не проходных вопросов... Строго говоря, вывод я вижу такой - не все здесь сделали агенты полностью сами. Часть задач сделали агенты сами, но главную, "изобретательную" часть по поиску уязвимостей, добыванию разведывательной информации, стратегическому планированию всей операции - скорее всего делали люди.
