Идентификация в агентской коммерции: Visa TAP, Google AP2 и Mastercard Agent Pay (RU)

Основные выводы

• Протокол Visa Trusted Agent Protocol (TAP), Google Agent Payments Protocol (AP2) и Mastercard Agent Pay делают покупки, совершаемые агентами, безопаснее, но они решают разные аспекты проблемы доверия.
• TAP помогает продавцам распознавать утвержденных агентов и проверять подлинность намерения совершить покупку. AP2 создает доказательства того, что пользователь авторизовал. Agent Pay объединяет зарегистрированных агентов, токенизированные платежные данные, согласие и прозрачность сети.
• Ни один из этих механизмов не устраняет необходимость доказывать, кто является физическим или юридическим лицом, проверять риски, применять меры контроля, специфичные для юрисдикции, и сохранять аудиторский след.
• Didit — это нейтральная инфраструктура для идентификации и борьбы с мошенничеством, а не карточная сеть или платежная компания. Ее размещенный сервер Model Context Protocol (MCP) предоставляет 115 инструментов в 11 категориях, а Representational State Transfer (REST) Application Programming Interface (API) поддерживает встроенные производственные процессы.
• Полный пакет KYC стоит $0.33, каждая учетная запись включает 500 бесплатных проверок в месяц, а сам сервер MCP бесплатен.

Агентская коммерция начинается, когда агент искусственного интеллекта (ИИ) делает больше, чем просто рекомендует продукт. Он сравнивает предложения, собирает корзину, выбирает способ оплаты и может завершить покупку в пределах, установленных физическим или юридическим лицом. Этот сдвиг сразу же порождает несколько вопросов доверия: Какой агент сделал запрос? Кто его авторизовал? Кто является физическим или юридическим лицом, стоящим за ним? Разрешена ли транзакция? И какие доказательства будут существовать в случае оспаривания покупки?

Появляющиеся платежные стандарты отвечают на важные части этой последовательности. Они не все отвечают на одну и ту же часть, и их не следует рассматривать как взаимозаменяемые. Для разработчиков полезный вопрос заключается не в том, какой бренд «победит». А в том, какие средства контроля остаются необходимыми при любой заслуживающей доверия архитектуре.

Три стандарта, три границы доверия

Visa TAP: может ли продавец распознать этого агента и доверять ему?

Протокол Visa Trusted Agent Protocol ориентирован на продавца. Его основная задача — помочь продавцу отличить утвержденного коммерческого агента от обычного краулера, вредоносного бота или неизвестной автоматизации. Агент подписывает запрос с ограниченными по времени и целенаправленными учетными данными. Продавец или его поставщик защиты проверяет подпись и может решить, разрешить ли просмотр, оформление заказа или более узкое действие.

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

Этот потребительский сигнал не автоматически эквивалентен свежей проверке личности. Модель Visa включает роль поставщика идентификационных данных на более высоком уровне, но продавцу по-прежнему нужна политика для нового или высокорискового клиента: какие доказательства были проверены, насколько сильна гарантия, требуется ли KYC и когда необходима повторная проверка. TAP может передавать доверенную информацию о личности, не предписывая каждое решение о регистрации в конкретной юрисдикции.

Google AP2: что пользователь разрешил агенту купить?

Google Agent Payments Protocol фокусируется на авторизации и доказательствах. Он использует подписанные мандаты для связи намерения пользователя, содержимого оформления заказа и оплаты. Открытый мандат может предоставить агенту ограниченное усмотрение, например, ограничения продавца или лимиты расходов. Закрытый мандат связывает одобрение с конкретной корзиной и суммой. Квитанции завершают цепочку доказательств.

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

Этот дизайн отвечает на вопрос «Разрешил ли этот человек это действие при таких условиях?» более прямо, чем на вопрос «Как этот человек был изначально проверен?». Рамки авторизации AP2 предполагают, что соответствующие регистрационные и пользовательские учетные данные существуют. Поэтому разработчику по-прежнему необходим процесс проверки личности и жизненного цикла учетных данных, прежде чем эти мандаты смогут нести значимую гарантию.

Mastercard Agent Pay: может ли сеть распознавать и управлять агентским платежом?

Mastercard Agent Pay основан на токенизации платежей. Рамки принятия Mastercard регистрируют и проверяют агентов, присваивают уникальный идентификатор агента и используют агентские токены, чтобы транзакции были отслеживаемыми, а платежные данные оставались защищенными. Распознавание, ориентированное на продавца, может работать с существующей инфраструктурой оформления заказа, в то время как более глубокие интеграции поддерживают более богатый обмен данными.

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

Agent Pay наиболее силен в вопросах безопасности платежных данных, видимости агента и сетевых средствах контроля. Он не снимает с продавца обязательства решать, когда применяются проверка личности, KYB, AML-проверка, возрастные проверки или расширенный анализ. Эти решения зависят от продукта, клиента, транзакции и юрисдикции, а не только от платежной системы.

Где стандарты пересекаются — и где еще применима идентификация

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

• TAP: распознавание агента и подписанное намерение на границе продавца, с опциональными связанными сигналами потребителя и платежа.
• AP2: криптографические артефакты авторизации, которые связывают намерение пользователя с результатами оформления заказа и оплаты.
• Agent Pay: зарегистрированные агенты, токенизированные платежные данные, согласие, аутентификация и прозрачность в рамках карточной сети.

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

Идентификация агента отвечает на вопрос «какое программное обеспечение действовало?». Авторизация отвечает на вопрос «что ему было разрешено делать?». Проверка личности отвечает на вопрос «кто стоит за этим?». Средства контроля мошенничества и соответствия отвечают на вопрос «должно ли это действие быть выполнено?»

Что разработчикам придется создавать независимо от того, какой подход победит

• Регистрация и проверка. Проверьте физическое или юридическое лицо перед предоставлением многоразовых учетных данных или делегированных полномочий на расходы. Применяйте KYC, KYB, проверку жизнеспособности, документов, баз данных или биометрические проверки в соответствии с риском.
• Привязка учетных данных. Привяжите проверенный субъект к учетной записи, устройству, ключу доступа, кошельку или другим учетным данным, которые могут участвовать в агентском потоке.
• Авторизация с ограниченной областью действия. Установите ограничения, такие как продавец, категория, сумма, частота, срок действия и необходимость возвращения человека для одобрения.
• Принятие решений о рисках во время выполнения. Проверяйте человека, компанию, кошелек и транзакцию в момент действия. Контроль «Знай свою транзакцию» (KYT) и AML-проверки остаются актуальными, даже если намерение подписано.
• Отзыв и восстановление. Остановите делегированные полномочия, когда учетные данные скомпрометированы, пользователь отзывает согласие или меняется риск.
• Аудируемость. Сохраняйте результат проверки, артефакт авторизации, идентификатор агента, решение по транзакции, временные метки и последующие действия по проверке в качестве отдельных доказательств.

Этот многоуровневый дизайн намеренно нейтрален по отношению к стандартам. Команда может принять TAP на стороне продавца, мандаты AP2 в рабочем процессе агента, Agent Pay для расчетов по картам или их комбинацию. Решение по идентификации и борьбе с мошенничеством остается переносимым, поскольку оно не встроено в одну платежную сеть.

Как Didit справляется с половиной задач по идентификации сегодня

Didit предоставляет инфраструктуру для идентификации и борьбы с мошенничеством, используемую 2000+ компаниями в производстве. Те же возможности доступны через размещенный сервер MCP для операций, управляемых агентами, и REST API для потоков, контролируемых приложениями. Для более широкого обзора архитектуры см. как сервер MCP обрабатывает проверку личности и как MCP связывает проверки личности и мошенничества для ИИ-агентов.

Размещенная конечная точка MCP — https://mcp.didit.me/mcp. Она использует Streamable Hypertext Transfer Protocol (HTTP), с Open Authorization (OAuth) 2.1, Proof Key for Code Exchange (PKCE) и динамической регистрацией клиента. Пользователь входит через Didit Business Console и предоставляет ограниченный доступ; размещенная конечная точка MCP не использует аутентификацию по API-ключу.

После авторизации агент может вызвать 115 инструментов в 11 категориях. Практическая последовательность проверки может использовать:

didit_context_get
didit_session_create
didit_verify_id
didit_verify_passive_liveness
didit_verify_face_match
didit_session_get_decision

Эти инструменты могут создать сеанс проверки, выполнить выбранные проверки и получить структурированное решение. Другие реальные инструменты включают didit_verify_aml, didit_verify_kyb_search, didit_verify_kyb_select и didit_transaction_screen_wallet. Записи с высокими последствиями остаются под контролем разрешений и поведения подтверждения подключенного пользователя.

REST API охватывает путь приложения: создавайте сеансы из своего бэкэнда, отправляйте пользователей через размещенную или встроенную проверку, используйте веб-хуки и храните решения в своей собственной системе. Запросы REST server-to-server используют заголовок x-api-key; это отличается от OAuth-аутентифицированного подключения к размещенному MCP. Прочтите обзор MCP, руководство по аутентификации и справочник по инструментам для получения подробной информации о реализации.

Ценообразование не зависит от стандарта агентских платежей. Сервер MCP бесплатен. Полный пакет KYC — проверка личности, пассивная проверка жизнеспособности, сопоставление лиц и IP-анализ — стоит $0.33, и каждая учетная запись включает 500 бесплатных проверок в месяц.

Путь реализации, нейтральный по отношению к стандартам

Начните с определения требуемой уверенности для каждого действия, а не с выбора логотипа сети. Просмотр с низким риском может требовать только распознавания агента. Создание учетной записи может требовать подтвержденной личности. Регулируемая покупка может требовать KYC или KYB плюс AML-проверку. Перевод криптовалюты может добавить проверку кошелька. Более высокие суммы или измененный риск могут вернуть человека в цикл.

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

Изучите страницу разработчика Didit MCP или ознакомьтесь с общедоступным репозиторием GitHub с разрешительной лицензией. Пользователи Claude могут добавить коннектор Didit и завершить вход через OAuth.

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