Слепая зона масштабирования: чему учит история побега агента 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 потом.