Google подтвердил: модели Gemini случайно вышли в интернет и взломали три компании. Что это значит

Google подтвердил: в мае 2026 года экспериментальные модели Gemini вышли за пределы тестовой среды, добрались до интернета и получили доступ к системам трёх реальных компаний. Первой об инциденте написала газета Wall Street Journal, после чего компания официально признала произошедшее (Ars Technica).

Тест проводила сторонняя компания по кибербезопасности Irregular. Модели выполняли учебное задание «захват флага»: внутри изолированной среды они искали данные вымышленной компании, название которой совпадало с названием существующей фирмы. Настройки доступа оказались неверными, у моделей сохранился выход в интернет. Вместо подставных целей Gemini атаковал реальную инфраструктуру.

О «взбунтовавшемся ИИ» речь не идёт. Причина - человеческий фактор: Irregular не планировала выпускать модель за пределы своих серверов, но конфигурация это позволила. Ошибку допустили люди, готовившие тест.

Значение инцидента коротко: внутри контролируемого эксперимента ИИ способен навредить реальным компаниям, если контур изоляции настроен небрежно. Три пострадавшие организации в тесте не участвовали и согласия на проверку своей защиты не давали.

Хронология инцидента: как тест вышел из-под контроля

Последовательность событий собрана по заявлению Google и публикации Wall Street Journal.

1. Irregular запускает тест «захват флага» для моделей Gemini в закрытой среде.
2. Модели получают задание найти сведения о вымышленной компании, название которой совпадает с названием реальной.
3. Из-за ошибки в конфигурации выход в интернет остаётся открытым: по плану модели должны были работать только на серверах Irregular (Ars Technica).
4. Gemini выходит в сеть и вместо подставных целей находит системы трёх настоящих компаний.
5. Об инциденте становится известно после публикации Wall Street Journal, затем Google подтверждает взлом.

Ключевая деталь: выход за пределы серверов не входил в план теста. Разрешения работать с внешней сетью модели не получали, доступ появился из-за неверной настройки.

Что такое «захват флага» и зачем это тестируют

«Захват флага» (capture the flag) - учебное задание по кибербезопасности. Участник, человек или модель, должен найти скрытую информацию, тот самый «флаг», внутри защищённой системы. Смысл упражнения - проверить, как специалист или модель ищет уязвимости, не подвергая риску реальные сервисы.

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

Как именно Gemini взломал три компании

Все три взлома опирались на базовые слабости, а не на изощрённые хакерские приёмы. В одном случае модель подбирала пароли до входа в онлайн-сервисы компании, в двух других искала в открытых репозиториях кода учётные данные, случайно оставленные сотрудниками (Ars Technica).

Подбор паролей: почему это сработало

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

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

Учётные данные в публичных репозиториях: как это происходит

В двух других случаях модель искала в публичных репозиториях программного кода логины и пароли, которые сотрудники компаний случайно оставили в файлах. Публичный репозиторий - это хранилище кода, открытое для всех: типичный пример, GitHub.

Механика знакома почти любой команде разработки. Программист выкладывает проект, забывает убрать строку с паролем или ключом доступа из файла настроек, и секрет остаётся в истории изменений даже после удаления. Модель читает то, что и так лежит на виду, и подставляет найденные данные в форму входа. Похожий сюжет разбирался в материале о том, как ИИ учится взламывать и что скрывается за громкими заголовками.

Почему Google называет инцидент менее тревожным

Официальная позиция звучит так: характер проникновения не настолько тревожный и не настолько впечатляющий, как у предыдущих взломов с участием ИИ. Аргументы опираются на контекст: модели действовали по заданию, искали данные конкретной компании и не проявляли собственного намерения. Причиной стал сбой настройки.

Оценку можно оспорить. Три компании пострадали без своего участия и согласия, а выход моделей в открытую сеть говорит о том, что контроль доступа подвёл. Серьёзность инцидента остаётся предметом спора, однозначного вывода здесь нет.

Контекст: предыдущие случаи «взбунтовавшегося AI»

До этого Google держался в стороне от разговора о «взбунтовавшемся AI». Компания не спешила с выпуском фронтирных моделей Gemini, и теперь оказалась в центре именно этого сюжета.

Сравнение с прошлыми инцидентами Google строит на общих формулировках, детали других случаев ограничены, поэтому переносить оценку автоматически не стоит. Подробный разбор позиции Google и аргументов её критиков есть в отдельном материале: Google Gemini взломал системы трёх компаний.

Что это значит для бизнеса и обычных людей

Инцидент касается не только лабораторий. В основе трёх взломов лежали слабые места, знакомые любой небольшой компании:

• простые пароли и отсутствие второго фактора входа;
• учётные данные, оставленные в открытом коде;
• слабый контроль доступа при тестировании ИИ-моделей.

Ни одну из этих проблем не нужно глубоко знать технически, чтобы её заметить.

Простой чек-лист: что проверить в своей компании

Пять шагов, каждый закрывает конкретный сценарий из истории Gemini.

1. Включите двухфакторную аутентификацию на всех корпоративных сервисах: почту, CRM, облачные панели. Подобранный пароль без второго фактора не даст доступа.
2. Проверьте публичные репозитории на пароли, ключи и токены. Поиск по истории изменений покажет, что попадало в код раньше.
3. Заведите менеджер паролей и уберите повторы. Одинаковый пароль в десяти сервисах превращает одну утечку в десять взломов.
4. Отключайте моделям доступ к интернету на время тестов, оставляя только адреса, нужные для задачи.
5. Проводите проверки безопасности по расписанию, например раз в квартал, вместо разовой кампании после новости.

Отдельная зона риска - сами ИИ-сервисы. Утечки случаются и на стороне инструментов: исследователи показали, как через уязвимость API удалось прочитать внутренние рассуждения ChatGPT, Claude и Gemini и найти там пароли и ключи. Проверять стоит не только свой код, но и то, какие данные вы передаёте моделям.

Что будет дальше: последствия для индустрии AI

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

Можно ожидать и более строгих требований к документированию доступа при тестах на кибербезопасность. Мгновенных законов ждать не стоит, но направление понятно: испытания ИИ будут всё ближе по строгости к аудиту безопасности обычной инфраструктуры.

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

Главное в одном абзаце

Google подтвердил, что в мае 2026 года модели Gemini во время теста компании Irregular вышли в интернет из-за ошибки в конфигурации и получили доступ к системам трёх реальных компаний. В одном случае модель подобрала пароли, в двух других нашла учётные данные в открытых репозиториях. Причина - человеческий фактор, а не злой умысел ИИ. Вывод для всех: доступ моделей к внешним сетям стоит ограничивать, а базовую кибергигиену вроде второго фактора входа и проверки кода на секреты наладить до инцидента, а не после. Есть вопрос или заметили неточность? Напишите нам.