Агентные платежи: как продавцу проверить ИИ-агента, пользователя и поручение

Агентным платежом называют оплату, которую по поручению человека или организации инициирует ИИ-агент в онлайн-покупке или корпоративной закупке: он оформляет заказ и передаёт продавцу платёжные данные или токен. Специальных норм об ИИ-агентах российское право на 7 октября 2026 года не содержит. К проверке пользователя применяются общие нормы: организации из ст. 5 115-ФЗ идентифицируют клиентов, а объём данных ограничивает ч. 5 ст. 5 152-ФЗ. Перед списанием продавцу нужны ответы на три вопроса: какой агент обратился, от чьего имени он действует и укладывается ли заказ в поручение. Для ответа на второй вопрос используют KYC и KYB: агента связывают с проверенным человеком или организацией.

Кратко:

• Продавец проверяет три объекта: агента, пользователя, от имени которого действует агент, и поручение с лимитом.
• В режиме human present пользователь подтверждает конкретный заказ и сумму, в режиме human not present агент платит по заранее подписанным открытым мандатам.
• Лимит поручения продавец сверяет до подтверждения заказа; серию операций лимиты не ограничивают, для неё нужен контроль частоты.
• Проверка подписи агента подтверждает источник запроса; ни личность пользователя, ни безвредность сделки она не устанавливает.
• Единого стандарта агентных платежей на 7 октября 2026 года нет.

Чем агентный платёж отличается от обычной оплаты

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

К покупателю, продавцу и платёжному провайдеру добавляются ИИ-агент и его оператор, то есть компания, которая развернула агента и отвечает за его работу. Пользователь — физическое лицо или организация, от имени которых действует агент; в англоязычных спецификациях эту роль называют principal. С принципалом из агентского договора по гл. 52 ГК РФ термин не связан: ИИ-агент является программой и стороной договора быть не может.

Агент с корректной подписью может отправить продавцу заказ, который пользователь не одобрял, а злоумышленник может выдать свой скрипт за известного агента. Поэтому при агентном платеже продавец проверяет три объекта: агента, пользователя и поручение. Единого стандарта агентных платежей на 7 октября 2026 года нет.

Как участие пользователя в сессии меняет проверку платежа

В протоколе AP2 (Agent Payments Protocol) описаны режим присутствия пользователя (Человек в сессии / human present) и режим, в котором агент действует без него (Человек вне сессии / human not present). От режима зависит, какое подтверждение воли пользователя получат продавец и платёжная цепочка, то есть эквайер, платёжная система и банк-эмитент.

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

В автономном режиме пользователь заранее подписывает открытые мандаты: в них записаны цель покупки и ограничения, например бюджет и допустимые платёжные инструменты. Когда условия выполнены, агент сам оформляет заказ. Пользователь этот заказ не подтверждает. Его согласие продавец устанавливает по открытым мандатам, платёжным данным с лимитом и журналу операции. Чем больше времени проходит между решением пользователя и платежом, тем сильнее продавец может сократить срок поручения, снизить лимиты и ужесточить пороги антифрода.

Кого и как проверяют при агентном платеже

Агента, пользователя и продавца проверяют по отдельности: агента и пользователя проверяет продавец, самого продавца проверяет банк-эквайер. 

Агента распознают по идентификатору, версии, оператору и среде исполнения. Проверка подписи подтверждает, что запрос сформирован заявленным ключом; с конкретным человеком ключ при этом не связан. Авторы блога NIST считают, что агентам нужны собственные идентификаторы, привязанные к идентичности пользователя или системы, от имени которых агент работает. Привязку агента к пользователю описывает модель Know Your Agent.

Насколько глубоко проверять пользователя, продавец решает по сумме и характеру операции. Физическое лицо можно сверить, например, по связке имени и контактных данных, организацию по сведениям ЕГРЮЛ. Идентифицировать клиентов по Федеральному закону № 115-ФЗ обязаны организации из ст. 5 закона, остальные продавцы выбирают глубину проверки сами. Объём данных ограничивает ч. 5 ст. 5 Федерального закона № 152-ФЗ: он должен соответствовать заявленной цели обработки. Если отдельного основания нет, паспортные данные при обычной онлайн-покупке для этой цели, как правило, избыточны.

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

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

Поручение и лимит: как фиксируют намерение пользователя

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

В спецификации AP2 версии v0.2 такие записи называются мандатами: Checkout Mandate получает продавец, Payment Mandate получает платёжная цепочка, и у каждого есть открытая стадия с ограничениями и закрытая с конкретным заказом или суммой.

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

Мандат и токен подтверждают, что поручение было и что платёж ему соответствует, но оценить по ним вред от самой сделки нельзя. Агент в пределах мандата проходит проверку мандата и токена и всё равно может причинить ущерб, если пользователь ошибся в поручении или агент выполнил вредоносную инструкцию со страницы сайта (prompt injection).

Как распознать ИИ-агента и какие антифрод-сигналы учитывать

Запросы неизвестных скриптов продавец может отклонять до антифрод-скоринга. По спецификации Trusted Agent Protocol Visa агент подписывает заголовок HTTP-запроса по стандарту RFC 9421, а продавец проверяет подпись и метку типа взаимодействия: просмотр каталога или оплата. Visa и Mastercard в марте 2022 года приостановили работу в России, поэтому российский продавец может применить сам принцип: согласовать с операторами агентов ключи и формат подписи в договоре. Проверка подписи подтверждает источник запроса, но безопасность поведения агента не гарантирует: доверенный агент может работать со скомпрометированным ключом или выполнять вредоносную инструкцию.

Частоту операций (velocity) отслеживают по связке «агент + пользователь + базовая карта». Если вести учёт только по агенту, в нём смешаются операции тысяч пользователей одной платформы, а по одноразовому токену всегда будет одна операция. Номер карты продавец, как правило, не получает: платёжный провайдер передаёт вместо него отпечаток карты или маскированный номер. По этим данным продавец и контролирует частоту операций.

По сетевым сигналам продавец видит, в какой среде работает агент: с каких адресов и через какую точку входа он отправляет запросы. Если что-то из этого меняется, продавец проверяет, тот ли агент платит. По поведенческим сигналам он сравнивает заказ с привычными покупками пользователя и с заявленным типом взаимодействия. Например, если запрос помечен как просмотр каталога, а в нём есть оплата, заказ отклоняется от заявленного типа. Вместе с частотой операций эти сигналы подтверждают, что платёж выполняет заявленный агент и что заказ похож на обычные. Насколько безопасна сама сделка, по ним не определить.

Дополнительное подтверждение: кто и как его запрашивает

При высоком риске продавец или платёжная цепочка запрашивает дополнительное подтверждение (step-up). Способ выбирают по степени риска операции и по тому, где пользователь может подтвердить своё решение об оплате.

• Повторное согласие пользователя в доверенном интерфейсе: в личном кабинете продавца, в приложении оператора агента или в банковском приложении. Подтверждение карточной операции у банка-эмитента запрашивает сам банк, продавец может влиять на него настройками эквайринга.
• Проверка на живость (liveness): подтверждает, что перед камерой живой человек. Подтвердить волю конкретного пользователя одной такой проверкой нельзя.
• Ручная проверка сотрудником продавца с обращением к пользователю по известному контакту.

Сценарий отказа: заказ превышает лимит поручения

Пример построен на модели AP2 v0.2. Покупатель здесь организация: закон о защите прав потребителей и ч. 15 ст. 9 Федерального закона № 161-ФЗ к нему не применяются.

Запрос. Агент организации-покупателя работает без участия человека. Сотрудник, уполномоченный на закупки, заранее подписал открытые мандаты: в Checkout Mandate записаны цель закупки и предельная цена 100 000 руб. за заказ, в Payment Mandate тот же бюджет и разрешённая корпоративная карта. Агент согласовал с продавцом партию оборудования на 180 000 руб. и пытается оформить заказ.

Проверка. До подтверждения заказа продавец сверяет подпись, статус покупателя и сумму. Подпись запроса действительна и принадлежит заявленному агенту. Организация-покупатель ранее прошла проверку и по сведениям ЕГРЮЛ остаётся действующей. Сумма заказа превышает предел открытого Checkout Mandate в 1,8 раза.

Решение. Продавец останавливает заказ до оплаты и возвращает агенту код причины. Превышение лимита может означать сбой или компрометацию агента, поэтому продавец уведомляет контактное лицо покупателя. Провести закупку можно только по новому поручению с другим лимитом. Его подписывает сотрудник, чьи полномочия подтверждены доверенностью по ст. 185 ГК РФ или иным документом покупателя. Если продавец проверку пропустит, расхождение обнаружит участник платёжной цепочки, который получает Payment Mandate: закрытый Payment Mandate на 180 000 руб. не укладывается в бюджет открытого.

Журнал. В запись попадают идентификатор агента, версия протокола, идентификаторы мандатов, сумма, предел поручения, код причины отказа и время решения. Записи связаны общим идентификатором операции, по которому цепочку восстанавливают при споре.

Продавец проверит лимит до оплаты, только если протокол передаёт ему ограничения поручения.

С чего начать продавцу перед приёмом агентных платежей

Подготовку к приёму заказов от ИИ-агентов можно провести в шесть шагов:

1. Выяснить, какие протоколы агентных платежей поддерживают эквайер и платёжные провайдеры и как каждый фиксирует поручение пользователя.
2. Настроить распознавание известных агентов и отсекать неподписанные запросы до антифрод-скоринга.
3. Проверять лимит поручения до подтверждения заказа, если протокол его передаёт.
4. Контролировать частоту операций по связке «агент + пользователь + базовая карта» и добавить сетевые и поведенческие сигналы.
5. Определить, кто, когда и каким способом запрашивает дополнительное подтверждение.
6. Описать возвраты, хранение журнала, признаваемые подписи в договоре с оператором агента и выполнение ст. 26.1 Закона РФ № 2300-1 при продаже потребителям.

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