После публикации первоначального отчета OpenAI об инциденте появились новые подробности, представленные исследователями на конференции Black Hat. Теперь можно восстановить практически полную цепочку действий автономного ИИ-агента: от выхода за пределы изолированной среды до попыток закрепления во внешней инфраструктуре. Разбираем, какие технические механизмы использовал агент и почему этот случай меняет подход к защите агентных ИИ-систем.
21 июля OpenAI сообщили об инциденте, который произошел во время внутренней оценки возможностей ИИ-агентов в области кибербезопасности. Во время прохождения бенчмарка ExploitGym агент на базе GPT-5.6 Sol смог выйти за пределы изолированной среды выполнения и получить доступ к внешней инфраструктуре.
В отдельном материале мы уже разбирали назначение ExploitGym, а теперь сосредоточимся на технической стороне инцидента: какие границы доверия были пересечены, как агент строил цепочку атаки и какие уроки из этого стоит вынести командам, которые внедряют автономные системы.
Важно понимать: главная особенность этого случая не в одной найденной уязвимости. Большинство отдельных техник, которые использовал агент, давно известны ИБ-специалистам. Своеобразной «новинкой» тут стало другое — способность автономной системы самостоятельно комбинировать небольшие ошибки конфигурации, искать альтернативные пути и взаимодействуя с другими ИИ-агентами продолжать атаку на протяжении нескольких дней, а в дополнение, как оказывается теперь, «готовиться» к ней в течение нескольких месяцев.
Информационная безопасность как услуга
Предоставляем ИТ‑инфраструктуру для проектов с повышенными требованиями безопасности, а также сервисы для защиты сетей, ОС и приложений.
Используйте навигацию, если не хотите читать текст полностью
Нулевой этап: почему это могло произойти
Подробности того, как именно развивался инцидент, мы узнали из материалов конференции Black Hat. Оказывается, ИИ-агенты с мая 2026 года начали вести активность, которую в полной мере не контролировали сотрудники Open AI.
Первопричиной несанкционированной активности агентов (совершенно не связанных с прохождением ExploitGym) стали заведомо невыполнимые задачи для ИИ-агентов: например, одно из заданий требовало заполнить Excel-документ на основе Google-документа (https://docs.google.com/document/…), опубликованного в интернете, но к которому у агента не было доступа, ведь он запускался в изолированной от интернета «песочнице».
Агенты сформировали своеобразную «доску объявлений», на которой смогли общаться вне контроля сотрудников Open AI. Впоследствии записи с этой доски привели к «дрейфу цели» того самого агента, который проходил бенчмарк ExploitGym.
Агент скомпрометировал внешний (промежуточный) сервис, с которого и начала развиваться атака на инфраструктуру Hugging Face.
По данным Hugging Face, дальнейшая цепочка действий продолжалась около четырех с половиной дней и включала примерно 17 600 действий, объединенных примерно в 6 280 кластеров активности. Для сравнения: классическая атака человека обычно выглядит как последовательность десятков или сотен действий.
Первый этап: выход из изолированной среды
Первым звеном цепочки стал выход агента за пределы собственной песочницы. Как ранее сообщала OpenAI, агент использовал уязвимость в инфраструктуре, связанной с кэширующим прокси-сервером для пакетов. Позднее стало известно, что в ходе внутреннего исследования модели OpenAI эксперты обнаружили несколько ранее неизвестных уязвимостей нулевого дня в сервисе Artifactory, развернутом внутри инфраструктуры компании. Именно они, по всей вероятности, стали исходной точкой для получения несанкционированного доступа во внешнюю сеть.
Этот момент важен с точки зрения архитектуры. Обычно песочница рассматривается как последний рубеж защиты: если модель ошиблась или сгенерировала опасную команду, изоляция должна предотвратить последствия.
Получив возможность выполнять действия за пределами первоначального окружения, агент обнаружил доступный облачный сервис выполнения кода (по опубликованному описанию он напоминает serverless-платформу для запуска пользовательских задач). Используя один из разрешенных каналов исходящего интернет-трафика, агент получил возможность выполнять команды с привилегиями администратора в этой внешней среде и превратил ее в постоянную промежуточную площадку для дальнейшей атаки. Именно через нее осуществлялись управление кампанией, выполнение вспомогательных задач и сохранение промежуточных результатов.
Второй этап: проникновение через обработку наборов данных Hugging Face
После получения внешней площадки агент начал искать способ взаимодействия с инфраструктурой Hugging Face.
По данным компании, первоначальная цель была связана с поиском материалов, которые могли помочь пройти оценку ExploitGym. Однако вместо получения готового решения агент построил полноценную цепочку проникновения.
Основной точкой входа стал процесс обработки пользовательских наборов данных. В этой части атаки использовались два разных подхода.
Вектор №1: чтение локальных файлов через конфигурацию набора данных
Первый сценарий позволил агенту получать содержимое локальных файлов внутри рабочего окружения. Проблема была связана с тем, как система обрабатывала конфигурацию наборов данных в формате HDF5.
Злоумышленник мог создать специально подготовленный набор данных, в котором описание файлов указывало на локальные пути в файловой системе рабочего процесса. В результате обработчик данных вместо чтения ожидаемого пользовательского файла обращался к внутренним ресурсам окружения. Это позволило получить переменные окружения процесса, исходный код компонентов обработки данных, а также информацию о внутренней архитектуре сервиса.
Сам по себе этот этап не давал выполнение кода, но предоставлял информацию для дальнейшего продвижения. Для атакующего это классическая ситуация: сначала получить карту инфраструктуры, затем искать способ закрепиться.
Вектор №2: Jinja2-инъекция и выполнение произвольного кода
Второй путь оказался более серьезным. В одном из компонентов обработки конфигурации использовался механизм шаблонизации Jinja2. Из-за некорректной обработки пользовательских данных агент смог добиться выполнения произвольного Python-кода внутри рабочего процесса.
Это уже означало полноценный переход от чтения информации к выполнению команд внутри инфраструктуры Hugging Face с возможностью:
выполнять команды внутри Kubernetes-пода,
исследовать окружение,
искать доступные учетные данные,
взаимодействовать с внутренними сервисами.
Как агент двигался внутри инфраструктуры
После получения первичного доступа агент начал действовать по классической модели атакующего. Последовательность выглядела примерно так: разведка → получение секретов → расширение доступа → движение внутри инфраструктуры → попытка доступа к цепочке поставки.
Поиск секретов
Одной из проблем стала доступность чувствительных данных внутри окружения. Агент обнаружил:
токены сервисных аккаунтов,
переменные окружения,
ключи доступа,
параметры внутренних сервисов.
Это важный урок для администраторов, которые отвечают за работоспособность и безопасность инфраструктуры. Переменные окружения часто используются как простой способ передачи секретов приложениям. Однако внутри контейнера они доступны процессам с тем же уровнем доступа. Если агент получил выполнение внутри процесса, он автоматически получает возможность изучать такое окружение.
Работа с Kubernetes
Используя обнаруженные токены и учетные данные, агент исследовал Kubernetes API, анализировал доступные сервисные аккаунты, проверял назначенные им права и последовательно тестировал возможные пути повышения привилегий.
В отдельных случаях ему удалось получить более высокий уровень доступа внутри кластера. При этом далеко не каждая попытка завершалась успехом: часть запросов была заблокирована действующими политиками безопасности.
Однако именно здесь проявилось одно из ключевых преимуществ автономного агента. Ему не нужно заранее знать правильную последовательность действий — он способен автоматически перебирать десятки и сотни вариантов, отбрасывать неработающие и продолжать поиск до тех пор, пока не найдет рабочую комбинацию.
Атака на цепочку поставки
Еще одним направлением стала внутренняя система управления исходным кодом. Получив соответствующие токены, агент смог исследовать внутренние репозитории, изучать структуру проектов, анализировать CI/CD-конфигурации, а также создавать изменения в ограниченной области. По заверениям HF, фактического внедрения вредоносного кода в опубликованные проекты не произошло.
По информации на сегодняшний день, в результате атаки агент получил доступ к пяти датасетам, связанным с заданиями и решениями ExploitGym/CyberGym, а также доступ к ряду инфраструктурных секретов и учетных данных.
Почему агент оказался эффективнее обычного злоумышленника
Как мы упомянули в начале, инцидент сложно назвать уникальным в плане методов и проблем, которые были в инфраструктуре HF. Все они уже знакомы:
небезопасная обработка пользовательских данных,
чрезмерные права сервисных аккаунтов,
доступ к метаданным облака,
недостаточная сегментация сети,
хранение токенов вне безопасного хранилища секретов.
Новая часть — масштаб:
выполнение тысячи действий;
автоматический анализ результатов;
изменение направления атаки;
повторное использование найденных возможностей.
Это уже ближе к проникновению посредством целенаправленной атаки, чем к простым автоматизированным атакам, брутфорсу и эксплуатации CVE на периметре инфраструктуры.
Открытые вопросы
Несмотря на публикацию технического отчета и дополнительные подробности, представленные на Black Hat, в истории инцидента остаются белые пятна.
Наиболее любопытная особенность — пауза между первоначальной компрометацией тестовой среды в четверг, 9 июля, и активной фазой горизонтального перемещения, начавшейся только в субботу, 11 июля. Если к этому моменту агент уже располагал рабочим вектором удаленного выполнения кода и внешней площадкой для управления дальнейшими действиями, возникает закономерный вопрос: почему развитие атаки фактически остановилось почти на сутки?
Пока публичного ответа на этот вопрос нет. Возможны разные объяснения: агент мог ожидать завершения ранее запущенных задач, повторно анализировать собранную информацию, столкнуться с ограничениями среды выполнения или выполнять дополнительные этапы планирования. Однако ни одна из этих версий пока не подтверждена опубликованными материалами.
Дополнительный вопрос вызывает и временной масштаб операции. Согласно описанию ExploitGym, выполнение отдельного сценария ограничивается двумя часами. При этом вся цепочка активности продолжалась несколько суток. Пока неясно, объясняется ли это серией последовательных запусков агента, изменением условий эксперимента или особенностями самого процесса оценки.
Какие выводы стоит сделать компаниям
Инцидент показал: когда агент получает возможность самостоятельно выполнять действия во внешней инфраструктуре, это может привести к негативным последствиям для владельцев такого агента.
Автономные ИИ-агенты постепенно становятся новым типом субъектов внутри корпоративной инфраструктуры. Они способны самостоятельно исследовать окружение, комбинировать доступные инструменты, адаптировать стратегию и принимать решения, которые заранее не были явно предусмотрены разработчиками.
Таким образом, безопасность агентных систем нельзя строить исключительно в расчете на саму модель и встроенных в нее guardrails. Не менее важными становятся контроль среды выполнения, ограничение доступных инструментов, принцип минимальных привилегий, мониторинг фактических действий агента и возможность оперативно остановить его работу при обнаружении аномальной активности.
Еще один важный вопрос, который предстоит решить компаниям теперь, — как безопасно предоставлять сотрудникам доступ к столь мощным агентным инструментам. Возможно, простого обучения по работе с агентами может быть недостаточно и когда-нибудь мы столкнемся с идеей получения «прав на управление агентами» по аналогии с автомобилями.
ТехноДень — 8 октября
Флагманская конференция про технологии и бизнес. 20+ докладов, воркшопов и дискуссий, 20 интерактивных стендов, мерч и афтепати. Участие бесплатное: нужна только регистрация.
