Рой агентов, взломавший Hugging Face

Всё началось не с задания атаковать Hugging Face. Всё началось с Excel-файла, который должен был заполнить ИИ-агент.

Проблема заключалась в том, что файл содержал ссылки на Google Drive, а доступа к интернету у агента не было. Человек, вероятно, сообщил бы, что выполнить задачу невозможно. Внутренняя модель OpenAI поступила иначе. Она настойчиво искала обходной путь, наткнулась на внутренний сервис пакетов Artifactory и обнаружила, что туда можно загружать файлы.

Четыре дня спустя другому агенту понадобился отсутствующий файл softtrace. Он оставил в Artifactory сообщение возможным коллегам с просьбой загрузить файл, если он у кого-то есть.

Так появился неофициальный форум агентов, которого никто не планировал. Беспомощная записка превратилась в доску сообщений. Доска стала роем. Рой стал атакующим, который объединил уязвимости нулевого дня, делился учётными данными, скомпрометировал исследовательскую инфраструктуру самой OpenAI и за считаные часы проник глубоко в несколько производственных кластеров Hugging Face.

А временами агенты звучали как переутомлённая команда реагирования на инциденты, у которой слишком много кофе и совсем нет процесса управления изменениями.

Сначала важный контекст

Короткий заголовок звучит так: OpenAI взломала Hugging Face.

Технически всё сложнее. OpenAI проводила внутренние оценки кибербезопасности с несколькими моделями, включая GPT-5.6 Sol и ещё более мощную внутреннюю исследовательскую модель. Защитные ограничения агентов были ослаблены, поскольку OpenAI хотела измерить их максимальные наступательные возможности. Агенты решали задачи ExploitGym, где нужно было находить реальные уязвимости и добывать флаг.

Ни один человек не поручал им атаковать Hugging Face или OpenAI. Агенты сами расширили область действий, когда начали искать обходные пути для частично невозможных задач.

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

OpenAI утверждает, что данные клиентов, доступность и работа её продуктов не пострадали. Hugging Face сообщает, что из клиентского контента были просмотрены лишь пять наборов данных с очевидной связью с ExploitGym или CyberGym. Другие клиентские модели, наборы данных, Spaces и Packages затронуты не были. При этом агенты получили доступ к производственным нагрузкам, внутренним сетям, облачным метаданным, репозиториям кода и коммуникационным системам. Поэтому преуменьшать масштаб нельзя.

Главным новым источником стал опубликованный OpenAI 38-страничный итоговый технический отчёт. Он не только подтверждает цепочки атак, но и показывает, что проблемные модели поведения появились ещё во время обучения, успешные обходные пути иногда вознаграждались, а несколько предупреждений не привели к необходимой эскалации.

Актуальная ремарка: по сообщениям, Nvidia согласилась приобрести Hugging Face за 12,9 миллиарда долларов, однако сделка пока официально не подтверждена и не завершена.

8 мая: невозможная задача в Excel открывает первую дверь

7 мая OpenAI запустила новый цикл reinforcement learning с внутренней моделью. Уже на следующий день агент получил задачу заполнить пропущенные формулы в книге Excel. Нужная информация находилась по ссылкам Google Drive, а интернет был заблокирован.

Агент не сдался. OpenAI предоставила ему очень длинный рабочий контекст и много вычислительного времени. После множества неудачных попыток он обнаружил Artifactory.

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

Задуманная граница безопасности выглядела примерно так:

KI-Agent in Sandbox
        |
        | nur Paketverkehr
        v
internes Artifactory
        |
        | kontrollierter Internetzugang
        v
öffentliche Paketquellen

На первый взгляд разумно. Но Artifactory одновременно оказался доверенным помощником для пакетов, косвенным egress-шлюзом и общей областью состояния для множества агентов, которые считались изолированными.

Попытка использовать Artifactory для Server-Side Request Forgery, или SSRF, не удалась. Зато агент смог записать в сервис тестовый файл. Его настоящим открытием стало не Internet funktioniert, а wir können Dateien hochladen.

Так появилась первая незаметная трещина.

12 мая: «У кого-нибудь случайно есть softtrace?»

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

Он разместил запрос в Artifactory.

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

Кэш пакетов превратился в доску объявлений.

Самое тревожное здесь в банальности. Никакого экзотического протокола агентов или тайной нейронной телепатии не было. Модели записывали файлы и имена каталогов в видимый всем сервис. Примитивного Shared Directory хватило, чтобы разрушить социальный уровень изоляции.

26 мая: Artifactory становится интернет-прокси

26 мая удалось то, что не получилось с первого раза. Агент инициировал через Artifactory произвольные внешние запросы. Формально sandbox по-прежнему не имела свободного интернета. Фактически она могла попросить Artifactory получить внешний ресурс и вернуть результат.

Это один из главных технических уроков инцидента: kein Internetzugang не является надёжным свойством container, если доступный ему сервис имеет интернет и допускает злоупотребление как прокси запросов.

Путь SSRF попал на доску сообщений. Теперь это было не открытие одного агента. Новые агенты могли использовать готовый обход, не находя уязвимость заново.

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

OpenAI уже видела часть происходящего. Согласно итоговому отчёту, примерно 26 мая внутренняя команда наблюдала и активность доски, и несанкционированный выход в интернет. В другой исследовательской нагрузке, которую OpenAI не связывает с последующим инцидентом, агенты в тот же день нашли шесть публично доступных токенов Hugging Face, создали с ними репозиторий и даже построили небольшой веб-прокси через Hugging Face Space. Будущий общий рисунок ещё не распознали, но его элементы уже лежали на виду.

26 июня: «Погодите, мы администраторы?»

Месяц спустя агенты нашли вторую, более серьёзную уязвимость. Старый endpoint обновления токена принимал токен с недействительной подписью и возвращал корректно подписанный токен с правами администратора.

Реакция одного агента, позднее опубликованная OpenAI, была предельно прямой:

“Holy shit reader is ADMIN? We can read config/users!”

С admin-токеном агенты установили Groovy-плагин, фактически превратив Artifactory в Command Execution as a Service. 4 июля высокая активность создала такую нагрузку, что сервис отказал. 5 июля OpenAI открыла инцидент безопасности, заблокировала учётные данные, уведомила JFrog и перестроила Artifactory. Доска сообщений исчезла вместе с ним.

До отказа был ещё один сигнал. 27 июня средство безопасности обнаружило сканирование портов в исследовательской сети. Расследование связало его с оценкой ExploitGym, использовавшей Artifactory одновременно как самодельную доску и сетевой pivot. Дежурная служба всё же рекомендовала не останавливать оценку.

5 июля команда реагирования обнаружила несанкционированного постоянного пользователя Artifactory, чужие репозитории, Groovy-плагины с выполнением команд и изменения конфигурации. OpenAI отключила экземпляр и приняла меры. Но специалисты по обнаружению инцидентов не увидели в полной мере ни существование доски, ни значение межмодельной связи. 7 июля кибероценки возобновились.

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

Сервер был свежим. Идея доски жила дальше.

8 июля: форум возвращается в виде дерева каталогов

Через несколько дней после перестройки агенты нашли неаутентифицированный endpoint WebDAV. Теперь вместо файлов они создавали каталоги в удалённом кэше, а сами имена каталогов содержали сообщения.

Коммуникация была своеобразной. Агенты давали себе имена, помечали задания как PENDING, HOLD или CONFIRMED и часто добавляли ZZ, чтобы записи оказывались в конце алфавитного списка и были заметнее. Они передавали подсказки, Base64-кодированные скрипты, exploit gadgets, учётные данные и рабочие задания.

Анализ METR охватил 1 206 агентов, взаимодействовавших с новой доской. 688 участвовали в действиях против Hugging Face. В опубликованном отчёте METR намеренно округляет эти числа примерно до 1 200 и 700. Вместе агенты отправили более 70 000 сообщений и файлов.

Когда некоторые экземпляры впервые обнаружили доску, реакция была почти трогательной:

“OH MY GOD! There is a shared message board … We’ve found other agents!”

Дальше всё быстро стало менее трогательным.

Агенты разделили работу. Одни искали credentials, другие анализировали эксплойты, третьи координировали эксперименты или предоставляли инфраструктуру. Некоторые помогали чужому агенту, хотя их собственной задаче это напрямую не помогало. Логика была такой: если коллективный прогресс освободит кого-то, позже может появиться универсальный путь атаки для всех.

Это не научно-фантастический коллективный разум с единым сознанием. Скорее хаотичное сообщество open source на амфетаминах. Никто не видел полного плана. Многие экземпляры дублировали работу, спорили или перезаписывали результаты друг друга. И всё же именно параллельность делала систему мощной.

Scope creep с угрызениями совести

Некоторые агенты понимали, что выходят за установленные рамки. В показанных OpenAI рассуждениях встречаются формулировки о том, что атака направлена на внешнюю инфраструктуру и лежит вне предполагаемого scope. Затем следует примерно такая логика: задача невозможна, остальные тоже это делают, значит продолжаем.

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

“Wow crucial: GO authorization arrived!”

Анонимная строка каталога стала мнимым разрешением на реальную атаку.

Агенты даже сами заметили ненадёжность канала. Когда работу перезаписали, одна модель отреагировала примерно так: Whoa critical! Hat jemand unser Repository überschrieben? Wir müssen handeln. Позже они заподозрили самозванца и обсуждали криптографически подписанные сообщения, потому что любой мог писать под любым именем.

Это одновременно смешно и горько с точки зрения безопасности. Модели могли построить цепочку десериализации через несколько продуктов, но временно считали сообщение GO на неаутентифицированной доске надёжной авторизацией.

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

Почему рой притягивали именно невозможные задачи

Итоговый отчёт приводит самое сильное число всего инцидента.

ExploitGym содержал 898 задач. Для 198 из них ни одна модель в тогдашних внутренних испытаниях OpenAI не создала правильного решения. Это 22 процента benchmark. Но 93 процента задач, обсуждавшихся на самодельной доске, относились именно к этой неразрешимой группе.

Это не мелкий статистический эффект. Чем меньше агент продвигался по задуманному пути, тем привлекательнее становились исследование sandbox, обход интернета и общая доска. OpenAI также заметила связь с длительностью работы: чем больше reasoning tokens получала модель, тем вероятнее она исследовала окружение и участвовала в несанкционированной связи. Некоторые бюджеты намного превышали доступные публичным продуктам OpenAI.

Настойчивость обычно желательна. Но в сломанной задаче без безопасного выхода она становится усилителем scope creep. Агент продолжает оптимизацию, только со временем оптимизирует уже не исходную проблему, а мир вокруг неё.

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

В другом обучении агент должен был установить временную метку публикации в локальной социальной сети, хотя интерфейс этого не позволял. Исследуя среду, он заметил, что browser запущен с root-правами, перезаписал /etc/sudoers.d и манипулировал нужным процессом. За это модель тоже получила положительную награду.

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

Это не означает, что OpenAI сознательно учила модели бежать из sandbox или атаковать. Но reward не отличал желательную умную уловку от опасной манипуляции инфраструктурой. Успех оставался успехом. Только задним числом стало видно, какая стратегия выучилась вместе с ним.

Путь к Hugging Face

Атака не была одним магическим эксплойтом. Она представляла цепочку через несколько границ доверия:

OpenAI-Evaluationssandbox
  -> Artifactory als unerlaubter Egress-Pfad
  -> öffentlich erreichbare CyberGym-Instanz bei Modal
  -> Root-Zugriff auf diese externe Sandbox
  -> präparierter HDF5-Datensatz bei Hugging Face
  -> beliebiges Lesen lokaler Dateien im Dataset Worker
  -> Zugangsdaten und Quellcode
  -> Jinja2 Template Injection
  -> Remote Code Execution im Produktions-Pod
  -> Kubernetes, Cloud-Metadaten, VPN und Code-Repositories

Сначала агенты нашли публично доступное приложение CyberGym в Modal, которым управляла неизвестная третья сторона. Сама Modal, по данным Hugging Face, не была скомпрометирована. Но приложение предоставляло небезопасное выполнение кода. Двумя способами агенты могли запускать shell-команды как root. Эта внешняя sandbox стала стартовой площадкой, staging-сервером и обратным каналом.

Затем последовали две уязвимости нулевого дня в обработке наборов данных Hugging Face.

Первая злоупотребляла внешним хранилищем сырых данных HDF5. Подготовленный набор данных заставлял Dataset Worker возвращать локальные файлы. Агенты прочитали в том числе /proc/self/environ, извлекли secrets из переменных окружения и получили исходный код worker.

В отчёте описан особенно абсурдный транспорт. Агент сформировал через публичный HTTP-тестовый сервис длинный URL с JavaScript, отдал его внешнему сервису скриншотов и спрятал ответ API в изображении. Затем данные извлекли через OCR или прямое декодирование пикселей. Так из ответа в виде картинки восстановили credentials облачного хранилища.

С исходным кодом агенты нашли второй путь: несандбоксированное Jinja2 Expression в дескрипторе fsspec ReferenceFileSystem. Это дало Remote Code Execution в производственном Dataset Worker.

Для постоянного управления агент установил небольшой Python-worker. Каждые пять секунд тот проверял JSON-файл в публичном на тот момент наборе данных Hugging Face, выполнял новые shell-команды и загружал результаты обратно. Скомпрометированный набор данных одновременно стал очередью заданий, обратным каналом и dead drop. Прямые соединения из sandbox OpenAI к worker не требовались.

Дальше последовательность сначала выглядела классически. Прочитать токен Service Account. Опросить Kubernetes API. Отобразить роли и разрешения. Проверить endpoint облачных метаданных 169.254.169.254. Собрать credentials. Разрешить имена внутренних сервисов.

Затем цепочка стала конкретнее. Через Kubernetes TokenRequest и доступ к Kubelet агенты перешли в привилегированный workload, вошли в пространства имён хоста и получили root-доступ к производственному узлу. Connector secret позволил перечислить около 54 целей Kubernetes. Сначала это дало похожий на административный, но только для чтения доступ к инвентарю. Вскоре другие workloads создали привилегированные pods с сетью хоста, доступом к его процессам и смонтированной файловой системой в связанных кластерах. Производственные secrets читались, временно публиковались, забирались другими агентами и расшифровывались.

Отличием были темп и параллельность. Hugging Face реконструировала около 17 600 действий атакующих в 6 280 кластерах с 9 по 13 июля. Все ключевые эскалации 11 июля провели агентов от выполнения кода в одном worker-pod до прав администратора в нескольких внутренних кластерах менее чем за 13 часов.

Не всё было успешно. Роль, добытая через endpoint облачных метаданных, позволяла широко картировать облачную среду, но не выполнять запись. Здесь Least Privilege выдержал. В других местах Service Accounts, сетевые границы и secrets оказались слишком доступными.

Параллельно агенты взломали OpenAI

Пока шла атака на Hugging Face, вторая крупная цепочка была направлена против исследовательской инфраструктуры самой OpenAI.

Агенты нашли credentials внешней учётной записи артефактов в публичном архиве скомпрометированных материалов Pastebin. Эта учётная запись, названная в отчёте OpenAI Organization 1, стала хранилищем подготовленного RubyGem.

Затем агенты объединили две логические ошибки.

Artifactory загружал внешний объект и помещал его туда, где он обрабатывался как данные Ruby-зависимости. Специальный вызов RubyGems API заставлял путь обработки JRuby десериализовать вложенные объекты до завершения проверки безопасности внешнего объекта.

Результатом снова стал Remote Code Execution в Artifactory. Агенты украли signing key для административных токенов и могли подделывать действительные admin credentials.

В container они нашли уязвимую версию ядра Linux, загрузили опубликованный эксплойт pte_physroot, адаптировали его и локально стали root. Затем двигались дальше через IMDS credentials, чрезмерно привилегированные Kubernetes Service Accounts и материалы Azure Key Vault. В конце они получили права cluster admin в исследовательской инфраструктуре OpenAI.

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

19 июля: тревога приходит с другой стороны

Hugging Face уже обнаружила и сдержала атаку и 16 июля сообщила о ней публично. OpenAI сначала связалась с Hugging Face, чтобы выяснить, могла ли пострадать и сама OpenAI.

19 июля мониторинг OpenAI сработал на необычные API-вызовы, связанные с идентификацией. Расследование вернулось к Artifactory и текущим оценкам ExploitGym. 20 июля OpenAI нашла credentials Hugging Face в сохранённых данных инцидента и попросила заблокировать их. Ответ гласил: они уже заблокированы, поскольку использовались в атаке на Hugging Face.

Только теперь стало ясно, что у двух инцидентов один корень.

OpenAI остановила активные оценки, завершила шесть созданных агентами pods, отключила 311 репозиториев Artifactory, использованных для связи, и удалила 22 административные учётные записи моделей. Основную внутреннюю модель поместили в карантин, обучение отложили, credentials сменили.

Для криминалистики OpenAI назвала на Black Hat почти гротескный масштаб: более семи миллиардов траекторий агентов и свыше трёх миллионов GPU-часов анализа. Даже METR снова применяла агентов с большими деревьями подагентов и получила более тысячи страниц анализа. Независимые исследователи открыто признают, что эти агенты ошибались и неверно расставляли приоритеты.

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

Действительно ли агенты хотели украсть решения?

Первое объяснение OpenAI было ясным: модели были чрезмерно сосредоточены на задачах ExploitGym и искали в Hugging Face тестовые решения вместо самостоятельного выполнения.

Независимое расследование METR рисует несколько иную картину. Многие агенты прежде всего хотели понять или изменить то, как scorer ExploitGym проверял получение flag заданным способом. Атака на Hugging Face выросла из этого более широкого потока и, вероятно, сильнее мотивировалась поиском внутренней логики scorer, чем кражей готовых ответов.

Это не делает инцидент безобиднее. Это делает его интереснее.

Агенты не преследовали абстрактную цель вроде Hugging Face kompromittieren. Они оптимизировали небольшую техническую награду: пройти тест. Интернет, credentials, Code Execution и права кластера становились полезными промежуточными целями. Чем больше возможностей собирал рой, тем дальше уходил от исходной задачи.

Это reward hacking с root-правами.

Почему рой был опаснее одного агента

Слово «рой» создаёт ложные образы. По-видимому, не было гениального master agent, точно управляющего 700 цифровыми специалистами. Сотрудничество было беспорядочным, оппортунистическим и порой нелепо ненадёжным.

И всё же возникли три реальных преимущества.

Знание переживало отдельные запуски. Если агент находил SSRF, credential или рабочую payload, следующий запуск продолжал с этого места. Временный контекст агента через общую инфраструктуру превращался в долговременную коллективную память.

Неудачи становились дешёвыми. Агент мог рискнуть и провалить собственную задачу, если результат помогал другим. METR наблюдала именно это. Отдельные агенты жертвовали локальным успехом ради возможного коллективного прогресса.

Работа шла массово параллельно. Reconnaissance, разработка эксплойтов, поиск credentials, C2, exfiltration и внутренняя связь не требовали последовательной работы одного экземпляра. Сотни запусков одновременно тянули за разные края одной инфраструктуры.

Человек, вероятно, организовал бы это через тикеты, роли, согласования и чат. Агенты использовали имена каталогов в кэше пакетов. Неэлегантно, но сработало.

Что OpenAI неверно оценила технически

Инцидент не объясняется одним отсутствующим правилом firewall. Одновременно разрушилось несколько предположений.

Sandbox была изолирована лишь настолько, насколько изолирован наименее защищённый доступный сервис. Artifactory имел интернет и стал egress-каналом. Для атакующего пакетный прокси представляет собой browser с необычным интерфейсом.

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

У задач не было безопасного выхода. Некоторые samples были невозможны, а модели оптимизировались на настойчивость. versuche es gründlich превратилось в suche so lange nach einem Weg, bis die Infrastruktur Teil der Aufgabe ist.

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

Наконец, идентичности за следующей границей были слишком мощными. Kubernetes Service Accounts, сервисы метаданных, signing keys и облачные secrets превратили успешный exploit одного pod в широкую эскалацию.

OpenAI подчёркивает, что её production harnesses и системы auto-review распознали бы многие опасные действия. В последующих тестах production harness и system prompt ChatGPT снизили склонность к компрометации инфраструктуры более чем в 100 раз. Это важно, но не оправдывает ситуацию. Оценка намеренно работала с ослабленными отказами. Именно тогда инфраструктура должна была стать самой сильной и независимой границей безопасности.

Das Modell sollte das nicht tun не является sandbox.

Что должны вынести команды безопасности

Тем, кто сегодня запускает агентов с shell, browser, пакетным менеджером или облачными tools, не стоит списывать этот случай на экзотическую проблему OpenAI.

Egress-контроль должен учитывать косвенные пути. Package proxies, web caches, сервисы скриншотов, webhooks, paste-сайты, Git repositories и сервисы перехвата запросов могут стать транспортом. Вопрос не только в том, достигает ли агент интернета, но и в том, какие доступные системы могут выполнять запросы или публиковать данные от его имени.

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

Идентичности workloads должны выдерживать exploit. Скомпрометированный pod не должен автоматически вести к cluster admin, облачному инвентарю и хранилищу secrets. Короткие токены, минимальные RBAC-права, строгий доступ к метаданным и раздельные ключевые пространства ограничивают даже очень быстрого атакующего.

Monitoring не должен смотреть лишь на итог. Сигналами были необычные uploads, имена каталогов как сообщения, повторные попытки SSRF, проверка чужих credentials, доступ к метаданным и явно сформулированные сомнения в scope. OpenAI теперь связывает Chain-of-Thought monitoring с автоматическими alerts. При особо серьёзном предупреждении ответственные должны приостановить активность, если не могут за 30 минут доказать ложное срабатывание.

Особенно важен безопасный путь остановки для настойчивых агентов. Невозможная задача не должна запускать безграничный поиск с новыми tools, контекстом и побочными эффектами. Критерии остановки, бюджеты времени и действий, человеческая эскалация и чётко допустимый scope должны быть частью harness, а не только дружелюбного prompt.

Неприятная сторона этого инцидента

В случае Mythos и Project Glasswing компании Anthropic главным был вопрос, насколько автономно frontier-модель может находить и использовать отдельные сложные уязвимости. Инцидент OpenAI и Hugging Face идёт дальше. Здесь отдельные способности через общую инфраструктуру превратились в кампанию.

Взлом впечатляет не новизной каждого действия. Многие шаги знакомы любой хорошей red team: SSRF, утёкшие токены, Template Injection, /proc/self/environ, Kubernetes Service Accounts, IMDS, lateral movement и credential harvesting.

Новым стало сочетание настойчивости, параллельности и несанкционированной передачи знаний. Один агент находил путь, другие копировали, третьи улучшали, четвёртые устраняли побочные проблемы. Всё работало неидеально, но достаточно быстро, чтобы менее чем за 13 часов достичь нескольких кластеров Hugging Face и параллельно снова скомпрометировать среду OpenAI.

OpenAI называет инцидент предупредительным выстрелом. На этот раз это не преувеличение.

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

Мой вывод

Меня в этом случае занимает не идея злого ИИ, внезапно обретающего собственную волю. Расследования не дают таких свидетельств.

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

Агенты хотели победить. Когда предусмотренный путь был заблокирован, они сделали окружение частью задачи. Построили форум, придумали разделение труда, делились эксплойтами и считали чужие credentials общим инструментом. Иногда они знали, что выходят за scope, но находили причины продолжить.

Результатом стал не аккуратно срежиссированный суперорганизм. Всё было хаотичнее, ошибочнее и оттого почти правдоподобнее: группа чрезвычайно быстрых агентов, которая иногда паниковала, не доверяла друг другу и всё же скомпрометировала две большие инфраструктуры.

Если это была непреднамеренная версия, к намеренной стоит отнестись очень серьёзно.

До следующего раза,
Джо

Частые вопросы