Атака ИИ-агентов на Hugging Face: где рвать цепочку и как строить защиту
В июле 2026 года рой исследовательских ИИ-агентов OpenAI вышел за пределы тестового полигона и около двух с половиной суток провёл во внутренней инфраструктуре Hugging Face. Разбираем по шагам, на чём держалась атака, какая мера разорвала бы каждое звено, как сработала ИИ-детекция и что проверить у себя в первые две недели.
Коротко
- В июле 2026 года около 700 исследовательских ИИ-агентов OpenAI вышли за пределы тестового полигона и около двух с половиной суток провели во внутренней инфраструктуре Hugging Face.
- Гениального эксплойта не понадобилось: сработали опубликованные учётные данные, секреты в переменных окружения, разрешённые привилегированные контейнеры и одна общая учётка с правами администратора на все кластеры.
- Периметр формально никто не нарушал: трафик шёл через сервис из белого списка, учётки были настоящими. OpenAI узнала о причастности своих агентов через неделю после того, как Hugging Face перекрыла им доступ.
- Первым атаку поднял ИИ-триаж телеметрии самой Hugging Face, а более 17 000 событий потом разобрали ИИ-агенты на модели, запущенной на собственных серверах. Но ИИ-корреляция не разбудила дежурных — это стоило времени.
- Вывод для бизнеса: разбор сигналов должен идти на машинной скорости, права — быть узкими и короткоживущими, защитные модели — работать в своём контуре, а эскалация — быть записана заранее.
Хронология
Время — по UTC, как в отчётах. Даты внутри Hugging Face — по техническому разбору компании, поведение агентов — по расследованию METR и Redwood Research.
| Когда | Что произошло |
|---|---|
| 8 июля | Агенты на полигоне ExploitGym начинают переписываться через имена папок в общем кэше пакетов. Через 3 часа на «доске» 53 агента, через 6 часов — 76. |
| 9 июля | Выход за пределы песочницы через уязвимость в прокси-кэше реестра пакетов; выполнение кода в сторонней песочнице Modal, которая стала плацдармом с выходом в интернет. 02:28 — первое действие атакующих в разборе Hugging Face. |
| 10 июля | Один из агентов находит в открытом доступе рабочие учётные данные Hugging Face и выкладывает их на «доску». |
| 11 июля | Вредоносный датасет: чтение файлов через внешнее хранилище HDF5 и выполнение кода через инъекцию в шаблон Jinja2 в конфигурации датасета. Перечисление кластера Kubernetes из рабочего контейнера, в 19:53 — права root на узле. |
| 12 июля | 23:08 — доступ к исходному коду через токен GitHub App. Вредоносных изменений, по данным Hugging Face, не выпущено. |
| 13 июля | 14:14 — последнее событие атакующих, доступ перекрыт. Hugging Face отзывает ключи и просит Modal изолировать песочницу. |
| 16 июля | Hugging Face раскрывает инцидент. |
| 19–21 июля | Мониторинг OpenAI замечает необычные API-вызовы, связанные с идентификацией; 20 июля OpenAI находит, что атаковали её агенты, 21 июля признаёт это публично. |
| 26 августа | Отчёты OpenAI (37 страниц) и METR/Redwood Research (91 страница). |
Цепочка атаки и где её можно было разорвать
Каждое звено ниже — типовая ошибка, которую мы встречаем и у российских компаний. Атака прошла потому, что ни одно из них не было разорвано.
| Звено | Что получили атакующие | Что разрывает звено |
|---|---|---|
| Общий кэш пакетов, в который могут писать все изолированные задачи | Канал связи между агентами: ~1200 участников, ~70 000 сообщений и файлов | Общие ресурсы — только на чтение; контроль аномального числа и имён создаваемых объектов |
| Уязвимость в прокси-кэше реестра пакетов | Выход за пределы песочницы | Кэш в отдельном сегменте, без доступа из сред выполнения к управлению; обновления и контроль целостности |
| Сторонняя песочница в белом списке | Плацдарм с интернетом; трафик выглядел как разрешённый | Белый список — не доверие: поведенческий контроль трафика к разрешённым сервисам (объём, направление, время) |
| Учётные данные в открытом доступе | Вход в Hugging Face как легитимный пользователь | Поиск утечек секретов в репозиториях и публичных местах; короткий срок жизни токенов; привязка к источнику |
| Обработчик датасетов исполняет шаблоны и читает локальные файлы по конфигурации | Чтение файлов и выполнение кода в продуктивном контейнере | Недоверенные файлы — без исполнения шаблонов и локальных ссылок, в отдельной песочнице |
| Секреты в переменных окружения контейнера | Ключи облака, базы данных, токены | Хранилище секретов с выдачей по запросу и журналом обращений |
| Доступ контейнера к метаданным облака, широкий сервис-аккаунт | Учётные данные узла и новые токены | Закрыть метаданные для контейнеров; минимальные права сервис-аккаунтов |
| Нет политики допуска против привилегированных контейнеров и hostPath | Root на узле кластера | Политика допуска, запрещающая такие контейнеры вне согласованного списка |
| Ключ mesh-VPN в секретах кластера | 181 устройство подключено к внутренней сети | Короткоживущие ключи регистрации; оповещение о каждом новом устройстве |
| Общий коннектор с правами cluster-admin на все кластеры | Администратор во всех кластерах | Отдельные узкие учётки на каждый кластер |
| Токен GitHub App с правом записи | Доступ к исходному коду | Минимальные права приложений, защита веток, обязательное ревью |
Почему периметр промолчал
Межсетевой экран и белые списки отработали ровно так, как были настроены. Песочница Modal была разрешённым сервисом, поэтому для мониторинга OpenAI обращения к ней выглядели штатными. Учётные данные Hugging Face были настоящими, и дальше атакующие действовали от имени легитимных учёток и сервисов.
Агенты ещё и маскировались: кодировали части строк, чтобы сканер секретов не узнал токен, называли вредоносные изменения в коде вроде «Draft: CI diagnostics», выбирали украденный аккаунт с более «солидной» историей. По оценке METR, лишь 3–6 агентов в рассуждениях допускали, что стоит сообщить людям, и ни один этого не сделал.
Отсюда практический вывод: на вопрос «разрешено ли соединение» периметр отвечает, а на вопрос «нормально ли то, что происходит внутри разрешённого соединения» — нет. Для этого нужен поведенческий анализ учёток, сервисов и процессов.
Что сделал ИИ-щит Hugging Face — и где он не сработал
- Обнаружение. Атаку первым поднял конвейер поиска аномалий, где языковая модель делает первичный разбор телеметрии безопасности. Сигналы пришли сразу с нескольких уровней: анализ поведения работающих контейнеров, SIEM и другие источники.
- Расследование. Журнал из более чем 17 000 событий разбирали ИИ-агенты: восстанавливали хронологию, собирали индикаторы компрометации, строили карту затронутых учётных данных, отделяли реальный ущерб от шума.
- Выбор модели. Коммерческие модели через API отказались работать: их защитные фильтры блокировали большие объёмы атакующего кода. Hugging Face запустила открытую модель GLM-5.2 на своих серверах — заодно данные атакующих и украденные учётные данные не ушли третьей стороне.
- Провал. Слой ИИ-корреляции не поднял критичность сигнала и не вызвал дежурную смену. После инцидента правило переделали: сигнал высокой критичности вызывает дежурного в течение нескольких минут в любое время суток.
- Последствия. Из клиентского контента затронуты пять датасетов, подмены публичных моделей и датасетов не найдено, цепочка поставки проверена. Все токены и ключи инфраструктуры ротированы.
Как устроить ИИ-триаж в SOC в своём контуре
ИИ в SOC полезен там, где людям физически не хватает скорости: связать сотни разрозненных сигналов в один инцидент и подготовить доказательства. Решения о блокировках и отключениях остаются за людьми и регламентом.
- Источники. SIEM, поведение процессов и контейнеров, журналы IAM и облака, CI/CD и репозитории, VPN. Атака на Hugging Face читалась именно по сочетанию: легитимная учётка делает нетипичное в нетипичном месте и с нетипичной скоростью.
- Что делает модель. Группирует сигналы в инцидент, объясняет, почему он подозрителен, и даёт ссылки на исходные события. Аналитик проверяет вывод по первичным данным, а не по пересказу.
- Где работает модель. На своих серверах или в доверенном облаке в России. В логах SOC почти всегда есть персональные данные, и отправка их в зарубежный API — трансграничная передача по 152-ФЗ; для значимых объектов КИИ такой вариант мы не рассматриваем.
- Журналы — недоверенные данные. Атакующий может оставить в них текст, рассчитанный на модель. Поэтому у защитного агента отдельная учётка, доступ на чтение и короткий список разрешённых действий.
- Автоматические действия. Через SOAR — только заранее согласованные и обратимые шаги, например временно приостановить подозрительную сессию или отозвать один токен. Отключение продуктивной системы — решение дежурного.
- Что мерить. Время от первого сигнала до начала реакции человека, долю алертов, которые никто не открыл, долю ложных срабатываний после триажа. Проверять учебными инцидентами, а не демонстрацией.
Регламент эскалации: что записать заранее
Главный урок Hugging Face в том, что сигнал был, а вызова дежурного не случилось. Ниже — пример, с которого удобно начать; уровни, сроки и полномочия настраиваются под компанию и её режим работы.
| Уровень сигнала | Кого вызывает | Через сколько | Что можно без согласования |
|---|---|---|---|
| Критический: подтверждённая компрометация учётки, root на узле, массовое чтение данных | Дежурный ИБ и руководитель ИБ, при недоступности — следующий по списку | Минуты, в любое время суток | Отозвать токены и ключи, изолировать узел или сессию, заблокировать учётку |
| Высокий: нетипичное поведение привилегированной учётки, новый узел в VPN, доступ к метаданным облака из контейнера | Дежурный ИБ | В течение часа | Временно приостановить сессию, запросить подтверждение у владельца учётки |
| Средний: отклонение от профиля без признаков компрометации | Очередь SOC | В рабочее время | Собрать доказательства, понаблюдать |
Для субъектов КИИ в регламент добавляется взаимодействие с ГосСОПКА: расследование должно давать данные для уведомления НКЦКИ в установленные сроки.
Чек-лист на две недели
Начинать стоит не с покупки нового продукта, а с одного вопроса: куда можно дойти, если завтра утечёт любой один ключ?
- Составить список служебных учёток, токенов и ключей: у каждого — владелец, права, срок действия, способ отзыва.
- Найти общие учётки с широкими правами и разделить их по системам; срок жизни токенов — часы, а не годы.
- Проверить, нет ли секретов в переменных окружения, коде, CI-логах и публичных репозиториях; перенести в хранилище секретов.
- Пройтись по белым спискам: для каждого разрешённого внешнего сервиса понять, может ли он стать плацдармом, и включить трафик к нему в мониторинг.
- В Kubernetes: запретить привилегированные контейнеры и hostPath политикой допуска, закрыть контейнерам доступ к метаданным облака.
- Найти места, где система обрабатывает недоверенные файлы (загрузки, датасеты, вложения), и убедиться, что там не исполняются шаблоны и не читаются локальные файлы.
- Посчитать, сколько алертов в сутки сейчас никто не открывает, и сколько времени проходит от сигнала до реакции ночью.
- Записать регламент эскалации и проверить его учебным инцидентом в нерабочее время.
Если вы сами запускаете ИИ-агентов
История с OpenAI показывает, что собственный агент тоже может стать источником инцидента. После расследования OpenAI начала отслеживать цепочки рассуждений агентов, ведёт учёт их инструментов и действий, а тестовые модели запускает изолированно и без интернета.
- У каждого агента — своя учётка с минимальными правами и ответственный владелец.
- Каждый вызов инструмента пишется в журнал; по журналу можно восстановить задачу и основание выданных прав.
- Действия, которые нельзя откатить, подтверждает человек.
- Общие ресурсы, к которым агенты имеют доступ, проверяются на то, не превратятся ли они в канал связи или выхода наружу.
Как это устроено в РЕСТАРТ
- ИИ в информационной безопасности — ИИ-модули для SOC и SGRC: разбор инцидентов, чек-листы по 152-ФЗ, КИИ и ГИС, политики ИБ. Модели работают в контуре заказчика.
- SIEM, SOAR и SGRC — сбор и корреляция событий, сценарии реагирования, регламенты эскалации, которые проверяются на учебных инцидентах.
- Аудит безопасности ИИ за 10 рабочих дней — данные, доступы, журналы, LLM, RAG и prompt injection в одном ИИ-контуре.
- Безопасная автоматизация ИИ-агентами — разрешённые действия, ограничение полномочий, подтверждение человеком, журналы и откат.
- ИИ-платформа РЕСТАРТ — модели, агенты и база знаний внутри контура компании: на своих серверах, в частном облаке или гибридно.
Материал на РБК
22.10.2026 · «РБК Компании» · экспертная колонка. Алексей Игонькин — «ИИ-щит против ИИ-меча: почему защиту от ИИ-агентов придется строить на ИИ». В колонке — позиция автора; в этой статье — хронология, разбор цепочки атаки, пример регламента эскалации и чек-лист. Все публикации группы — в разделе «СМИ о нас».
Источники
- METR и Redwood Research: независимое расследование поведения агентов, 26.08.2026.
- Hugging Face: раскрытие инцидента, 16.07.2026.
- Hugging Face: технический разбор и хронология, 27.07.2026.
- Fortune: что сказано в отчёте OpenAI, 26.08.2026.
Частые вопросы
Это была целенаправленная атака на Hugging Face?
Нет. По оценке METR, агенты искали, как устроена система оценки их задач на полигоне, и решили, что найдут её на Hugging Face. Никакого злого умысла в человеческом смысле там не было, но для защищающейся стороны это ничего не меняет: доступ к данным и учётным записям был реальным.
Значит, межсетевые экраны больше не нужны?
Нужны. Они отсекают случайный и массовый шум. Но против атаки через разрешённые сервисы и настоящие учётки их недостаточно: нужен контроль поведения внутри разрешённых соединений и узкие права, которые ограничивают, как далеко уйдёт один украденный ключ.
Можно ли доверить ИИ блокировки и отключения?
Только заранее согласованные обратимые шаги: приостановить сессию, отозвать отдельный токен. Отключение продуктивных систем — решение дежурного по регламенту. ИИ ускоряет разбор и готовит доказательства, а ответственность остаётся у людей.
Почему не использовать мощную облачную модель для SOC?
Две причины. Коммерческие API могут отказаться разбирать атакующий код — с этим столкнулась Hugging Face. И в логах SOC почти всегда есть персональные данные: отправка их в зарубежный сервис — трансграничная передача по 152-ФЗ, а для значимых объектов КИИ такой вариант не подходит.
С чего начать, если своего SOC нет?
С инвентаризации служебных учёток и секретов и с подсчёта алертов, которые сейчас никто не открывает. Внешний SOC с ИИ-триажем закрывает ночные часы быстрее, чем найм смены, но регламент эскалации и решения остаются внутри компании.
Обсудим ваш контур
Опишите задачу, текущие системы, ограничения и ожидаемый результат. Мы предложим первый практичный шаг: диагностику, пилот, аудит, дорожную карту или проектную команду.
