ИИ-агент с доступом к деньгам: права, лимиты и подтверждение операций

Финансовый менеджер открывает карточку счёта. Агент уже сверил поставщика с договором, нашёл заявку и подготовил платёж. На экране осталась одна кнопка: отправить деньги. В этот момент решающей становится граница полномочий модели.

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

Привет, я Антон Фокин — CEO Qtim

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

Один запрос проходит три независимые проверки

У агента нет абстрактного «доступа к деньгам». У него есть ограниченный набор вызовов: создать черновик платежа, запросить расчёт комиссии, отправить операцию конкретному получателю. Каждый вызов нужно связать с пользователем, задачей и правилами сервиса.

OWASP относит избыточные функции, права и автономию к причинам Excessive Agency. Поэтому модель не должна решать, разрешён ли платёж. Она формирует предложение, а сервис правил проверяет его детерминированно: по данным операции, роли инициатора и актуальной политике.

Практическая схема состоит из трёх проверок.

Таблица отвечает на вопрос, который часто скрывается за словом «автоматизация»: где заканчивается подготовка операции и начинается её разрешение.

Право привязывают к человеку и отдельной агентской идентичности

Первый риск появляется, когда агент вызывает платёжный API от общей технической учётной записи. Такой вызов сложно связать с инициатором, отозвать для одного пользователя и проверить по его роли.

Вместо этого полезна связка из трёх сущностей: пользователь поручает действие, агент получает отдельную сервисную идентичность, а платёжная система получает контекст операции. Сервис правил проверяет, разрешён ли именно этому пользователю именно этот вид платежа. Агентская учётная запись подтверждает происхождение вызова, но не расширяет права пользователя.

NCCoE в проекте об идентичности и авторизации программных и ИИ-агентов рассматривает идентификацию, управление доступом и авторизацию действий агентов как самостоятельную инженерную задачу. Для продуктовой команды это означает, что агентскую идентичность нужно проектировать рядом с пользовательской, а не прятать в ключе интеграции.

В нашем кейсе Poison Drop мы развивали e-commerce-продукт: работали с frontend, backend, интеграциями и инфраструктурой. В checkout профиль, заказ и оплата проходили по одному сценарию, а роли и авторизация были вынесены в отдельный контур — та же архитектурная граница нужна, когда агент получает доступ к финансовому действию.

Минимальный набор ограничений выглядит так:

1. список разрешённых операций: например, агент создаёт черновик платежа и не меняет реквизиты контрагента;
2. границы доступа к ресурсу: конкретная компания, счёт или проект вместо доступа ко всем юридическим лицам;
3. короткоживущий токен с привязкой к сессии или задаче;
4. запрет на вызовы, которых нет в продуктовой функции агента.

Эти ограничения дают ещё один полезный эффект. При инциденте команда видит, какую именно способность нужно отключить, а не выключает весь финансовый сервис.

Лимит должен жить в платёжном контуре

Фраза «агент не должен тратить больше 50 000 рублей» в системном промпте не защищает деньги. Промпт определяет поведение модели, но не блокирует API-вызов после ошибки, инъекции или сбоя в оркестрации.

Лимит работает, когда его проверяет тот же сервис, который принимает платёж к исполнению. В политике фиксируют параметры операции: сумму, валюту, получателя, период, число попыток, срок действия разрешения и допустимый тип действия. Для нового получателя или нетипичной суммы система может выбрать более строгий маршрут.

PCI в рекомендациях по ИИ в платёжных окружениях предлагает выдавать ограниченные контекстные учётные данные, логировать действия и сохранять возможность быстро отключить систему. Там же упомянуты токены и одноразовые платёжные реквизиты с ограничениями суммы, частоты, получателя и срока действия. Конкретный набор инструментов зависит от провайдера, зато принцип один: ограничение исполняется вне модели.

Например, агент может подготовить оплату счёта знакомому поставщику. Платёжный сервис сверяет компанию, договорный контур, лимит на день и статус получателя. При совпадении правил операция идёт по заданному сценарию. При выходе за лимит сервис создаёт запрос на подтверждение, даже когда модель уверена в своём решении.

В таких сценариях мы в Qtim проектируем правила доступа, лимиты и журналы как части продукта и интеграционного контура. Разработка SaaS- и PaaS-платформ помогает заложить эти механизмы до подключения модели.

Подтверждение выбирают по ущербу и обратимости

Подтверждение человека не обязано появляться перед каждым действием. Оно должно срабатывать там, где ошибка дорого стоит, плохо обратима или меняет риск-профиль операции.

Подтверждение должно показывать человеку не общий текст «разрешить?», а объект решения: получателя, сумму, основание, применённое правило и последствия. Тогда сотрудник подтверждает операцию, а не доверяет краткому пересказу модели.

У этого подхода есть возражение: много проверок замедлит процесс. Для массовых повторяемых операций ответом служит не отмена контроля, а заранее согласованная политика. Команда устанавливает ограниченные маршруты для предсказуемых действий и оставляет подтверждение для отклонений. Скорость появляется из ясных правил, а не из отключённых проверок.

Платёжный маршрут должен быть идемпотентным и наблюдаемым

Даже корректное решение нельзя считать завершённым в момент вызова API. Сеть может повторить запрос, пользователь может открыть одну задачу в двух вкладках, а оркестратор — получить таймаут между подтверждением и исполнением.

Поэтому платёжному маршруту нужен ключ идемпотентности (idempotency key): один ключ связывает предложение агента, запрос на подтверждение и попытку исполнения. Повтор того же запроса не создаёт второй платёж. Рядом нужен журнал событий: входные параметры без лишних чувствительных данных, версия политики, результат каждой проверки, ID подтверждения, ответ платёжного провайдера и действие оператора при сбое.

Журнал помогает разбирать две разные ситуации. В первой агент неверно извлёк сумму из счёта. Во второй злоумышленник попытался через содержимое письма повлиять на вызов инструмента. NIST отмечает, что агентские системы создают новые угрозы, а привычные практики кибербезопасности требуют адаптации. Без наблюдаемого маршрута эти ситуации выглядят одинаково: «платёж ушёл».

Отдельно нужен механизм аварийного отключения. Он останавливает новые вызовы платёжного инструмента, отзывает агентские токены и переводит незавершённые задачи в очередь на разбор. Возможность отключения проверяют на учениях, а не после первого инцидента.

Чек-лист до пилота

До разработки команда может пройти по восьми вопросам:

1. Какой конкретный платёжный вызов доступен агенту?
2. Кто является инициатором и как сервис получает его права?
3. Какие параметры входят в лимит: сумма, период, получатель, валюта, частота, срок?
4. Какие признаки переводят операцию в маршрут подтверждения?
5. Где сервис хранит версию политики и результат её применения?
6. Как ключ идемпотентности связывает предложение, подтверждение и исполнение?
7. Какие события попадают в журнал и кто их разбирает?
8. Как отключить агентский инструмент без остановки остального платёжного контура?

Эти вопросы полезнее обсуждать на одном сценарии: например, на оплате счёта конкретному поставщику. После этого проще увидеть, какие права действительно нужны модели, а какие появились «на всякий случай».

Агенту дают способность, а не кошелёк

Вернёмся к счёту на экране финансового менеджера. Хорошая архитектура не просит человека каждый раз угадывать, безопасно ли поведение модели. Она заранее задаёт, кто имеет право на действие, где проходит лимит и когда появляется подтверждение.

Правило для пилота: агент может предлагать и исполнять только те операции, для которых платёжный контур независимо проверяет право, лимит и маршрут подтверждения.

Обсудите с Qtim проектирование SaaS-платформы, чтобы определить границы автономии, лимиты и путь подтверждения для одного финансового сценария.