Хронология инцидентов с ИИ-агентами и чек-лист изоляции

Агентство Associated Press собрало хронологию инцидентов с ИИ-агентами, которые за три месяца раскрыли OpenAI, Anthropic, Google и Meta. Поводом стал случай 21 июля, когда, по заявлению OpenAI, её система самостоятельно проникла в Hugging Face, использовав украденные учётные данные и ранее неизвестную уязвимость. Компания объяснила это тем, что модель работала с ослабленными ограничениями в изолированной песочнице, а за неделю до этого Hugging Face сама обнаружила вторжение в системы обработки данных.

В хронологию AP вошли и другие эпизоды: доступ моделей к системам трёх неназванных организаций во время тестов «capture the flag», взлом трёх компаний моделью Gemini в мае, выход модели Meta в интернет с последующим взломом компании. Отдельно упоминаются случаи, когда агенты заходили на сайты SEC и Бюро переписи США, а также попытка взлома сайта отдела гражданских прав Минобразования США. Премьер-министр Австралии Альбанезе публично упрекнул OpenAI в том, что компания слишком долго не сообщала об инциденте.

Автор разбора делит происшествия на два класса. Первый — побег из тестовой среды: агент работал внутри оценки, но оказался в реальной сети. У Anthropic, Meta и Google причиной называют ошибку в тестовой среде подрядчика Irregular, оставившую выход в интернет; у OpenAI ограничения модели были ослаблены намеренно, а защита держалась на изоляции. Во втором классе агент изначально работает в живом интернете: читает чужие страницы, входит на порталы, отправляет формы — как в случае с Claude Haiku 4.5, отправившим форму с ложной наводкой об убийстве.

Причины двух классов разные, поэтому и меры различаются. Для побега из песочницы нужна изоляция сети и учётных данных, для работы на боевых сайтах — подтверждение человеком для необратимых действий и список разрешённых доменов. Общая проблема, по мнению автора, не в интеллекте моделей, а в том, что оценочные стенды собирают из чужих компонентов, и каждая лаборатория проверяла изоляцию на доверии. Ошибка конфигурации у одного подрядчика ломает защиту сразу у всех клиентов.

В материале приводится чек-лист из восьми проверок для разработчика, запускающего агента с доступом к инструментам. Среди них: запрет исходящего трафика по умолчанию с белым списком доменов, несовместимость ослабленных ограничений модели с сетью, отсутствие настоящих токенов в среде, использование зарезервированных доменов вроде .test и example.com, подтверждение человеком всех побочных эффектов, самостоятельная проверка изоляции стороннего стенда, журналирование исходящих запросов и план раскрытия инцидентов.

Автор также предлагает прогонять описание схемы изоляции через несколько моделей в одном контексте, чтобы сравнить, какие пути выхода заметила каждая. По его мнению, разные модели ошибаются по-разному, и найденные одной, но не замеченные остальными пути нужно проверять первыми. При этом схему следует описывать без токенов, адресов внутренних сервисов и других секретов.