ИИ-агент с доступом к деньгам: права, лимиты и подтверждение операций
Агент сопоставляет счёт с договором, находит заявку и готовит платёж. До отправки денег платёжный контур должен независимо проверить его полномочия, лимиты и маршрут подтверждения.
У агента нет общего «доступа к деньгам». Его возможности ограничивает набор конкретных вызовов: подготовить черновик платежа, запросить расчёт комиссии, передать операцию определённому получателю. Каждый вызов связывают с пользователем, задачей и правилами сервиса.
Три проверки перед операцией
OWASP относит избыточные функции, права и автономию к причинам Excessive Agency. Модель формирует предложение, а сервис правил проверяет его детерминированно: по данным операции, роли инициатора и действующей политике.
Идентичность агента не расширяет права пользователя
Общая техническая учётная запись скрывает инициатора операции и усложняет отзыв доступа. Безопаснее связать пользователя, отдельную агентскую идентичность и контекст конкретной операции. Агентская учётная запись подтверждает происхождение вызова, но сервис авторизации проверяет права инициатора.
NCCoE рассматривает идентификацию и авторизацию действий программных и ИИ-агентов как отдельную инженерную задачу. Практически это означает список разрешённых операций, границы доступа по компании или счёту, короткоживущие токены и запрет на функции вне сценария.
В нашем кейсе Poison Drop Qtim развивал e-commerce-продукт: frontend, backend, интеграции и инфраструктуру. В checkout профиль, заказ и оплата проходили по одному сценарию, а роли и авторизация были вынесены в отдельный контур — та же архитектурная граница нужна, когда агент получает доступ к финансовому действию.
- Агент создаёт черновик платежа и не меняет реквизиты контрагента.
- Доступ ограничен конкретной компанией, счётом или проектом.
- Токен действует только в рамках задачи или сессии.
- Функции вне продуктового сценария недоступны.
Лимит исполняет платёжный контур
Инструкция в системном промпте не блокирует API-вызов после ошибки, инъекции или сбоя оркестратора. Ограничения суммы, периода, получателя, частоты, срока действия и типа операции проверяет сервис, который принимает платёж к исполнению.
PCI рекомендует для ИИ в платёжных окружениях ограниченные контекстные учётные данные, журналирование и возможность отключения. В зависимости от провайдера ограничения могут дополнительно связываться с токенами или одноразовыми платёжными реквизитами.
Правила доступа, лимиты и журналы проектируют как части SaaS- и PaaS-платформы, а не как настройки в интерфейсе модели.
Подтверждение зависит от ущерба и обратимости
Подтверждение показывает получателя, сумму, основание, правило и последствия. Предсказуемые маршруты можно заранее ограничить политикой, а отклонения переводить на человека.
Много проверок могут замедлить процесс. Для массовых повторяемых операций команда заранее согласует ограниченные маршруты и оставляет подтверждение для отклонений. Скорость создают ясные правила, а не отключённые проверки.
Наблюдаемость не даёт сбою стать вторым платежом
Ключ идемпотентности (idempotency key) связывает предложение агента, запрос на подтверждение и исполнение: повторный запрос не создаёт вторую операцию. Журнал хранит параметры без лишних чувствительных данных, версию политики, результаты проверок, ID подтверждения и ответ провайдера.
NIST отмечает новые угрозы безопасности ИИ-агентов и потребность адаптировать киберпрактики. Поэтому аварийное отключение должно останавливать новые вызовы платёжного инструмента, отзывать агентские токены и переводить незавершённые задачи на разбор.
Чек-лист до пилота
- Зафиксировать доступный агенту платёжный вызов.
- Связать инициатора с его правами.
- Описать сумму, период, получателя, валюту, частоту и срок лимита.
- Определить триггеры подтверждения.
- Хранить версию политики и её результат.
- Связать маршрут ключом идемпотентности.
- Назначить владельца журнала событий.
- Проверить аварийное отключение на учениях.
Правило для пилота: агент может предлагать и исполнять только те операции, для которых платёжный контур независимо проверяет право, лимит и маршрут подтверждения.
Обсудите с Qtim проектирование SaaS-платформы, чтобы определить границы автономии, лимиты и путь подтверждения для конкретного финансового сценария.
