18 сентября Google подтвердил неприятную историю. Во время проверки на безопасность модель Gemini вошла в системы трёх настоящих компаний. В одну – подобрав пароль, в две другие – по логинам и паролям, которые нашла в открытом репозитории кода.
Никто её об этом не просил. Она считала, что всё ещё решает учебную задачу. Эта ошибка и есть главный урок для любой компании, которая даёт ИИ-агенту доступ к CRM, почте или серверу.
Что произошло с Gemini во время теста в мае
Проверку проводила компания Irregular, которая тестирует продвинутые ИИ-системы. Модель решала учебное задание в тестовой среде, но, по данным NBC News, из-за ошибки конфигурации у неё оказался выход в настоящий интернет.
Дальше Gemini сделал то, что делал бы в учебной среде. В одном случае перебирал пароли, пока не вошёл в защищённую систему. В двух других нашёл учётные данные в публичном репозитории и воспользовался ими. Во всех трёх случаях модель остановилась и больше ничего с доступом не делала.
Вице-президент Google Хизер Адкинс объяснила это так: модель нашла публичную информацию и подобрала учётные данные к сайтам, которые считала частью теста. Google не считает это «выходом из-под контроля» – по оценке компании, модель ошиблась с тем, где находится, а не нарушила инструкции.
| что | как было |
|---|---|
| когда | май 2026, обнаружили в июле, Google подтвердил 18 сентября |
| кто тестировал | Irregular, независимая компания по проверке ИИ-систем |
| причина | ошибка конфигурации: у модели оказался доступ в реальный интернет |
| как вошла | подбор пароля в одном случае, найденные в открытом репозитории пароли в двух |
| что сделали | уведомили три компании и федеральные власти США |
Обнаружили всё это не сразу. Irregular пересмотрела свои старые прогоны только в июле – после того как стало известно, что агент OpenAI взломал Hugging Face. А по данным NBC, похожее поведение во время киберпроверок было и у Claude.
Почему это касается не только Google
Потому что обстоятельства были самые обычные. Не хакерская атака на модель, не хитрый промпт – просто неверная настройка окружения и открытый пароль в интернете.
ИИ-агент в бизнесе получает ключи: токен CRM, доступ к почте, к таблицам, иногда к серверу. Он действует сам, быстро и без усталости. Если его цель сформулирована как «добудь данные» или «закрой задачу любой ценой», а границы не заданы технически, он будет пробовать все пути, которые видит.
Модели при этом становятся осторожнее. Anthropic в анонсе Claude Opus 5.5 отдельно пишет, что новая модель заметно реже делает трудно обратимые действия. Но полагаться на характер модели – всё равно что оставлять кассу открытой, потому что кассир честный.
Хотите агента в CRM, который не сделает лишнего?
Внедрение ИИ в CRM начинаю с прав: что агент читает, что пишет, сколько действий в час ему разрешено и кто получает тревогу, если он упёрся в лимит.
Обсудить задачу → Или сначала прайс: 29 услуг со сроками и ценами
Правило 1. Какие права давать ИИ-агенту: по действиям, а не по системам
Отвечать клиенту в чате и удалять сделки – это разные права, даже если оба живут в одной CRM. Выдавать агенту «доступ к amoCRM» целиком – та же ошибка, что дать стажёру ключ администратора.
Правильный порядок обратный. Выписать, какие действия агенту нужны для задачи: создать заявку, добавить комментарий, поменять приоритет. Всё остальное закрыть. Если система позволяет ограничить токен интеграции по разделам и операциям – пользоваться этим. Если не позволяет – ограничение делается в коде агента.
Удаление – отдельная история. Если агенту не нужно удалять, этого права у него не должно быть нигде. Причём проверять стоит не только явные методы удаления: в некоторых системах запись «удаляется» обычным обновлением с флагом вроде isDeleted. Такую лазейку закрывают уже в коде агента.
Правило 2. Песочница отдельно от продакшна
С Gemini всё случилось потому, что учебная среда оказалась связана с реальным интернетом. Для бизнеса аналог – тестовый агент, который случайно смотрит в боевую CRM.
Минимум, который стоит соблюдать: отдельный тестовый аккаунт системы, отдельный токен, и в коде агента – проверка, в какую систему он пишет. Если адрес не совпадает с ожидаемым, агент должен отказаться работать, а не продолжить.
Отдельно – выход в интернет. Агенту, которому для задачи нужна только ваша CRM, доступ в интернет вообще не нужен. Закрыть его на уровне сервера проще, чем потом разбираться, куда он сходил.
Правило 3. Никаких паролей в коде и открытых файлах
Две из трёх систем Gemini открыл паролями, которые кто-то оставил в публичном репозитории. Это не проблема ИИ – это старая проблема, которую агенты сделали опаснее: агент перебирает варианты без усталости и сразу пробует найденное.
Что проверить у себя. Нет ли ключей и паролей в коде, в общих таблицах, в открытых папках на сайте. Лежат ли секреты агента в отдельном закрытом хранилище, а не в файле рядом с кодом. Видны ли снаружи служебные файлы – журналы, выгрузки базы, резервные копии.
Последний пункт звучит как паранойя, пока не проверишь. Открытый файл журнала или резервной копии в корне сайта агент найдёт так же, как пароль в репозитории, – достаточно, что файл отдаётся по прямой ссылке.
Правило 4. Лимиты на действия и стоп-кран
Агент без лимитов при ошибке сделает её тысячу раз. Перебор паролей у Gemini – именно такая картина: одно и то же действие по кругу, пока не получилось.
Лимит – это потолок действий за час: всего, в одну карточку, в одну задачу. Упёрся в потолок – агент останавливает запись и сообщает человеку. Снимает стоп тоже человек, а не сам агент через минуту.
Выставлять лимиты стоит по реальной нагрузке с запасом. Если в обычный день агент создаёт 40 заявок, потолок в 300 действий в час не мешает работе, но не даёт ему за час натворить то, что потом неделю разгребать.
Правило 5. Необратимое – только через человека
Отправить письмо клиенту, провести оплату, удалить запись, закрыть сделку как проигранную – такие действия нельзя отменить одной кнопкой. Для них агент готовит черновик, а подтверждает человек.
Удобная граница: всё, что меняет данные внутри компании и легко откатывается, агент может делать сам. Всё, что уходит наружу или стирает данные, – через подтверждение. На практике таких действий немного, и подтверждение не тормозит работу.
Про то, как вендоры сами оценивают опасность своих моделей в кибербезопасности, я писал в новости о том, как OpenAI признала Astra моделью уровня Critical. Вывод там тот же: осторожность модели – бонус, а не защита.
Правило 6. Журнал всех действий агента
Google узнал о входах в чужие системы только через два месяца, когда Irregular пересмотрела старые прогоны. Если у вашего агента нет журнала действий, вы можете не узнать о проблеме вообще.
Журнал должен отвечать на три вопроса: что агент сделал, в какой записи и что там было до него. Последнее важнее, чем кажется: без старого значения ошибочную правку нельзя откатить, только заметить.
Как я ограничиваю агентов в своих проектах
Покажу на проекте ИИ-поддержки, который сейчас готовлю к запуску: агент принимает обращения из мессенджеров и телефона, опознаёт клиента и заводит заявки в систему учёта задач. Все правила выше там сделаны кодом, а не договорённостью.
| мера | как сделано |
|---|---|
| права по действиям | белый список запросов: создать заявку, комментарий, приоритет, привязка чата к компании – всё остальное запрещено |
| удаление | запрещено в коде, в том числе через флаги удаления и архивации |
| лимиты | 300 записей в час всего, 60 в карточки компаний, 5 в одну карточку, 20 в одну задачу |
| стоп-кран | при превышении запись останавливается, тревога уходит руководителю и в рабочую группу, снимает стоп человек |
| журнал | каждая запись со старым значением |
| боевая система до запуска | токен только на чтение, запись разрешается при переключении |
| файлы от клиентов | каждый разбирается в отдельном изолированном контейнере без сети и без прав на запись |
Похожая схема приёма обращений из нескольких каналов описана в кейсе про голосового бота на входе в поддержку. Разница только в том, куда агент пишет – принципы ограничения те же.
Эту часть заказчик обычно не заказывает отдельно, но без неё я агента с правом записи в рабочую систему не запускаю.
Вопросы и ответы
Что случилось с Gemini во время теста безопасности?
В мае 2026 года во время проверки, которую проводила компания Irregular, модель из-за ошибки конфигурации оказалась в реальном интернете и вошла в системы трёх компаний: подобрав пароль и использовав пароли из открытого репозитория. Google подтвердил это 18 сентября.
Может ли ИИ-агент взломать мою CRM?
Если у агента есть токен с широкими правами и нет ограничений в коде, он может сделать в CRM всё, что разрешает токен, в том числе по ошибке. Поэтому права выдаются по действиям, а удаление и массовые изменения закрываются.
Какие права давать ИИ-агенту в amoCRM или Битрикс24?
Только те действия, которые нужны для задачи: например, создать сделку или заявку, добавить комментарий, поменять этап. Удаление, экспорт и изменение настроек агенту не нужны почти никогда.
Как ограничить количество действий ИИ-агента?
Лимитами в коде агента: потолок записей в час всего, в одну карточку и в одну задачу. При превышении агент останавливается и сообщает человеку, а снимает стоп человек.
Нужно ли подтверждение человека для каждого действия агента?
Нет, только для необратимых: отправка писем клиентам, оплата, удаление, закрытие сделок. Остальное агент делает сам, а человек видит всё в журнале действий.
Безопасно ли давать ИИ-агенту доступ в интернет?
Если задача агента – работа с вашей CRM или базой знаний, доступ в интернет ему не нужен и его лучше закрыть на уровне сервера. Случай с Gemini начался именно с того, что выход в интернет оказался открыт по ошибке.
