Gemini CLI 0.61.0 теперь требует явного подтверждения перед правкой файлов сборки и запуском команд, на которые мог повлиять недоверенный контент. Для команд разработки это не косметика, а защита от неприятного класса атак: когда агент читает репозиторий, документацию или внешний тикет и принимает спрятанную там инструкцию за волю пользователя.
Изменение описывает The New Stack: патч связан с pull request #29250 в репозитории google-gemini/gemini-cli, который был смержен 11 сентября 2026 года. Его название достаточно прямолинейно: защита от косвенной prompt injection через изменения build-файлов и недоверенные флаги команд. То есть Google закрывает не дыру в модели как таковой, а риск в обвязке вокруг агента — там, где LLM получает доступ к файлам, shell-командам и контексту из внешних источников.
Сценарий атаки выглядит буднично, поэтому и опасен. Агенту дают задачу: поправить тесты, обновить зависимость, разобраться с ошибкой сборки. По пути он читает package.json, Makefile, pyproject.toml, BUILD.bazel, README, issue из трекера, страницу из веба или ответ MCP-сервера. Если в этом контенте спрятана инструкция для модели, агент может воспринять ее как часть задания. Дальше начинается магия, которую никто не заказывал: правка build-конфига, добавление флага к команде, запуск npm run, make, cargo или другой сборочной команды уже с чужой подсказкой на борту.
Новый механизм делает две вещи. Во-первых, Gemini CLI отслеживает создание и изменение build-конфигураций в рамках сессии. Если такие файлы были затронуты, последующие команды сборки или тестирования выводятся пользователю на подтверждение. Во-вторых, CLI анализирует параметры команд, которые могли быть сформированы под влиянием внешнего контекста: веб-выдачи, Google Docs, Buganizer, MCP-ответов и других источников, помеченных как недоверенные. Если параметр выглядит как продукт такого контекста, агент больше не должен тихо протаскивать его в shell.
В pull request также поменяли интерфейс подтверждения: он должен показывать, что именно выглядит рискованным — недавние изменения build-файлов или конкретные параметры команды. Это важная деталь. Окно «разрешить действие?» быстро превращается в белый шум, если не объясняет, почему оно вообще появилось. Разработчик в потоке работы и так нажимает Enter чаще, чем хотелось бы признавать. Хороший security UX обязан не просто тормозить процесс, а давать повод задуматься на полсекунды раньше, чем команда уйдет в терминал.
Контекст шире одного инструмента Google. Автономные coding agents продают разработчику удобную сделку: «дай мне репозиторий, задачу и доступ к инструментам, а я сам пройду путь от анализа до патча». Но именно эта автономность размывает границу между данными и командами. README, комментарий в issue, markdown-документ, ответ внутреннего сервиса или сгенерированный diff для агента выглядят как текст. Для злоумышленника это поверхность атаки. Для бизнеса — вопрос, можно ли пускать такие инструменты в репозитории с секретами, приватной логикой и CI/CD без дополнительной изоляции.
Особенно неприятна зона build-файлов. Они не выглядят как исполняемый код в привычном смысле, но часто определяют, что именно запустится на машине разработчика или в пайплайне. Package scripts могут дернуть произвольную команду. Makefile исторически умеет почти все. Конфигурации сборки в больших монорепозиториях связаны с тестами, генерацией кода, публикацией артефактов и доступом к окружению. Если агент незаметно меняет такой файл, а потом сам же запускает тесты, получается короткая дорожка от текстовой подсказки до выполнения команды.
Для российских и русскоязычных команд практический вывод простой: AI-агента нельзя рассматривать как «умный автокомплит». Это процесс с правами на чтение, запись и запуск команд. Его нужно вписывать в модель угроз так же, как CI-раннер, bot account или скрипт деплоя. Минимальный набор гигиены: не давать агенту лишних секретов в окружении, запускать его в контейнере или sandbox, требовать подтверждения для shell-команд, внимательно относиться к внешним issue и документам, не включать бездумные режимы полного автопилота в рабочих репозиториях.
При этом стоп-кран не отменяет пользу агента. Наоборот, такие изменения показывают, куда рынок движется: от «модель умеет писать код» к «система умеет безопасно действовать в инженерной среде». Победят не самые разговорчивые помощники, а те, кто лучше различает пользовательскую волю, содержимое файла и чужую инструкцию, подброшенную по дороге. Подробности разбора опубликованы у , а главный вопрос для команд остается прикладным: какие действия AI-агента вы готовы доверить автоматике, а где человек все еще должен держать палец на кнопке подтверждения?