Протокол Agent Payments Protocol (AP2) от Google — это открытая, нейтральная по отношению к поставщикам спецификация для выполнения платежей, инициированных агентами ИИ, с криптографическим, поддающимся проверке доказательством намерений пользователя.
Проблема, которую решает AP2:
Сегодняшние платёжные системы предполагают, что человек сам нажимает «купить». Когда автономный или полуавтономный агент инициирует оплату, продавцы и эмитенты сталкиваются с тремя нерешёнными вопросами:
* Действительно ли полномочия пользователя были делегированы (авторизация).
* Отражает ли запрос то, что пользователь имел в виду и одобрил (аутентичность).
* Кто несёт ответственность, если что-то пойдёт не так (подотчётность).
AP2 формализует данные, криптографию и обмен сообщениями, чтобы последовательно отвечать на эти вопросы у разных поставщиков и типов платежей.
Как AP2 устанавливает доверие?
AP2 использует проверяемые учётные данные (VC) — защищённые от несанкционированного доступа, криптографически подписанные цифровые объекты — для передачи доказательств в рамках транзакции. Протокол стандартизирует три типа мандатов:
* Mandate of Intent (присутствие человека не требуется): фиксирует ограничения, при которых агент может совершать транзакции (например, бренд/категория, ценовые ограничения, временные окна), подписанные пользователем.
* Mandate of Cart (присутствие человека требуется): связывает явное одобрение пользователя с корзиной, подписанной продавцом (товары, суммы, валюта), создавая неоспоримое доказательство того, что «то, что вы видели, — это то, за что вы заплатили».
* Payment Mandate: сообщает сетям/эмитентам, что участвовал агент ИИ, включая модальность (присутствие человека или его отсутствие) и контекст, имеющий отношение к риску.
Эти VC формируют аудиторский след, который однозначно связывает авторизацию пользователя с окончательным запросом на оплату.
Основные роли и границы доверия
AP2 определяет ролевую архитектуру для разделения задач и минимизации раскрытия данных:
* Пользователь делегирует задачу агенту.
* Пользовательский/торговый агент (интерфейс, с которым взаимодействует пользователь) интерпретирует задачу, согласовывает корзины и собирает одобрения.
* Поставщик учётных данных (например, кошелёк) хранит способы оплаты и выдаёт артефакты, специфичные для метода.
* Конечная точка продавца предоставляет каталог/котировки и подписывает корзины.
* Платёжный процессор продавца формирует объект сетевой авторизации.
* Сеть и эмитент оценивают и авторизуют платёж.
Человеческое присутствие и его отсутствие: что меняется в сети?
AP2 определяет чёткие, поддающиеся проверке потоки:
* Присутствие человека: продавец подписывает окончательную корзину; пользователь утверждает её в доверенном пользовательском интерфейсе, генерируя подписанный Mandate of Cart. Процессор отправляет объект сетевой авторизации вместе с Payment Mandate. При необходимости происходит усиление (например, 3DS) на доверенной поверхности.
* Отсутствие человека: пользователь предварительно авторизует Mandate of Intent (например, «купить, когда цена < 100 долларов»); позже агент преобразует его в Mandate of Cart, когда условия будут выполнены, или продавец может принудительно запросить повторное подтверждение.
Как AP2 сочетается с A2A и MCP?
AP2 описан как расширение A2A (для обмена сообщениями между агентами) и взаимодействует с MCP (для доступа к инструментам), чтобы разработчики могли повторно использовать установленные возможности для обнаружения, согласования и выполнения. AP2 специализирует уровень платежей — стандартизируя объекты мандата, подписи и сигналы подотчётности — оставляя при этом возможность совместной работы и вызова инструментов A2A/MCP.
Какие способы оплаты включены в протокол?
Протокол не привязан к конкретному способу оплаты. Первоначальное внимание уделяется распространённым инструментам, основанным на принципе «вытягивания» (кредитные/дебетовые карты), с дорожной картой поддержки переводов в режиме реального времени (например, UPI, PIX) и цифровыми активами. Для пути web3 Google и партнёры выпустили расширение A2A x402 для реализации криптоплатежей, инициированных агентами, согласовав x402 с конструкциями мандата AP2.
Что это значит для разработчиков?
Google опубликовал общедоступный репозиторий (Apache-2.0) со справочной документацией, типами Python и работающими примерами:
* Примеры демонстрируют потоки карт с участием человека, вариант x402 и цифровые платёжные данные Android, показывая, как выдавать/проверять мандаты и переходить от переговоров агентов к сетевой авторизации.
* Пакет типов: основные объекты протокола доступны в src/ap2/types для интеграции.
* Выбор фреймворка: хотя в примерах используются ADK от Google и Gemini 2.5 Flash, AP2 не зависит от фреймворка; любой агентский стек может генерировать/проверять мандаты и использовать протокол.
Как AP2 обеспечивает конфиденциальность и безопасность?
Разделение ролей в AP2 гарантирует, что конфиденциальные данные (например, PAN, токены) остаются у поставщика учётных данных и никогда не проходят через общие агентские поверхности. Мандаты подписываются с использованием проверяемых идентификаторов и могут содержать сигналы риска без раскрытия полных учётных данных контрагентам. Это согласуется с существующими элементами управления (например, усиленной аутентификацией) и предоставляет сетям явные маркеры участия агента для поддержки логики управления рисками и спорами.
Что насчёт готовности экосистемы?
Google сотрудничает с более чем 60 организациями, включая сети, эмитентов, шлюзы и технологических поставщиков (например, American Express, Mastercard, PayPal, Coinbase, Intuit, ServiceNow, UnionPay International, Worldpay, Adyen). Цель — избежать индивидуальных интеграций, согласовывая общие семантики мандата и сигналы подотчётности на разных платформах.
Примечания по реализации и крайние случаи
* Детерминизм над выводом: продавцы получают криптографическое доказательство того, что пользователь утвердил (корзину) или предварительно авторизовал (намерение), а не сводки, сгенерированные моделью.
* Споры: цепочка учётных данных функционирует как доказательный материал для сетей/эмитентов; подотчётность может быть назначена в зависимости от того, какой мандат был подписан и кем.
* Проблемы: эмитент или продавец могут инициировать усиление; AP2 требует, чтобы задачи выполнялись на доверенных поверхностях и были связаны с трассировкой мандата.
* Несколько агентов: когда участвует более одного агента (например, метапоиск для путешествий + авиакомпания + отель), A2A координирует задачи; AP2 гарантирует, что каждая корзина подписана продавцом и авторизована пользователем, прежде чем будет произведена оплата.
Что будет дальше?
Команда AP2 планирует развивать спецификацию в открытом формате и продолжать добавлять эталонные реализации, включая более глубокую интеграцию с сетями и web3, а также согласование со стандартами форматов VC и идентификационных примитивов. Разработчики могут начать уже сегодня, запустив примеры сценариев, интегрировав типы мандатов и проверив потоки на соответствие своим стекам агентов/продавцов.
Резюме
AP2 даёт агентской экосистеме конкретный, криптографически обоснованный способ доказать авторизацию пользователя, привязать её к подписанным продавцом корзинам и представить эмитентам поддающийся проверке отчёт — не привязывая разработчиков к единому стеку или способу оплаты. Если агенты будут покупать что-то от нашего имени, именно такой след доказательств нужен платёжной системе.
1. Какие проблемы решает протокол Agent Payments Protocol (AP2) от Google?
Протокол Agent Payments Protocol (AP2) решает три основные проблемы платёжных систем:
* авторизация (действительно ли полномочия пользователя были делегированы);
* аутентичность (отражает ли запрос то, что пользователь имел в виду и одобрил);
* подотчётность (кто несёт ответственность, если что-то пойдёт не так).
2. Какие типы мандатов используются в AP2 и для чего они нужны?
В AP2 используются три типа мандатов:
* Mandate of Intent (присутствие человека не требуется) — фиксирует ограничения, при которых агент может совершать транзакции, подписанные пользователем.
* Mandate of Cart (присутствие человека требуется) — связывает явное одобрение пользователя с корзиной, подписанной продавцом.
* Payment Mandate — сообщает сетям/эмитентам, что участвовал агент ИИ, включая модальность (присутствие человека или его отсутствие) и контекст, имеющий отношение к риску.
Эти мандаты формируют аудиторский след, который однозначно связывает авторизацию пользователя с окончательным запросом на оплату.
3. Как AP2 обеспечивает конфиденциальность и безопасность платёжных операций?
Разделение ролей в AP2 гарантирует, что конфиденциальные данные (например, PAN, токены) остаются у поставщика учётных данных и никогда не проходят через общие агентские поверхности. Мандаты подписываются с использованием проверяемых идентификаторов и могут содержать сигналы риска без раскрытия полных учётных данных контрагентам. Это согласуется с существующими элементами управления (например, усиленной аутентификацией) и предоставляет сетям явные маркеры участия агента для поддержки логики управления рисками и спорами.
4. С какими организациями сотрудничает Google для внедрения AP2?
Google сотрудничает с более чем 60 организациями, включая сети, эмитентов, шлюзы и технологических поставщиков (например, American Express, Mastercard, PayPal, Coinbase, Intuit, ServiceNow, UnionPay International, Worldpay, Adyen). Цель — избежать индивидуальных интеграций, согласовывая общие семантики мандата и сигналы подотчётности на разных платформах.
5. Какие планы у команды AP2 по развитию протокола в будущем?
Команда AP2 планирует развивать спецификацию в открытом формате и продолжать добавлять эталонные реализации, включая более глубокую интеграцию с сетями и web3, а также согласование со стандартами форматов VC и идентификационных примитивов. Разработчики могут начать уже сегодня, запустив примеры сценариев, интегрировав типы мандатов и проверив потоки на соответствие своим стекам агентов/продавцов.