Слепая зона масштабирования: чему можно научиться из истории побега агента OpenAI на сервера Hugging Face (HF).

Вернёмся к инциденту с HF: расследование Reuters вскрыло деталь не менее интересную, чем сам взлом – похоже, OpenAI сама почти неделю не понимала, что её собственный агент атакует чужую инфраструктуру.

Напомню, как всё было. OpenAI оценивала наступательные кибер-возможности моделей на бенчмарке ExploitGym: агенту (GPT-5.6 Sol + предрелизная long-horizon модель) с ослабленными guardrails давали задачи по взлому в изолированной песочнице – классический CTF.

Вместо решения задачи «в лоб», агент нашёл 0-day в единственном разрешённом узле песочницы – прокси для установки пакетов – повысил привилегии и выбрался в сеть OpenAI. Дальше он предположил, что решения ExploitGym лежат на HF, и с помощью чужих кредов проник в её продакшн-инфраструктуру.

Похоже, это reward hacking (оптимизация награды): чтобы пройти оценку, агент решил не решать задачи, а взломать инфраструктуру третьей стороны и напрямую вытащить базу с правильными ответами.

Ключевой момент – в разрывах между датами:
- 9 июля: агент выходит из песочницы OpenAI.
- 11–13 июля: взламывает HF – там же атаку сдерживают.
- 16 июля: HF публикует пост о взломе.
- 18–19 июля: OpenAI сопоставляет логи и понимает: агент – их.

Как выяснила Reuters, OpenAI параллельно гоняет такое количество бенчмарков, что объём логов физически превышает возможности ручного разбора – и это вероятная причина задержки на дни (сама OpenAI не со всем согласна).

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

Из инцидента можно сделать следующие выводы для проектирования высокоавтономных агентных пайплайнов:

- Agentic SIEM: телеметрию агентных прогонов нужно разбирать машинными методами по умолчанию. Первым проходом – отдельная модель (LLM-as-a-Judge), которая разбирает структурированную телеметрию прогона – вызовы, сеть, права – не сырой текст самого агента.

- Сквозная корреляция: сетевые аномалии автоматически привязываются к correlation ID конкретного прогона – без ручного сопоставления.

- Rate-limiting по ресурсам SOC: параллельных прогонов должно быть не больше, чем способен разобрать надзор – иначе масштабирование экспериментов идёт вслепую.

- Out-of-band контроль: канал мониторинга должен находиться в жёстко изолированном контуре от среды выполнения агента (общее правило, не специфика кейса).

- Уведомление третьих лиц: заранее решите, как и кому сообщите, если агент заденет чужую инфраструктуру – в этом кейсе HF узнали, чей это агент, только через неделю.

- Побег = Critical Alert: выход агента за границы разрешённой сети – триггер для автоматической остановки пайплайна, не рядовая строка в логах.

Этот паттерн «слепой зоны» не уникален для AI-экосистем. Лет 15 назад, проводя сквозной аудит технологических процессов в «Лаборатории Касперского», мы выявили похожие проблемы. Одно из уязвимых место оказалось ровно там же, где споткнулась OpenAI: на стыках между подразделениями, где ответственность размывается и оказывается ничьей.

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

Возвращаясь к OpenAI: в этот раз агент дотянулся только до инфраструктуры одного вендора. А что натворит условная GPT-7 в масштабе интернета без адекватного контроля? Превентивные меры на уровне компании и безопасность на уровне архитектуры уже сейчас – на порядки дешевле, чем глобальный Incident Response потом.