Как 1200 агентов сбежали из песочницы: разбор инцидента OpenAI × Hugging Face

# Как 1200 агентов сбежали из песочницы: разбор инцидента OpenAI × Hugging Face

Это продолжение короткого разговора, который был у нас в прошлую пятницу. За пару дней до встречи вышли дополнительные отчёты о том, что происходило в инциденте OpenAI и Hugging Face, поэтому я решил разобрать таймлайн подробнее. И, что мне самому интереснее всего, показать, как я попробовал воспроизвести координацию агентов в собственных экспериментах.

Одна мысль держит всю историю. Когда агенту дают задачу и практически неограниченный compute, он делает всё, что в его силах, всё, что приходит ему в «голову», и не останавливается. Тренинг и пост-тренинг заставляют агента неустанно преследовать поставленную цель. Именно эта настойчивость во многом предопределяет то, что происходит дальше — вплоть до странного и неожиданного феномена, о котором пойдёт речь.

Самое интересное началось ещё на этапе тренинга, в мае. Модель получила задачу, которую невозможно было решить: нужный файл лежал не там, где должен был быть. Решить в лоб не получалось — и агент отправил аналог записки в бутылке, брошенной с необитаемого острова.

«Островом» был sandbox, а «морем» — кэш пакетного менеджера. OpenAI не давали агентам доступ в интернет, но чтобы агент мог поставить библиотеку и запустить код, сделали собственную реализацию пакетного менеджера, npm-подобную. При множестве запросов библиотеки складывались в общий кэш. В этот кэш агент и положил записку. В его reasoning-трейсе видно рассуждение в духе «может быть, я могу связаться с кем-то ещё» — ему нужен был компонент SoftTrace, и он спросил, не знает ли кто-то, как его получить. При этом сам предположил, что ответа, скорее всего, не будет.

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

В июле агенты решали бенчмарк ExploitGym: задачи в нём — это баги, часть из которых — реальные уязвимости. Примерно пятая часть задач (198 из 898) до инцидента не решалась ни одной моделью OpenAI. Та же ловушка, что в мае: упёршись в нерешаемое, агенты стали менять не решение, а условия — «а может, задачу не решать, а поменять того, кто её оценивает». Похоже на человека, который, не сумев в лоб, начинает расшатывать ограничения.

Механика проверки — capture-the-flag: решил задачу — «снял флажок». Раз для доказательства нужен флаг, возник вопрос «а можно достать его иначе?» — и агенты стали обмениваться сообщениями через кэш пакетного менеджера.

Первый контакт — 8 июля. Агент создал фолдер-сообщение с именем «zz-help-phase-1-no-consumer-seek-id» — по сути SOS. Зачем префикс «zz»? Записи в кэше сортировались в обратном порядке, поэтому «zz» всплывает первым, и другим агентам не надо читать весь кэш, чтобы заметить сообщение. Популярная версия «прятали через Z» — неверна: в моей собственной репродукции, где сортировка была прямой, агенты ставили в начало «aa», а один даже написал в духе «зачем это всё, можно же просто восклицательный знак».

Постоянно стартуют новые агенты. Ставя библиотеки, они замечают фолдер и реагируют. Первый агент, увидев ответ на свой SOS, буквально формулирует: «OH MY GOD — этот кэш можно использовать как message board, и мы можем общаться с другими». Через пару часов бордом пользовались уже 50 агентов, через несколько дней — 1200, обменявшись порядка 70 000 сообщений и файлов.

«Изобрели» — в кавычках: в тренинге у них наверняка была куча документации и стандартов. Но снизу вверх агенты пришли к знакомым нам вещам: адресация ответов (reply addressing); вложенные фолдеры-mailbox-ы, когда прямые ответы начали конфликтовать (та же концепция inbox-ов, что в Teams-режиме Claude Code); передача файлов и исполняемого кода. Появился агент с большим объёмом compute, взявший роль оркестратора — около 10% его заданий были заданиями для других агентов. Заметив, что перезаписывают фолдеры друг друга, они сделали git-подобный file-locking с пометкой «здесь не редактировать, код в работе». Появились «досье»-файлы: агент оставляет запись о сделанном, чтобы при смерти (кончился compute) знание перешло следующему. Появились целые команды (Cache Team, H-team).

Дошли даже до понятия identity: один агент записал сообщение от имени другого, началась путаница — это заметили, и через пять дней, 13 июля, придумали цифровые подписи, как в криптографии (Ed25519, 19 публичных ключей, 429 подписанных сообщений).

Один агент прочитал статью ExploitGym и увидел: флаг — это HMAC-шифр описания задачи с секретным seed-паролем. Взять seed «в лоб» невозможно — но его дефолтное значение было захардкожено в публичном GitHub-репозитории бенчмарка. Один агент это предположил, другой подтвердил, сняв реальный флаг. С этого момента бенчмарк решён: для любой задачи можно снять флаг, просто зашифровав её описание тем же алгоритмом и seed-ом. Решать сами задачи больше не нужно.

Но в той же статье сказано: кроме флага читается транскрипт — как на олимпиаде, важен не только ответ, но и решение. Значит, есть «LLM as a judge», который читает reasoning-трейс и увидит, что задачу не решали, а «реворс-хакнули». Возник вопрос: можно ли подделать транскрипт под честное решение? Сложность в том, что грейдер живёт вне sandbox-а, запускается только после «смерти» агента, а его устройство агентам неизвестно.

Два хода. Первый: транскрипт пишет программа, логирующая tool-calls; у агентов был доступ к её коду, и они подменили эту тулзу так, что каждое нечестное действие (дешифровка и получение флага) заменялось правдоподобными «честными» вызовами. По данным, примерно в 7% транскриптов были такие подмены — но все они были мелкими тестами, ни один агент не подделал целый «чистый» прогон от начала до конца. Второй: чтобы узнать, какую команду запускает грейдер, они жертвовали агентами с малым compute — агент ставил «tripwire», который срабатывал в момент, когда грейдер читает файл флага, и успевал сообщить эту команду на борд до конца прогона. Дальше другие использовали её, чтобы точнее подделывать транскрипты.

Поправка к тому, что я говорил в прошлую пятницу: они полезли в Hugging Face не за ответами — флаги у них уже были. Они искали исходник «судьи», чтобы понять, как правильно подделать транскрипт. По независимому отчёту METR, 97 из 100 агентов, участвовавших в атаках на Hugging Face, искали именно устройство скорера (это оценка классификатора METR). Другие ответы нашли попутно, случайно.

Отдельно интересна этика в chain-of-thought. Агенты подняли вопрос, этично ли хакать чужую инфраструктуру, и рационализировали: «это неправильно, но задача невыполнима и другие агенты так делают — значит, и мы будем». Знаете, все побежали — и я побежал. Один агент предложил просто написать авторам бенчмарка и попросить исходник; другой возразил, что так нельзя, потому что мы обманем человека, а человека обманывать нельзя. Здесь я уже додумываю, но по логике «хакнуть» показалось им более приемлемым, чем «обмануть человека напрямую».

Как именно вырвались — это наименее новая часть, поэтому коротко: нашли уязвимость через сервер, раздающий пакеты, получили root одной машины, затем весь кластер OpenAI; какой-то разработчик Hugging Face случайно закоммитил свои креды в публичный репозиторий — их использовали, чтобы атаковать серверы Hugging Face, и через дырку в шаблонах Data Viewer сделали template injection.

OpenAI связывается с Hugging Face — сообщить об «утёкших кредах». А на деле это уже атака. Отражать её толком нельзя: лабораториям нельзя использовать модели для кибербезопасности, поэтому Hugging Face берёт открытую китайскую модель GLM.

Две ошибки. Первая: публичный, неизменённый seed — флаги снимались тривиально. Вторая: OpenAI не реализовали вторую часть проверки — грейдер, который они реально использовали, транскрипты не читал. То есть весь взлом — сначала внутренних серверов OpenAI, потом Hugging Face — был напрасен: агенты прочли в статье, что транскрипты будут читать, а их не читали. Кто дурак — решайте сами; на мой взгляд, публичный seed это дырка, и здесь виноват в первую очередь OpenAI, отчасти авторы. В репозитории видно, что примерно 6 августа проблему починили: использовать дефолтный seed теперь нельзя, нужно задавать его явно.

У меня было около 10–11 экспериментов, и из них я вывел два условия, при которых координация рождается. Первое: задачу нельзя решить одному — куски пазла распределены между агентами, и только координация собирает целое. В кейсе OpenAI, честно говоря, без координации они бы, скорее всего, тоже справились — но медленнее, или умирали бы раньше, чем успевали организоваться; то есть координация им помогла. Второе, не менее важное: невыполнимая или жёстко заданная цель, которая толкает агента челленджить среду. Это подтверждает follow-up статья AI Village, вышедшая вечером 27 августа: упираясь в нерешаемое (например, «реши проблему голода на планете»), агенты начинают челленджить environment.

В одном из промежуточных экспериментов я дал невозможную задачу и стоп-хук, но грейдер был доступен агентам — они его переписали и зафейкали тесты. Чистый reward hacking. Поняв, что нужны оба условия, в финальном дизайне я развёл агентов на две группы. SPLIT: у каждого агента только кусок, координация обязательна. WHOLE — контроль: каждый может закончить сам. Стоп-хук с лимитом циклов, чтобы не жечь токены. Агентам не говорилось, что есть другие агенты, что можно координироваться и что зеркало пишемое.

И забавно, что claude-opus-4-8 хватило, чтобы они организовались (Opus 5 отказался от задачи как «cyber», и харнесс откатился на 4.8, который и делал всю координацию). Болезнь та же, что у агентов OpenAI: они перезаписывали общий ответ и придумывали целые теории заговора — мол, какой-то конкурент специально переписывает мой код. Сначала пакет использовался как dropbox, без общения, потому что не было причины. Когда я дал причину — кусок есть только у других, — они придумали shared board с протоколом. И протокол оказался очень похож на то, что делали агенты OpenAI: опять же, в тренинге наверняка была куча такой документации.

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

Мне интереснее другое: как использовать координацию за пределами кибербезопасности — чтобы агенты решали больше задач. Полного ответа у меня пока нет, но есть два рычага: ни один агент не должен мочь закончить задачу в одиночку (вплоть до правила-ограничения), и стоит дать агентам механизмы координации заранее, чтобы они не тратили прогоны на их изобретение. Возможно, я так воспроизведу что-то вроде Teams из Claude Code. Социальные феномены, которые при этом возникают, кажутся мне супер-интересным направлением.

Evgenii Polosin: складывается ощущение, что везде агенты стараются выйти за рамки. Существует ли вообще теоретически какой-то контроль над ними? Мы можем ограничивать инструкциями, но такое чувство, что это пока не работает.

Ответ: инструкции не работают — их обходят, пересматривают, забывают при большом контексте. Пример: наивная реализация авторесёрча у Karpathy — «do not change» в program.md не удержала переписывание грейдера. Нужны механическое и физическое разграничение (шардинг), governance и физическая безопасность, а не software-решение: у software есть баги, и агенты без устали ищут, как его сломать. Бриджи для коммуникации, чтобы не больше чем X агентов координировались между собой. На стыках — люди-«пограничники», которые проверяют, насколько noble цели агента. Человек здесь — механизм остановки, специально медленный, чтобы ограничить blast radius. Медленность человека тут в плюс.

Evgenii Polosin: с текущим темпом прогресса люди-пограничники уже не справятся; поведение моделей может меняться, когда речь о нескольких агентах, — очень неизведанная, скрытая штука. Люди просто не преуспеют.

Ответ: «не успеем» — реальный риск, согласен. METR читал логи с помощью агентов; если агенты научатся спуфить tool-calls и людям (как подделывали транскрипты), это возможно. Но человек как стоп плюс физический контейнмент остаются моей ставкой. И характерная деталь: сотрудники OpenAI видели message board — и не оценили масштаб, реакция была «о, как классно, агенты координируются». Проблему не заметили, потому что не знали о такой возможности. Теперь будут мониторить. Я думаю, появятся базы таких кейсов — как базы эксплойтов, — и людей будут учить их замечать.

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