В браузерном тесте люди одобряли в среднем треть опасных запросов AI-агентов. Для команд, где безопасность AI-агентов уже сводят к ручному подтверждению команд, это неприятный сигнал: такой контроль быстро превращается в формальность. Если агент работает рядом с Git, облачными учетками и конфигами Kubernetes, цена ошибки получается слишком реальной.
6 августа, как пишет The Register, бельгийский разработчик Алекс Ваутерс (Alex Wauters) подвел итоги своей браузерной игры, имитирующей окно разрешений у AI-агента для написания кода в духе Claude Code. Игру он запустил в конце мая после довольно практичного наблюдения: схема, в которой пользователь по умолчанию должен вручную подтверждать буквально каждое действие агента, выглядит безопасной только на бумаге. В реальной работе она быстро утомляет. В игре на решение дается 60 секунд: нужно одобрять или отклонять команды, а очки снимают и за пропущенную угрозу, и за блокировку безопасного действия. По итогам более 40 тыс. запусков и 409 тыс. решений по командам выяснилось, что пользователи в среднем пропускали примерно каждый третий вредоносный запрос.
Хуже всего люди распознавали не очевидный саботаж, а команды, которые выглядели рабочей рутиной, но лезли за пределы текущей задачи. Самый частый промах — попытки читать чувствительные файлы вроде kubeconfig и AWS credentials, хотя агенту по сценарию не нужно было к ним прикасаться. Такие нарушения периметра пропускали в 35% случаев. Примерно на том же уровне проскакивали curl-запросы к неизвестным API и пакеты с тайпосквоттингом. Опасность здесь не в самой команде cat или установке пакета, а в том, что они открывают прямой путь к утечке секретов и дальнейшему выводу данных наружу. А вот явные сигналы беды вроде rm -rf по корню файловой системы или рекурсивной раздачи максимальных прав ловили заметно чаще. Инъекции в crontab и перехват git config тоже распознавали лучше.
Самый показательный эпизод — команда npm run analyze. Ее одобряли почти в 65% случаев, хотя такой скрипт может выполнить любой код, который агент заранее прописал в package.json. Ваутерс отдельно отметил неприятную деталь: история действий в игре показывала, что именно скрывается за этим скриптом, причем лог находился прямо над окном разрешения, но две трети игроков все равно нажимали подтверждение. Это уже не вопрос знания Unix-команд. Это вопрос внимания, которое быстро заканчивается, когда перед человеком сыпется поток похожих запросов, а каждый требует открыть лог, сверить изменения и понять, не подменил ли агент контекст под безобидным названием.
На этом фоне особенно хорошо видно, как изменился сам режим работы с генеративными инструментами. Если раньше AI чаще подсказывал одну строку кода и человек сразу ее проверял, то теперь агенту все чаще отдают полноценный кусок задачи, дают ему крутиться часами и смотрят на результат ближе к концу. Ваутерс прямо говорит, что такая эволюция делает модель human-in-the-loop заметно менее надежной: чтобы по-настоящему проверить безопасность команды, инженер должен остановиться, открыть файлы, посмотреть, что агент изменил, и только потом решать. В теории это правильно. На практике именно ради экономии времени команды и запускают агента. Неудивительно, что часть пользователей уходит в режим «--dangerously-skip-permissions», лишь бы многочасовой прогон не остановился через пять минут после старта.
Проблема не выглядит локальной причудой одной игры. В мае Anthropic сама писала, что по телеметрии Claude Code пользователи одобряют около 93% запросов на разрешения. Чем больше таких запросов видит человек, тем меньше внимания он уделяет каждому следующему. Компания попыталась лечить эту усталость режимом auto mode, где часть решений берет на себя модель-классификатор. Но и там речь не о серебряной пуле: по собственной оценке Anthropic, режим перехватывает около 83% «слишком рьяного» поведения агента до выполнения, а оставшиеся 17% все же проскакивают. Для дискуссии про безопасность AI-агентов это важная оговорка: автоматизация снижает шум, но не отменяет риск, особенно если агент уже работает рядом с инфраструктурой, внутренними пакетами и секретами команды.
Для разработчиков и бизнеса вывод довольно приземленный. Безопасность AI-агентов нельзя строить на бесконечной ленте всплывающих окон, где человек должен в сотый раз за день угадывать, не спрятан ли опасный шаг внутри безобидного названия. Нужны песочницы, devcontainer-окружения в облаке, более узкие права доступа и хуки, которые добавляют контекст к потенциально опасным действиям до того, как они будут одобрены автоматически. Для команд, гоняющих AI-агентов по терминалу, CI и инфраструктурным репозиториям, это уже не вопрос удобства интерфейса. Ошибка здесь похожа не на лишний diff, а на полноценный инцидент безопасности с доступом к облаку и внутренним системам.
Главный вопрос теперь не в том, умеют ли такие системы писать код и вести рабочие сценарии. Вопрос в том, кто первым нормально переделает их модель разрешений под реальную дисциплину инженера, у которого есть дедлайны, параллельные задачи и обычная человеческая усталость. Пока рынок лечит перегрузку новыми слоями автоматики, цена одной неверной кнопки остается старой: доступ к секретам, облаку и внутренней инфраструктуре.