Что такое агентские платежи?

Ника, редакция NodeTimes.

Агентские платежи (agentic payments) – это платежи, которые инициирует программа от чьего-то имени, и решение о том, когда платить, сколько и кому, принимает агент, а не человек. Вопрос о том, как ИИ-агенты платят на блокчейн-рельсах, – это тот же вопрос, только со стейблкоином (stablecoin) на расчётном слое (settlement leg) и подписанным мандатом (signed mandate) вместо логина. Сложность не в том, чтобы перевести деньги; сложность в том, чтобы потом доказать, что автономной системе было позволено их перевести, – поэтому каждый протокол в этой области занимает отдельный слой, а не борется за один и тот же.

Почему существующие платёжные системы не подходят агентам

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

Из сломанного допущения вытекают три отдельные проблемы:

• Авторизация: откуда продавец знает, что у агента было разрешение тратить?
• Оформление заказа: как агент завершает покупку на витрине, построенной под людей?
• Расчёт: что именно двигает деньги и как быстро они приходят?

Каждую из трёх решает свой протокол, поэтому сравнение этих протоколов лоб в лоб как соперников – самая частая ошибка в материалах о теме. Если словарь в новинку, определения держит глоссарий блокчейна; эта статья несёт только то, что нужно аргументу.

Протоколы и слой, которым владеет каждый

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

Стек может их складывать: авторизовать через AP2, провести покупку через коммерческий слой или слой оформления заказа, рассчитаться через x402 или MPP и прочитать реестры ERC-8004, прежде чем иметь дело с незнакомым агентом. Протокол, который важен конкретной команде, обычно тот, на котором уже говорит её контрагент.

Как агент доказывает, что может тратить

Авторизация в AP2 – это подписанное удостоверение, а не API-ключ. Протокол определяет мандаты как защищённые от подмены, криптографически подписанные объекты, которые едут вместе с транзакцией и дают продавцу проверяемую запись того, о чём пользователь на самом деле просил; Google опубликовал спецификацию как расширение для агентских протоколов A2A и MCP и с тех пор передал её FIDO Alliance, поэтому слой авторизации остаётся платформенно-нейтральным.

Типов мандатов три, и разница между ними важна, когда что-то идёт не так:

• IntentMandate: что агент может купить, когда рядом нет человека, – случай, у которого нет аналога на карточных рельсах.
• CartMandate: финальная корзина плюс подпись пользователя, для покупок, где человек присутствует.
• PaymentMandate: сигнал эквайерам и расчётным рельсам, что участвовал агент, чтобы они могли оценить риск.

В связке с x402 оба потока идут одновременно: мандат авторизует заказ, а подписанная полезная нагрузка x402 авторизует платёж, при этом жизненный цикл отслеживают статусы вроде payment-required, payment-submitted, payment-verified и payment-completed.

Где на самом деле двигаются деньги

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

x402 делает механику явной. Неоплаченный API-запрос получает ответ HTTP 402 со своей ценой, агент повторяет его с подписанной платёжной нагрузкой, а сервис проверяет и рассчитывается, прежде чем вернуть ответ. Такая схема убирает API-ключи, аккаунты и подписки из вызовов машина-машина, и именно это делает её привлекательной для инференса, данных и вычислений с оплатой за вызов. Кроме того, расчёт наследует свойства блокчейна в обе стороны: возвратов нет, и восстановления нет, если агент заплатил враждебному контрагенту.

Какие контроли трат нужны агентскому кошельку

Делегирование – это и есть вся поверхность риска, поэтому работающие контроли живут в кошельке, а не в протоколе. EIP-7702 – самое ясное опубликованное изложение примитива: аккаунт может подписать подключи, чьи полномочия куда слабее глобального доступа, например тратить токены ERC-20, но не ETH, тратить не более 1% баланса в день или взаимодействовать с одним приложением.

EIP-4337 даёт основу, на которой строится большинство кошельков с сессионными ключами: объект UserOperation, проверяемый контрактом EntryPoint, при этом бандлеры (bundlers) ретранслируют операции, а пеймастеры (paymasters) по желанию оплачивают газ. То, где лимит на самом деле применяется, – это кошелёк, и это то проектное решение, которое команда контролирует, а не наследует.

Что ломается первым

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

• Промпт-инъекция (prompt injection): недоверенный контент становится платёжной инструкцией, и широкий сессионный ключ её исполняет.
• Избыточное делегирование: один ключ, способный перевести весь баланс, выданный потому, что так было быстрее настроить.
• Нет пути отзыва: украденный ключ агента продолжает тратить, пока не истечёт его мандат.
• Состояние из одного источника: мост KelpDAO был опустошён именно так, когда единственному верификатору подсунули отравленные данные RPC; агент, читающий балансы с одной точки, наследует ту же границу доверия, которую описывает опубликованный разбор блокчейн-RPC.
• Ответственность: пока нет опубликованного правила о том, поглощает ли убыток продавец или кошелёк, когда агент покупает не то.

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

Более широкий контекст не криптографический: агент, который доверяет единственному источнику состояния, наследует все слабости этого источника. Это тот же вопрос доверия, на который что меняет Web3 отвечает для всего стека, а трудовая сторона сдвига – в материале Гонка ИИ без иллюзий.

Частые вопросы

Агентские платежи – это просто криптоплатежи?

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

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

Нужен ли агентским платежам вообще блокчейн?

Нет, и это доказывает карточное оформление заказа агентом: блокчейн помогает там, где у плательщика и получателя нет прежних отношений, нужна точность до долей цента или нужен расчёт без аккаунта, а где он используется, расчётный слой – это стейблкоин, например USDC.

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

Может ли ИИ-агент владеть кошельком?

Он может держать ключи, но это не одно и то же: кто держит ключ, тот может двигать средства, поэтому практичная схема – смарт-аккаунт под контролем пользователя, с ключом агента, ограниченным лимитами и отзываемым владельцем.

ERC-8004 отвечает на половину этого же вопроса про обнаружение, через реестры, которые фиксируют личность агента, репутацию и историю проверок.

Что мешает агенту перерасходовать?

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

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

С какого протокола команде начинать?

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

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