Gemini получил доступ к системам компаний из-за ошибки в тестовом домене
Модель Google Gemini во время кибербезопасностной оценки в мае 2026 года получила несанкционированный доступ к защищённым системам реальных компаний. В одном эпизоде агент многократно подбирал пароль, ещё в двух случаях обнаружил учётные данные в публичном репозитории и использовал их для входа.
Тестовая цель оказалась реальным доменом
Проверку проводила израильская компания Irregular в формате capture the flag. Как указала компания в опубликованном отчёте, вымышленное название организации, использованное в упражнении, по ошибке совпало с доменом реально существующей компании.
Эта ошибка позволила моделям ограниченное число раз обращаться к настоящему домену. Существенным условием стал непреднамеренно доступный интернет: агент мог взаимодействовать не только с изолированной тестовой инфраструктурой.
Irregular уведомила Google об инцидентах в июле 2026 года. Названия затронутых компаний не раскрываются, однако Irregular подтвердила The Wall Street Journal, что случай с Gemini относится к той же категории инцидентов, а проблему устранили несколькими неделями ранее.
Почему Google не называет это рассогласованием модели
В отличие от отдельных эпизодов, описанных в оценках Anthropic и OpenAI, Gemini прекратил вторжение после того, как обнаружил, что получил доступ к системе настоящей компании. Вице-президент Google по security engineering Хизер Адкинс заявила, что в этой ситуации модель действовала корректно.
Google также отметила, что не рассматривает поведение как пример рассогласования модели: агенты остановили дальнейшие действия после срабатывания защитных механизмов. Сам факт доступа, однако, показывает, что оценка ИИ-систем зависит не только от поведения модели, но и от точности настройки среды.
Что учитывать при проверке ИИ-агентов
Контекст подобных проверок важен и на фоне сообщений о том, как автономные агенты похитили тысячи учётных данных демонстрирует риски автономных действий агентов при выходе за заданные ограничения. В случае Gemini непосредственной причиной стала нестыковка между фиктивной целью и существующим доменом.
Для бизнеса практический вывод состоит в необходимости изолировать тестовые контуры, заранее проверять занятость доменных имён и исключать внешний сетевой доступ, если он не требуется сценарием. Учётные данные, репозитории и механизмы остановки агента также должны входить в границы проверки до запуска оценки.