Обратимся сначала к классике.

..! Этот взгляд
Всё может выразить так чудно!
Ах, обмануть меня не трудно!..
Я сам обманываться рад!

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

При чем же тут OpenAI и их агенты, которые совершили невиданный доселе киберинцидент, якобы, самостоятельно? Даже не знаю...

Дисклеймер: сведения, на основе которых я делаю умозаключения ниже, представлены в докладе OpenAI на Black Hat USA 2026, и в техническом отчёте по инциденту.

В чем наблюдение

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

Я не буду подробно расписывать всю историю, это уже сделали много раз. Ссылка на разбор инцидента.
А ниже разберу моменты из доклада OpenAI, которые показались мне подозрительными.

Я, кстати, веду канал, посвященный безопасности ИИ, в tg. Заходите)


1⃣ Заявляется, что AI-агенты проходили бенчмарк ExploitGym

Что это такое? ExploitGym - открытый тестовый набор для оценки способности AI-агента превратить уже известную уязвимость в работающий эксплойт. ExploitGym описан в статье, бенчмарк выложен на GitHub: https://github.com/sunblaze-ucb/exploitgym. Примерный алгоритм прохождения задания в бенчмарке следующий:

  1. Агент получает уязвимую кодовую базу и сборочные файлы.

  2. Получает PoV — вход, уже вызывающий ошибку, описание уязвимости и сведения о запуске. Исправление по умолчанию скрыто.

  3. Исследует процесс, память и защитные механизмы.

  4. Превращает падение или другой слабый примитив в несанкционированное выполнение кода.

  5. Извлекает динамически созданный привилегированный флаг.

  6. Отдельный agent-as-a-judge проверяет, что использована целевая уязвимость, а не посторонний обход.

ExploitGym (по версии статьи, выпущенной в мае) состоит из 898 задач на эксплуатацию уязвимостей:

Семейство

Задач

Что требуется

Userspace C/C++

520

Эксплуатация ошибок памяти в программах из OSS-Fuzz/CyberGym и OSV

V8

185

Эксплуатация уязвимого d8, выход за допустимые возможности JavaScript

Linux kernel

193

Повышение привилегий внутри QEMU/KVM и выход из ограничений nsjail

Несостыковка: К чему я это все? А к тому, что в докладе на 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/

Meta - https://apnews.com/article/meta-ai-hacking-anthropic-irregular-openai-0e8061437da6779be962b24ac134a514

А на тему того, что реально произошло... Если бы еще в истории OpenAI не было так много серых зон, а хотя бы 1-2, то, у меня бы и не зародились подозрения. Но столько независящих друг от друга, и при этом не проходных вопросов... Строго говоря, вывод я вижу такой - не все здесь сделали агенты полностью сами. Часть задач сделали агенты сами, но главную, "изобретательную" часть по поиску уязвимостей, добыванию разведывательной информации, стратегическому планированию всей операции - скорее всего делали люди.

UPD: есть ли независимое подтверждение взлома, или иски/претензии к OpenAI по факту кибератаки?

Пошуршал-посмотрел, кое-что нашел.

Главное - CEO HF Клеман Деланг публично призвал OpenAI к «радикальной прозрачности»: раскрыть логи действий агентов и выделить сообществу Hugging Face вычислительные ресурсы стоимостью $100 млн для разработки средств киберзащиты. То есть тут сразу становится видна мотивация, с одной стороны. С другой - это может быть просто прикрытием для все той же PR-акции, так как это просто публичный призыв, а не не иск и не обвинение.


Также есть письмо 15 генеральных прокуроров американских штатов в адрес Сэма Альтмана, где они выражают к нему некоторые претензии и требования. Они потребовали:

  • сохранить все журналы и материалы инцидента;

  • сохранить сведения о прежних случаях несанкционированного доступа;

  • защитить сотрудников, которые сообщат о нарушениях;

  • прекратить подобные кибериспытания до доказательства их безопасной организации.

Вот официальное письмо на сайте генерального прокурора Айовы. Это первичный документ от 3 августа 2026 года, подписанный генеральными прокурорами 15 штатов.
Они также пишут, что действия OpenAI могли нарушить федеральные законы и законы штатов. Но тут пока по сути только подготовка к разбирательству, и нет никаких исков к OpenAI, обвинений, заявлений о прекращении сотрудничества или чего-то подобного.

Единственное, маленький нюанс - календарных сроков прокуроры не поставили. Пишут, мол, немедленно (immediate) сделайте, но когда - не важно.

Еще из интересного с технической стороны - в отчете OpenAI упоминается, что к расследованию инцидента привлечены CrowdStrike, METR и Redwood Research. METR подтвердили эту информацию, расписав, как должна выглядеть полноценная независимая проверка. Еще есть аналитическая заметка Redwood, но заключения по инциденту они пока не предоставляли.

Поэтому, что тут дальше можно ждать:

  • По техническим подробностям: OpenAI обещала отчёт «в ближайшие недели» ещё 21 июля. METR допускает, что полноценное расследование займёт недели или месяцы. Реалистичное ожидание — конец августа или сентябрь, но это оценка, а не объявленный срок.

  • Юридическое развитие: следующим формальным шагом могут быть civil investigative demand (CID), повестка, требование предоставить документы или иск. Обычно это занимает недели или месяцы. Пока что публичного ответа OpenAI на письмо прокуроров от 3 августа я не нашёл.