29 августа 2026 г.
Запрос подтверждения у вашего ИИ-агента — это граница полномочий
Просите подтверждать всё — и пользователи перестанут читать. Подтверждайте только цель — и согласие станет опасно широким. Полезная граница проходит ровно там, где действие что-то меняет в реальном мире.
Пользователь говорит ИИ-агенту: «Удали песочницу Q3». Агент открывает настройки, находит рабочее пространство и добирается до кнопки удаления. Если он просит подтверждения после каждого клика, им невозможно пользоваться. Если он считает исходную фразу неограниченным согласием, он безрассуден. Если в конце он спрашивает «Продолжить?», пользователь всё равно не понимает, что произойдёт. Сложное продуктовое решение не в том, оставлять ли человека в контуре. А в том, где этот контур начинается, что именно одобряет человек и когда это одобрение перестаёт действовать.
Поэтому запрос подтверждения нужно считать частью модели полномочий, а не вежливым трением, которое добавили, когда агент был уже готов.
Две плохие крайности
Первый плохой вариант — подтверждать каждое изменение состояния. Открыть страницу оплаты? Подтвердите. Выбрать вкладку с годовой оплатой? Подтвердите. Вписать название компании? Подтвердите. Продукт выглядит осторожным, но бесконечные запросы приучают пользователей одобрять машинально. Система создала театр согласия: кликов много, внимания мало.
Противоположный вариант спрашивает один раз, в самом начале: «Я наведу порядок в рабочем пространстве. Начинать?» Звучит эффективно — пока задача не разрастается до архивации записей, удаления участников и отправки итогового письма. Пользователь одобрил цель, а не каждое последствие. Широкая инструкция на естественном языке превратилась во временную роль администратора.
Обе ошибки происходят оттого, что диалог используют как слой авторизации. Диалог хорошо помогает установить намерение. Но плохо определяет, какое именно право выдаётся.
Таксономия сбоев ИИ-агентов, которую Microsoft опубликовала в 2026 году, прямо формулирует ту же мысль с точки зрения безопасности. Она рекомендует детерминированную проверку человеком, отдельное подтверждение для промежуточных действий с последствиями, описания, построенные на реальных вызовах инструментов, и уровни подтверждения в зависимости от обратимости и радиуса поражения. Обеспечивать границу должно приложение, а не модель.
Если от одной фразы в объяснении агента зависит, появится ли проверка, значит, проверкой управляет текст. Настоящей границей полномочий управляет действие, которое приложение вот-вот выполнит.
Классифицируйте последствие, а не кнопку
Команды часто начинают со списка опасных слов: удалить, отправить, оплатить, отменить. Это полезно, но текст на кнопке — ещё не политика. «Отменить» может закрыть диалоговое окно, а может прекратить подписку. «Убрать» может сбросить фильтр, а может отозвать у человека доступ. «Продолжить» может оказаться последней кнопкой перед покупкой.
Для классификации нужны само действие, его объект и окружающее состояние. Практичную политику можно начать с пяти вопросов:
1. Создаёт ли действие внешний эффект — сообщение, приглашение, публикацию или опубликованное изменение?
2. Перемещает ли оно деньги или создаёт финансовое обязательство?
3. Меняет ли оно то, у кого есть доступ к данным и какие у кого права?
4. Удаляет ли оно данные, закрывает аккаунт или меняет подписку?
5. Если это ошибка, сможет ли тот же пользователь быстро и полностью её отменить?
Такая граница полезнее, чем правило «любая запись требует подтверждения».
Предлагаемое действие · Поведение по умолчанию · Почему
Прочитать страницу, выполнить поиск, отфильтровать или открыть вкладку · Выполнять · Нет долговременного внешнего эффекта
Заполнить поле черновика без чувствительных данных · Выполнять, оставляя действие на виду · Обратимо до отправки
Изменить локальную настройку с понятной отменой · Обычно выполнять · Малый радиус поражения, легко откатить
Отправить, опубликовать, пригласить, поделиться или изменить доступ · Показывать точное действие на проверку · Затрагивает другого человека или пересекает границу
Купить, повысить тариф, отменить, закрыть или удалить · Показывать на проверку непосредственно перед выполнением · Затрагивает деньги или трудно обратимо
Ввести учётные данные или принять регулируемое решение · Требовать, чтобы пользователь сделал это сам, или отказываться · Одного подтверждения мало, чтобы любое действие стало допустимо делегировать
Это близко к модели рисков инструментов из руководства OpenAI по созданию агентов: там инструменты предлагают оценивать по доступу на запись, обратимости, правам аккаунта и финансовым последствиям. Главное — превратить эти свойства в код и политику, а не в ещё одну инструкцию, которую модель может творчески истолковать.
Спрашивайте там, где наступают последствия
Подтверждение должно появляться как можно позже, но до внешнего эффекта.
Возьмём просьбу «Отмени мою подписку Growth». Агент может открыть настройки, перейти в раздел оплаты и посмотреть текущий тариф, никого не прерывая. Ни один из этих шагов ни к чему пользователя не обязывает. Полезная проверка появляется, когда агент нашёл настоящую кнопку Отменить подписку и знает, какую подписку она затрагивает.
В этот момент у запроса есть конкретные факты. Он может назвать действие и объект, а не пересказывать исходную просьбу. И пользователя не просят одобрить операцию, которую агент, возможно, даже не сумеет найти.
Здесь есть чёткое различие:
– Уточнение нужно, когда задуманное действие или его объект неоднозначны. Просьба «Удали Alex из команды» требует вопроса, если участников по имени Alex двое.
– Подтверждение нужно, когда действие понятно и приложение готово выполнить шаг с последствиями. Это должен быть строго ограниченный выбор: «Разрешить» или «Отклонить».
Если смешать одно с другим, диалоги начинают сводить с ума. Агент спрашивает «Вы уверены?», хотя ещё не знает, какую запись имел в виду пользователь. Или сначала получает одобрение, потом натыкается на другую кнопку подтверждения и считает прежний ответ разрешением на это новое действие.
Безопаснее такая последовательность: намерение, определение объекта, проверка, выполнение. Если позже сайт сам просит подтверждения, это новое исполняемое действие, и для него нужно отдельное решение.
Запрос должен описывать исполняемое действие
Агент может говорить «Я просто навожу порядок в рабочем пространстве», а следующим вызовом инструмента удалить участника. Неважно, что стоит за этим расхождением: злой умысел, инъекция или обычная ошибка. Интерфейс подтверждения не может полагаться на рассказ агента о том, какие полномочия он запрашивает.
Вместо этого стройте текст проверки из объекта выполнения. Показывайте элемент управления, объект, выбранное значение, адресата и нужную область действия — такими, какими их определило приложение. «Нажать „Удалить аккаунт“ для Acme» — полезно. «Продолжить уборку» — нет.
В таксономии Microsoft слабый вариант называется «отмыванием описания» (description laundering): агент показывает безобидное резюме, за которым скрывается действие с куда более серьёзными последствиями. Предлагаемая защита проста. Генерируйте описание для подтверждения из реального вызова инструмента или элемента страницы, а не из свободного текста модели.
Это важно, даже когда систему никто не атакует. Модели ужимают формулировки. Опускают уточнения. Говорят «его» и имеют в виду не тот объект. У слоя выполнения уже есть точные аргументы — проверка должна опираться на них.
– Она появляется, потому что детерминированная политика классифицировала исполняемое действие, а не потому, что модели вздумалось спросить.
– Она называет действие, объект, адресата и область действия словами, которые пользователь может проверить.
– Она даёт настоящую возможность отказаться и не прячет шаг с последствиями внутри пакета действий.
– Она разрешает одну попытку, а не весь остаток диалога.
Согласие должно быть разовым и привязанным к состоянию
Самый недооценённый вопрос возникает после того, как пользователь нажал «Разрешить»: что именно санкционировал этот клик?
Допустим, в проверке было написано «Удалить песочницу Q3». Пока карточка была открыта, страница перерисовалась, и элемент под ней теперь указывает на рабочее пространство продакшена. Или сменился маршрут. Или у формы сменился получатель. Если подтверждение хранится как булев флаг approved, агент может выполнить действие в состоянии, которого пользователь никогда не видел.
Вместо этого подтверждение должно быть привязано к отпечатку ожидающего действия. В него могут входить идентификатор элемента, тип действия, подпись объекта, адресат, состояние формы, контейнер, источник (origin) и маршрут. Непосредственно перед выполнением приложение сравнивает текущее действие с тем, которое проверил пользователь.
Если изменилось хоть что-то важное для безопасности, выполнение останавливается. Старое подтверждение при этом всё равно считается израсходованным, поэтому его нельзя использовать повторно, когда страница вернётся в прежний вид. Если выполнение прошло успешно, подтверждение тоже израсходовано. Одна проверка, одна попытка, один неизменный объект.
Это не лишние церемонии. Тот же принцип лежит в основе подписанных запросов и одноразовых токенов: полномочия должны быть узкими, атрибутируемыми и недолговечными. Рекомендации Microsoft для прикладного уровня указывают: проверка человеком нужна, чтобы агенты не могли сами разрешать себе действия с последствиями, причём триггеры обеспечивает код, а вмешаться можно прямо во время выполнения. Согласие, привязанное к состоянию, — это способ сохранить этот принцип в динамическом интерфейсе.
Подтверждение — лишь один слой, а не вся система безопасности
Даже хорошо продуманный запрос не вынесет на себе всю модель безопасности. Пользователь может одобрить плохое действие, потому что объект описан путано. Промпт-инъекция может исказить путь, который привёл к проверке. Скомпрометированная страница может показать вводящий в заблуждение контекст. А некоторые задачи должны оставаться вне полномочий агента, какое бы согласие ни дал пользователь.
В системной карточке ChatGPT agent от OpenAI подтверждения стоят в одном ряду с обучением модели, автоматическими мониторами, ограниченными возможностями и активным надзором в чувствительных контекстах. Такая многослойная структура — правильная ментальная модель. Подтверждение ограничивает ущерб от ошибки. Но оно не доказывает, что предшествующие рассуждения были верными.
Остальной системе по-прежнему нужны:
– доступ к инструментам и данным по принципу минимальных привилегий;
– детерминированные запреты на недопустимые объекты и чувствительные поля ввода;
– кнопка остановки во время многошаговой задачи;
– повторное чтение интерфейса после каждого действия;
– финальная сверка с запрошенным результатом, прежде чем заявлять об успехе;
– логи, которые связывают запрос пользователя, проверку, выполнение и результат.
Финальная сверка особенно важна. Согласие означает «можешь попробовать выполнить именно это действие». Оно не означает, что клик сработал, что изменилось нужное состояние или что задача выполнена.
Что мы выбрали для Barkan
В режиме выполнения, когда задачу за пользователя делает сам Barkan, рутинная навигация и обратимые действия в интерфейсе обходятся без парада подтверждений. Виджет сам останавливается прямо в браузере перед действиями, которые отнесены к удалению данных, изменению аккаунта или подписки, движению денег, внешней коммуникации или изменению доступа. Проверку запускает путь выполнения, а не усмотрение модели.
Разрешение, данное при проверке, привязывается к текущему объекту действия и состоянию страницы, а затем расходуется на первой же попытке выполнения. Если объект изменился, подтверждение нельзя использовать повторно. Если сайт открывает собственное финальное подтверждение, эта кнопка проверяется как отдельное действие. После выполнения действий Barkan заново читает отрисованную страницу и проводит отдельный шаг финальной сверки, прежде чем сообщить, что всё готово.
Эти решения добавляют трение ровно там, где мы его хотим. Цель — не максимальная автономность и не максимальная осторожность. А максимум полезной работы в пределах границы полномочий, понятной пользователю.
Измеряйте границу, а не только одобрения
Сама по себе доля одобрений — плохая метрика успеха. Доля одобрений в 99% может означать, что агент всегда прав. А может — что запросы настолько частые и расплывчатые, что пользователи их уже не читают.
Отслеживайте систему как механизм контроля:
– Покрытие проверками: действия с последствиями, которые были остановлены до выполнения.
– Доля ложных остановок: безобидные действия, которые вызвали проверку.
– Решения по категориям: одобрения и отказы для удаления, денег, коммуникаций, доступа и изменений аккаунта.
– Отказы из-за устаревшего согласия: попытки, заблокированные потому, что объект или состояние изменились во время проверки.
– Подтверждённое выполнение: одобренные действия, чьё целевое конечное состояние затем подтвердилось.
– Остановки и корректировки: задачи, которые пользователи прервали или перенаправили до шага с последствиями.
Затем изучайте примеры с обоих краёв: действия с последствиями, которые проскочили мимо проверки, и безобидные действия, которые раздражали пользователей. Политика становится лучше, когда сокращаются обе группы, а не когда каждую задачу толкают к ещё большему числу подтверждений.
Запрос подтверждения — это момент, когда ИИ-продукт превращает предсказание в полномочие. Относитесь к нему так же строго, как к выдаче прав доступа. Пусть агент быстро проходит обратимую работу, останавливается ровно на действии с последствиями, показывает, что на самом деле будет выполнено, — и пусть каждое «да» сгорает после одной попытки.
Barkan выполняет многошаговые задачи в вашем продукте и останавливается ровно на действии с серьёзными последствиями — до того, как оно выполнится.
«Большинству пользователей не нужен ещё один ответ. Они хотят, чтобы им показали путь или чтобы всё сделали за них. В этом весь продукт.»
Gabriel Lancelot
Сооснователь Barkan
