> ## Documentation Index
> Fetch the complete documentation index at: https://veriqa.app/docs/llms.txt
> Use this file to discover all available pages before exploring further.

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

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

Программный агент действует от имени человека, а на рискованную часть работы кто-то должен сказать
«да» — и такое согласие мало стоит, если собрано на том же экране, которым агент и управляет.
Зачем это нужно и кому — на странице
[«Подтверждение действий ИИ-агентов»](https://veriqa.app/whats-next/agent-approvals). Здесь —
инженерная сторона.

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

Отдельного протокола направление не требует: подтверждение действия — это та же транзакция, что и
подтверждение входа, только с другой целью. Транзакция с явным состоянием и единственным исходом,
сообщение в доверенном канале, ответ человека и запись в журнале аудита — всё это в основе 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»](/docs/ru/research/claude-code-approvals).

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

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

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

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

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

<Warning>
  Это сильный и удобный шаг для сценариев, где такому доверию есть место, но **не
  криптографическое доказательство намерения**. Мессенджер от участия в схеме не становится
  аппаратным модулем безопасности. Там, где модель рисков требует большего, нужно и большее.
</Warning>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.