Подтверждение действий ИИ-агентов

Программный агент действует от имени человека, а на рискованную часть работы кто-то должен сказать «да» — и такое согласие мало стоит, если собрано на том же экране, которым агент и управляет. Зачем это нужно и кому — на странице «Подтверждение действий ИИ-агентов». Здесь — инженерная сторона.

​

На чём это стоит

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

1. Серверное создание транзакции подтверждения. Приложение вызывает POST /api/transaction/confirmation, аутентифицируясь по client credentials, — без OIDC-запроса и без пользовательского редиректа. В ответе — точка входа для человека: deep link канала и тот же адрес QR-картинкой с полосой знака «Powered by Veriqa» под кодом. Исход приложение забирает запросом GET /api/transaction/{id}/result.
2. Предметный текст подтверждения. Запрос называет объявленный тип действия (action_type), и человек видит не «подтвердите вход», а сообщение этого действия: какое действие, над чем, с какими параметрами.
3. Безопасная передача данных действия. Свободный текст от приложения в сообщение пользователю не пускается — это прямой путь к подмене смысла подтверждения. Данные едут типизированными слотами (slot_values) по схеме, объявленной для типа действия, и проверяются до создания транзакции.

​

Что работает уже сегодня: агент с известными инструментами

Если агента пишете вы и его инструменты известны заранее, больше ничего не нужно. Подтверждение встраивается туда, где вызываются инструменты, а не в промпт:

1. Каждому инструменту с последствиями в вашем коде задаётся политика подтверждения: какой объявленный тип действия спрашивает человека и какие аргументы вызова заполняют его слоты.
2. Код, который вызывает инструменты, проверяет политику. Для такого инструмента он создаёт подтверждение, показывает или отправляет точку входа и ждёт исхода.
3. Инструмент выполняется только при confirmed. При declined или expired обвязка возвращает отказ результатом вызова — так же, как сообщает модели о любом другом неудавшемся вызове.

Что бы модель ни решила вызвать, инструмент с политикой без подтверждённой транзакции не выполнится. Человек читает значения слотов объявленного типа действия, а не текст, который написал агент. Запускаемый пример — samples/dotnet/inproc/agent-approval в репозитории. Агент поддержки разбирает заявку на возврат тремя инструментами: lookup_order и send_customer_email выполняются сами, а каждый вызов refund_payment ждёт, пока человек одобрит его в Telegram. Журнал прогона фиксирует, кто одобрил. Для одного разрушительного действия в обычном приложении — удалить проект, закрыть аккаунт — см. samples/dotnet/inproc/step-up: там бэкенд ещё и проверяет, что подтвердил владелец аккаунта (expected_identities). Для харнеса, инструменты которого пишете не вы, samples/claude-code показывает то же подтверждение, подключённое к Claude Code через его хуки, — см. «Подтверждения в Claude Code».

​

Чего сегодня нет

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

• словаря описания действий — общего языка для «что подтверждаем», а не свободного набора типов действий у каждого интегратора;
• поверхности интеграции для агентских платформ и протоколов работы с инструментами — например, шага подтверждения, который сервер инструментов объявляет сам;
• политик согласований вокруг подтверждений: что требует человека всегда, что — по порогу, что можно доверить один раз и переиспользовать.

​

Где проходит граница

Направление наследует границу всей остальной Veriqa: подтверждение опирается на доверенный канал человека и на API платформы этого канала.