Кто нажимает кнопку: как устроены разрешения у ИИ-агентов

Агент, которому вы дали доступ к терминалу, только что предложил выполнить rm -rf в каталоге проекта — потому что «так чище». Агент с доступом к почте отправил ответ клиенту от вашего имени, пока вы отходили за кофе. Это не гипотезы: осенью 2024 года Anthropic показала Claude, работающего с компьютером напрямую (Computer Use), OpenAI выпустила Operator в январе 2025-го, а к середине 2025-го автономные агенты появились почти у всех — от Google до стартапов на LangChain. И у всех встал один и тот же вопрос: кто должен разрешать действия, которые нельзя откатить.

Что вообще случилось

Разница между чат-ботом и агентом¹ — в праве действовать. Чат-бот выдаёт текст, а вы решаете, что с ним делать. Агент сам вызывает инструменты: открывает браузер, дёргает API, запускает команды в shell, ходит в базу данных. Как только у модели появляется доступ к реальным системам, ошибка перестаёт быть опечаткой в ответе и становится удалённым продакшеном или списанием денег.

Поэтому вокруг агентов быстро сложился отдельный слой — управление разрешениями (permissions, human-in-the-loop). Его задача проста на словах и сложна на практике: разделить действия на безопасные, которые агент делает сам, и критические, которые требуют подтверждения. Спор идёт не о том, нужны ли подтверждения — их необходимость почти никто не оспаривает, — а о том, кто и когда их даёт, чтобы это не превратилось в бесконечное «Разрешить? Да / Нет» на каждый чих.

Три модели, кто разрешает

Сейчас в продуктах и фреймворках сложились три подхода к тому, кто санкционирует опасное действие агента.

• Человек на каждом шаге. Агент останавливается перед любым действием с побочным эффектом и ждёт клика. Так работают режимы подтверждения в кодовых ассистентах и Computer Use у Anthropic по умолчанию для чувствительных операций. Безопасно, но убивает смысл автономности: если вы подтверждаете каждый шаг, вы и есть исполнитель.
• Человек на критических шагах (по политике). Действия заранее делятся на классы. Прочитать файл — свободно. Отправить деньги, удалить данные, написать вовне — стоп и запрос. Именно к этому идут Operator от OpenAI (подтверждение перед вводом платёжных данных и отправкой) и корпоративные обёртки над агентами.
• Другой агент или правило. Санкцию даёт не человек, а второй компонент — модель-надзиратель или жёсткий policy engine. Быстро и масштабируемо, но вы заменяете одну модель, которая может ошибиться, второй, которая тоже может.

Автономность без границ разрешений — это не продукт, а инцидент, который ещё не случился.

Почему «человек на каждом шаге» не масштабируется

У постоянных подтверждений есть цена, и она не в деньгах, а в внимании. Когда система спрашивает разрешение сто раз подряд и девяносто девять из них безобидны, человек перестаёт читать и жмёт «Да» рефлекторно. В индустрии безопасности это называют усталостью от предупреждений (alert fatigue), и она превращает защиту в декорацию. Сотый запрос — тот самый, что стирает базу, — проходит так же не глядя, как предыдущие.

Как это выглядит у основных игроков

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

Кому это пригодится и кому нет

Тонкая настройка разрешений нужна не всем и не всегда. Разберём по сценариям.

• Пригодится: разработчик с агентом в терминале. Здесь граница очевидна — читать код и запускать тесты автономно, а команды с rm, git push --force, миграции БД — только через подтверждение. Белый список команд экономит часы и не даёт снести ветку.
• Пригодится: бизнес-процесс с деньгами. Агент, который сам оформляет заказы или платит по счетам, обязан упираться в человека на этапе списания. Здесь дешевле лишний клик, чем один ошибочный перевод.
• Спорно: агент, ходящий в чужие системы через браузер. Operator и подобные упираются в то, что чужой сайт не знает о ваших политиках. Подтверждение перед вводом карты помогает, но агент всё равно может кликнуть не туда на странице без явного платежа.
• Скорее нет: простые задачи в песочнице. Если агент работает в изолированной среде, где любое действие обратимо (одноразовый контейнер, тестовые данные), навешивать подтверждения — только мешать. Дешевле пересоздать окружение, чем спрашивать.

Практический минимум для своего агента

Если вы собираете агента сами, разграничение разрешений сводится к нескольким шагам.

1. Составьте список инструментов агента и разметьте каждый: обратимо / необратимо, есть ли внешний побочный эффект (деньги, отправка вовне, удаление).
2. Всё необратимое и внешнее закройте подтверждением по умолчанию, остальное разрешите автономно.
3. Дайте пользователю белые списки для рутины — иначе он отключит подтверждения целиком из-за усталости.
4. Логируйте каждое критическое действие с его аргументами: без журнала вы не разберёте, что именно сделал агент.
5. Изолируйте среду там, где можете: обратимость в песочнице снимает половину вопросов о разрешениях.

¹ Агент — в контексте LLM это система, где модель не только генерирует текст, но и сама вызывает внешние инструменты (функции, API, команды) в цикле «подумал — действовал — посмотрел результат», пока не решит задачу или не упрётся в ограничение.