A Identidade no Comércio Agente: Visa TAP, Google AP2 e Mastercard Agent Pay

Principais conclusões

• Visa Trusted Agent Protocol (TAP), Google Agent Payments Protocol (AP2) e Mastercard Agent Pay tornam as compras lideradas por agentes mais seguras, mas resolvem diferentes partes do problema de confiança.
• O TAP ajuda os comerciantes a reconhecer agentes aprovados e a verificar a intenção de comércio assinada. O AP2 cria evidências do que um usuário autorizou. O Agent Pay combina agentes registrados, credenciais de pagamento tokenizadas, consentimento e visibilidade da rede.
• Nenhum desses mecanismos elimina a necessidade de provar quem é o humano ou a empresa, rastrear riscos, impor controles específicos de jurisdição e preservar um rastro de auditoria.
• A Didit é uma infraestrutura neutra para identidade e fraude, não uma rede de cartões ou empresa de pagamentos. Seu servidor Model Context Protocol (MCP) hospedado expõe 115 ferramentas em 11 categorias, enquanto a Interface de Programação de Aplicativos (API) Representational State Transfer (REST) suporta fluxos de produção incorporados.
• Um pacote completo de Know Your Customer (KYC) custa US$ 0,33, cada conta inclui 500 verificações gratuitas por mês, e o próprio servidor MCP é gratuito.

O comércio agente começa quando um agente de inteligência artificial (IA) faz mais do que recomendar um produto. Ele compara ofertas, monta um carrinho, escolhe um método de pagamento e pode concluir uma compra dentro dos limites definidos por uma pessoa ou empresa. Essa mudança cria várias questões de confiança de uma só vez: Qual agente fez a solicitação? Quem a autorizou? Quem é o humano ou a entidade legal por trás dela? A transação é permitida? E que evidência existirá se a compra for contestada?

Os padrões de pagamento emergentes respondem a partes importantes dessa sequência. Eles não respondem todos à mesma parte e não devem ser tratados como intercambiáveis. Para os desenvolvedores, a pergunta útil não é qual marca “vencerá”. É quais controles permanecem necessários em todas as arquiteturas credíveis.

Três padrões, três limites de confiança

Visa TAP: o comerciante pode reconhecer e confiar neste agente?

O Visa Trusted Agent Protocol é voltado para o comerciante. Sua principal função é ajudar um comerciante a distinguir um agente de comércio aprovado de um rastreador comum, bot abusivo ou automação desconhecida. Um agente assina uma solicitação com credenciais com tempo limitado e específicas para o propósito. O comerciante ou seu provedor de proteção verifica a assinatura e pode decidir se permite a navegação, o checkout ou uma ação mais restrita.

O TAP descreve três sinais relacionados: uma assinatura de reconhecimento de agente, uma identidade de consumidor ou dispositivo vinculada e assinada, e um contêiner de pagamento vinculado e assinado. Esta é uma separação útil. O reconhecimento de agente estabelece qual agente aprovado está presente; a intenção assinada estabelece que tipo de interação é solicitada; o sinal do consumidor pode ajudar um comerciante a reconhecer um cliente existente.

Esse sinal de consumidor não é automaticamente equivalente à prova de identidade recente. O modelo da Visa inclui uma função de provedor de identidade upstream, mas um comerciante ainda precisa de uma política para um cliente novo ou de alto risco: quais evidências foram verificadas, quão forte é a garantia, se o KYC é exigido e quando a reverificação é necessária. O TAP pode carregar informações de identidade confiáveis sem prescrever todas as decisões de integração jurisdicionais.

Google AP2: o que o usuário autorizou o agente a comprar?

O Google Agent Payments Protocol foca na autorização e na evidência. Ele usa mandatos assinados para conectar a intenção do usuário, o conteúdo do checkout e o pagamento. Um mandato aberto pode dar ao agente discrição limitada, como restrições do comerciante ou limites de gastos. Um mandato fechado vincula a aprovação a um carrinho e valor específicos. Os recibos completam a cadeia de evidências.

O AP2 distingue fluxos com presença humana e sem presença humana. Quando a pessoa está presente, ela pode aprovar diretamente um checkout fechado e um mandato de pagamento. Quando ausente, o agente opera dentro de restrições previamente aprovadas e assina os mandatos fechados finais. Um comerciante ou provedor de credenciais ainda pode trazer a pessoa de volta ao ciclo quando uma restrição não pode ser resolvida.

Este design responde “Esta pessoa autorizou esta ação sob estas condições?” mais diretamente do que “Como esta pessoa foi originalmente verificada?”. A estrutura de autorização do AP2 assume que as credenciais de inscrição e de usuário relevantes existem. Um desenvolvedor, portanto, ainda precisa de um processo de prova de identidade e ciclo de vida de credenciais antes que esses mandatos possam carregar uma garantia significativa.

Mastercard Agent Pay: a rede pode reconhecer e governar um pagamento agente?

O Mastercard Agent Pay se baseia na tokenização de pagamentos. A estrutura de aceitação da Mastercard registra e verifica agentes, atribui identidade de agente única e usa Tokens Agentes para que as transações sejam rastreáveis e as credenciais de pagamento permaneçam protegidas. O reconhecimento voltado para o comerciante pode funcionar com a infraestrutura de checkout existente, enquanto integrações mais profundas suportam uma troca de dados mais rica.

O modelo também enfatiza o consentimento do consumidor, a autenticação e a capacidade de emissores, adquirentes e comerciantes reconhecerem que um agente participou. Isso torna a atividade do agente visível dentro de um modelo de risco de rede de cartão familiar, em vez de tornar a automação indistinguível de uma solicitação comum de cartão não presente.

O Agent Pay é mais forte em segurança de credenciais de pagamento, visibilidade de agente e controles de rede. Ele não remove a obrigação de um comerciante de decidir quando a verificação de identidade, Know Your Business (KYB), triagem Anti-Money Laundering (AML), verificações de idade ou revisão aprimorada se aplicam. Essas decisões dependem do produto, cliente, transação e jurisdição — não apenas do trilho de pagamento.

Onde os padrões se sobrepõem — e onde a identidade ainda se encaixa

Todas as três abordagens estão tentando tornar o comércio delegado legível. Um comerciante deve ser capaz de dizer que a automação está envolvida, verificar se o agente é confiável, conectar a ação à intenção do usuário, restringir a compra e reter evidências. A ênfase difere:

• TAP: reconhecimento de agente e intenção assinada no limite do comerciante, com sinais opcionais de consumidor e pagamento vinculados.
• AP2: artefatos criptográficos de autorização que vinculam a intenção do usuário aos resultados de checkout e pagamento.
• Agent Pay: agentes registrados, credenciais de pagamento tokenizadas, consentimento, autenticação e visibilidade em toda a rede de cartões.

A prova de identidade fica antes e ao lado desses controles. Uma autorização assinada é valiosa apenas se a credencial pertencer à pessoa certa. Um agente aprovado ainda pode ser instruído por uma conta sintética, roubada, sancionada, menor de idade ou de outra forma inelegível. Um token pode proteger as credenciais de pagamento sem estabelecer que um vendedor de mercado ou beneficiário de negócios passou pela devida diligência exigida.

A identidade do agente responde “qual software agiu?” A autorização responde “o que foi permitido fazer?” A verificação de identidade responde “quem está por trás disso?” Os controles de fraude e conformidade respondem “esta ação deve prosseguir?”

O que os desenvolvedores precisam construir, independentemente da abordagem vencedora

• Inscrição e prova. Verifique a pessoa ou empresa antes de conceder uma credencial reutilizável ou autoridade de gasto delegada. Aplique verificações KYC, KYB, prova de vida, documento, banco de dados ou biométricas de acordo com o risco.
• Vinculação de credenciais. Vincule o sujeito verificado a uma conta, dispositivo, passkey, carteira ou outra credencial que possa participar do fluxo agente.
• Autorização com escopo. Capture limites como comerciante, categoria, valor, frequência, expiração e se um humano deve retornar para aprovação.
• Decisões de risco em tempo de execução. Faça a triagem da pessoa, empresa, carteira e transação no momento da ação. Os controles Know Your Transaction (KYT) e as verificações AML permanecem relevantes mesmo quando a intenção é assinada.
• Revogação e recuperação. Interrompa a autoridade delegada quando uma credencial for comprometida, o usuário retirar o consentimento ou o risco mudar.
• Auditabilidade. Preserve o resultado da verificação, o artefato de autorização, a identidade do agente, a decisão da transação, os carimbos de data/hora e as ações de revisão posteriores como evidência separada.

Este design em camadas é deliberadamente neutro em relação aos padrões. Uma equipe pode adotar o TAP na borda do comerciante, os mandatos AP2 em um fluxo de trabalho de agente, o Agent Pay para liquidação de cartões ou uma combinação. A decisão de identidade e fraude permanece portátil porque não está incorporada em uma única rede de pagamento.

Como a Didit cobre a metade da identidade hoje

A Didit fornece infraestrutura para identidade e fraude usada por mais de 2.000 empresas em produção. As mesmas capacidades estão disponíveis através de um servidor MCP hospedado para operações guiadas por agentes e uma API REST para fluxos controlados por aplicativos. Para uma visão geral da arquitetura mais ampla, consulte como um servidor MCP lida com a verificação de identidade e como o MCP conecta verificações de identidade e fraude para agentes de IA.

O endpoint MCP hospedado é https://mcp.didit.me/mcp. Ele usa Streamable Hypertext Transfer Protocol (HTTP), com Open Authorization (OAuth) 2.1, Proof Key for Code Exchange (PKCE) e Registro Dinâmico de Clientes. Um usuário faz login através do Didit Business Console e concede acesso com escopo; o endpoint MCP hospedado não usa autenticação por chave de API.

Após a autorização, um agente pode chamar 115 ferramentas em 11 categorias. Uma sequência de verificação prática pode usar:

didit_context_get
didit_session_create
didit_verify_id
didit_verify_passive_liveness
didit_verify_face_match
didit_session_get_decision

Essas ferramentas podem criar uma sessão de verificação, executar as verificações selecionadas e recuperar uma decisão estruturada. Outras ferramentas reais incluem didit_verify_aml, didit_verify_kyb_search, didit_verify_kyb_select e didit_transaction_screen_wallet. Gravações de alta consequência permanecem sujeitas às permissões e ao comportamento de confirmação do usuário conectado.

A API REST cobre o caminho do aplicativo: crie sessões a partir do seu backend, envie usuários através de verificação hospedada ou incorporada, consuma webhooks e armazene decisões em seu próprio sistema. As solicitações REST de servidor para servidor usam um cabeçalho x-api-key; isso é separado da conexão MCP hospedada autenticada por OAuth. Leia a visão geral do MCP, o guia de autenticação e a referência de ferramentas para detalhes de implementação.

O preço é independente do padrão de pagamento agente. O servidor MCP é gratuito. Um pacote completo de KYC — Verificação de ID, Prova de Vida Passiva, Comparação Facial e Análise de IP — custa US$ 0,33, e cada conta inclui 500 verificações gratuitas por mês.

Um caminho de implementação neutro em relação aos padrões

Comece definindo a garantia necessária para cada ação, não escolhendo um logotipo de rede. A navegação de baixo risco pode precisar apenas de reconhecimento de agente. A criação de contas pode exigir identidade verificada. Uma compra regulamentada pode exigir KYC ou KYB mais triagem AML. Uma transferência de cripto pode adicionar triagem de carteira. Valores mais altos ou riscos alterados podem trazer o humano de volta ao ciclo.

Em seguida, conecte o artefato de pagamento à decisão de identidade com identificadores internos estáveis. Mantenha a assinatura do agente, a autorização do usuário, a evidência de verificação e o resultado do pagamento distintos para que cada um possa ser revogado, revisado e atualizado independentemente à medida que os padrões evoluem.

Explore a página do desenvolvedor Didit MCP ou inspecione o repositório GitHub público e com licença permissiva. Usuários do Claude podem adicionar o conector Didit e concluir o login OAuth.

A arquitetura durável é em camadas: os padrões de pagamento provam a participação e a autorização do agente; a infraestrutura de identidade e fraude prova quem está envolvido e se a ação é aceitável. Essa divisão permite que os desenvolvedores suportem os padrões atuais sem codificar a confiança em um único.