Know Your Agent (KYA): verificar a identidade dos agentes IA

O KYC verifica humanos. Mas quem abre contas ou move dinheiro em 2026 não é humano — é um agente de IA a agir por ele. Essa lacuna é o KYA.

Emily Carter
Por Emily CarterConsultora de Estratégia de IA na Joinble
·9 min de leitura
Partilhar
Know Your Agent (KYA): verificar a identidade dos agentes IA
imageUse esta imagemdownloadBaixar

A próxima conta aberta na sua plataforma não será aberta por um humano.

Soa a slogan. Não é. Em 2026, a entidade que preenche um formulário, chama a sua API ou tenta um pagamento é cada vez mais um agente de IA autónomo a agir sob as instruções de uma pessoa. A Visa lançou o Agentic Ready como infraestrutura de pagamentos para o comércio impulsionado por IA. A Mastercard seguiu com o Agent Pay. A OpenAI, a Anthropic e a Google enviam runtimes de agentes com uso de ferramentas, controlo de navegador e autoridade de pagamento integrados. O Model Context Protocol tornou a invocação de ferramentas por agentes num padrão.

O seu stack KYC foi construído para responder a uma pergunta: o humano do outro lado é quem diz ser? Num mundo em que o ator é software, essa pergunta nem sequer faz sentido. Precisa de outra: que agente é este, quem o autorizou e o que tem permissão para fazer? Isso é o KYA — Know Your Agent — e tratá-lo como uma nota de rodapé do KYC é a brecha por onde passarão tanto os fraudadores como os auditores.

O que é realmente o KYA

O KYA é a camada de verificação para atores não humanos. Valida três coisas, nenhuma opcional:

Identidade. O agente tem uma identidade criptográfica que se resolve ao seu proprietário, ao seu operador e ao seu contexto de execução — não um nome de utilizador, não uma chave de API no bolso de alguém. É exatamente para isso que os W3C Decentralized Identifiers (DIDs) e as Verifiable Credentials foram normalizados, aplicados a atores de software em vez de humanos.

Autoridade. O agente consegue provar que age dentro de um mandato que o titular lhe concedeu: este utilizador autorizou este agente a gastar até esta quantia nesta categoria de comércio durante esta janela. Autorização do tipo capability, não "confie no token portador". A presença de uma chave não é o mesmo que a presença de consentimento.

Proveniência. O agente corre sobre um modelo e um conjunto de ferramentas que pode atestar — pesos conhecidos, salvaguardas conhecidas, cadeia de fornecimento conhecida. O ecossistema crescente de construtores de agentes, e a ascensão dos agentes de IA autónomos em compliance, só funciona se o verificador a jusante conseguir distinguir um modelo sancionado de um com jailbreak.

Uma verificação KYC diz-lhe "um humano verificou-se uma vez". Uma verificação KYA diz-lhe "este agente, com este mandato, neste modelo, está a agir agora mesmo". Não são intercambiáveis, e uma não subsume a outra.

Por que é urgente em 2026, não em 2030

Três forças comprimiram o calendário.

Os pagamentos agênticos saíram do laboratório. Visa Agentic Ready, Mastercard Agent Pay e os toolkits de agentes da Stripe são já trilhos de produção a cursar autorizações reais sem presença do cartão originadas por agentes autónomos. A infraestrutura existe; a camada de verificação dos agentes está, em grande medida, improvisada. A lacuna que mapeamos em Know Your Human: a lacuna KYC nos pagamentos agênticos é a mesma lacuna vista do lado da instituição financeira.

O uso de ferramentas é a nova superfície de ataque. Um agente com um navegador, uma ferramenta de pagamento e memória tem a capacidade de ação de um funcionário com cartão da empresa — mas a vulnerabilidade a injeção de prompt de um chatbot. O Top 10 da OWASP para LLMs (LLM01 injeção de prompt, LLM06 manuseio inseguro de saídas, LLM07 fuga do prompt do sistema) descreve ataques que, aplicados a um agente com ferramentas, se tornam transações não autorizadas em vez de texto fugido. Verificar a identidade e o mandato do agente é a única coisa que impede que um agente vítima de injeção de prompt gaste o dinheiro do titular.

Os reguladores começam a perguntar. A Lei da IA da UE inclui obrigações de transparência no Artigo 50 para sistemas de IA que interagem com pessoas, e o quadro mais amplo sob as obrigações de alto risco de agosto de 2026 cria responsabilidade para os implementadores quando um agente age em nome do utilizador. A lógica de CDD contínua do AMLR não se detém no humano; se um agente move dinheiro, a ação do agente é o evento CDD relevante.

Se a sua plataforma tem pelo menos um cliente a usar um assistente baseado em agentes para interagir com ela — e a meio de 2026 tem, saiba-o ou não — tem tráfego não humano por verificar no seu funil de autenticação.

Os três pilares, ancorados em padrões reais

Identidade criptográfica do agente. Cada agente leva um DID e uma Verifiable Credential emitida pelo seu operador, que por sua vez liga o agente a um titular. O handshake é uma apresentação verificável, não um token portador. É a mesma maquinaria do desenvolvimento da carteira EUDI sob o eIDAS 2.0, aplicada um nível acima: a carteira verifica o humano, a credencial verifica o agente a quem o humano delegou.

Verificação de mandato e intenção. A Verifiable Credential que o agente apresenta inclui o âmbito: quantia, categoria de comércio, jurisdição, janela temporal, tipo de ação. A sua plataforma não tem de confiar na afirmação do agente sobre o que está a fazer; valida que a ação solicitada está dentro do mandato assinado criptograficamente. Se o agente tenta algo fora do mandato — porque sofreu injeção de prompt, foi sequestrado ou simplesmente se confundiu — a ação falha na camada de verificação, não na fila de chargebacks.

Proveniência e reputação do modelo. Uma atestação assinada do runtime do agente — modelo base, fine-tunes, conjunto de ferramentas, configuração de segurança — ligada à credencial. É a ideia do ML-BOM (um SBOM para o stack de IA) feita operacional. O padrão que derrota a dinâmica IA contra IA da Fraude 4.0 na camada do agente é exatamente este: um agente cujo modelo está sancionado e cujo runtime está atestado pertence a uma classe de risco diferente da de um agente cujo runtime é desconhecido.

Os três juntos produzem algo que uma chave de API estática não pode: um ator verificado em tempo de execução, ligado a um mandato, com proveniência atestada. É o piso para permitir que um não humano execute ações com consequências na sua plataforma.

O que se parte se o saltar

Saltar o KYA não cria apenas exposição à fraude. Faz colapsar vários controlos ao mesmo tempo.

Um utilizador legítimo delega num agente, o agente sofre injeção de prompt por uma página web maliciosa que percorre e executa um pagamento que o utilizador não autorizou. Sem KYA, o seu sistema antifraude vê uma transação a partir do dispositivo de um utilizador verificado e aprova. Com KYA, o pagamento falha porque o mandato não incluía "enviar fundos para uma morada controlada pelo atacante".

Um agressor constrói um agente que imita um legítimo — mesmo nome, mesma UX, mesmos padrões de API. Sem KYA, distingui-los exige heurísticas. Com KYA, as credenciais simplesmente não validam.

Um auditor pergunta quem realizou uma ação e sob que autoridade. Sem KYA, pode mostrar uma sessão autenticada e um ID de utilizador. Com KYA, pode mostrar a cadeia criptográfica humano → mandato → agente → ação. A segunda sobrevive a um regulador.

A resposta de 20 pontos do setor à fraude de identidade por IA reconhece-o explicitamente. Várias das suas medidas só funcionam se houver uma camada de identidade de agente por baixo; não se pode defender de fraude impulsionada por agentes em escala sem primeiro conseguir identificar os agentes.

O KYA é a metade superior da infraestrutura de identidade

O KYC verifica o humano. Tornar essa verificação contínua e preditiva — em vez de única no onboarding — é o que faz da identidade um sinal vivo. O KYA verifica o agente a quem o humano delegou. KYA contínuo — a verificar o agente em cada ação com consequências, não apenas uma vez — fecha o ciclo.

Esta é a forma da infraestrutura de identidade para o resto da década: um humano verificado de forma contínua, agentes verificados por ação, mandatos assinados e revogáveis, e proveniência atestada até aos pesos do modelo. Os fornecedores construídos em torno do KYC selfie-documento da era 2010 terão de se readaptar. As plataformas que entregam KYA de origem receberão o tráfego agêntico por defeito, porque serão aquelas pelas quais as Visa e Mastercard deste mundo poderão encaminhar comércio agêntico com consequências sem herdar a responsabilidade.

É essa a aposta da Joinble. A nossa arquitetura de KYC agêntico já funciona sob a hipótese de que o ator pode ser um agente; o KYA é a camada que torna essa hipótese operacional. Não estamos a readaptar fornecedores baseados em selfie para a era dos agentes — construímo-la assim.

Perguntas frequentes

O KYA substitui o KYC? Não. O KYA assenta sobre o KYC. O humano continua a ser verificado na base do stack; o KYA verifica o agente a quem o humano delegou. Um não elimina a necessidade do outro.

Em que difere o KYA da autenticação por API? Uma chave de API autentica um cliente. O KYA verifica a identidade criptográfica do agente, o titular por quem age, o mandato sob o qual opera e a proveniência do seu modelo e ferramentas. Uma chave de API fugida é plenamente utilizável por um atacante; uma credencial KYA roubada sem o mandato com que foi assinada não concede nada acionável.

Porquê W3C DIDs e Verifiable Credentials? Porque já existem como padrões, estão a ser implementadas sob o eIDAS 2.0 para carteiras humanas e são as únicas primitivas criptográficas de identidade maduras e interoperáveis. Construir o KYA sobre o mesmo substrato mantém o humano e o agente no mesmo grafo de identidade em vez de em silos paralelos.

O KYA obriga a mudar todos os fluxos de login da minha plataforma? Não. O KYA é invocado quando um agente se apresenta à sua plataforma — tipicamente via uma troca normalizada de credenciais no API gateway ou na camada de autorização de pagamentos. Os fluxos só-humano existentes continuam sem alterações. O trabalho está no perímetro, não em cada superfície de produto.

E a injeção de prompt num agente verificado? O KYA não impede que o agente se confunda. Impede que um agente confuso cause danos. Se um agente vítima de injeção de prompt tenta agir fora do seu mandato, a verificação falha na plataforma e a ação não se executa. A credencial diz "o agente pode gastar na categoria X até à quantia Y", não "o agente pode fazer qualquer coisa".

Se tráfego não humano está a chegar à sua plataforma — e está — o seu stack KYC já não é a resposta inteira. Fale com a nossa equipa sobre como cabear o KYA nas suas camadas de autenticação e pagamento antes de os reguladores perguntarem por que não o fez.

Emily CarterEmily Carter
Partilhar

Artigos relacionados

ZK-KYC: verificar identidade sem revelar dados
Tecnologia01 Jun, 2026

ZK-KYC: verificar identidade sem revelar dados

O ZK-KYC permite verificar conformidade sem armazenar dados pessoais. Como as provas de conhecimento zero resolvem o paradoxo LGPD-RGPD e compliance em 2026.

KYC Agêntico: Agentes de IA Substituem Revisão Manual
Tecnologia31 Mar, 2026

KYC Agêntico: Agentes de IA Substituem Revisão Manual

O KYC tradicional depende de revisores humanos. O KYC agêntico utiliza agentes de IA autónomos que detetam deepfakes, avaliam risco e tomam decisões de compliance. Descubra como a arquitetura multi-agente reduz 80% das revisões manuais, cumprindo MiCA e AMLD6.

Tokenização de Ativos: KYC como Chave da Economia Token
Tecnologia16 Mar, 2026

Tokenização de Ativos: KYC como Chave da Economia Token

A tokenização de ativos está a transformar as finanças, o imobiliário e o mercado de arte. Mas sem uma verificação de identidade robusta, a economia token não pode escalar. Descubra como o KYC potenciado por IA permite uma tokenização segura e conforme.