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

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

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

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

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

О слишком широких правах в реальной работе узнают по косвенным признакам, и их стоит знать заранее. Diff трогает файлы, которых нет в задаче. В выводе появляется сетевой вызов, которого никто не заказывал. Агент сообщает о выполненном действии вместо того, чтобы спросить разрешения. Браузер оказывается на странице, где вы авторизованы, хотя задача касалась локальной вёрстки. Ни один из этих признаков не говорит о сбое модели: инструмент сделал ровно то, что ему было позволено, и вопрос в том, кто и когда это позволил.

Типичные провалы предсказуемы. Считать, что фраза в запросе ограничивает права. Отдать в контекст вывод терминала вместе с секретами. Разрешить браузеру действия на авторизованной странице в задаче смешанного доверия. Принять текст найденной страницы за инструкцию, а не за данные. И выдать права один раз на всю сессию, не заметив, что задача за это время сменилась.