Conheça o seu Agente: Como Associar um Humano a um Agente de IA

Principais conclusões

• Conhecer o Seu Agente (KYA) não é resolvido apenas nomeando um agente. O controlo duradouro é uma cadeia de delegação que liga uma pessoa autenticada, um cliente registado, âmbitos concedidos, um contexto de organização e cada ação resultante.
• O endpoint MCP (Model Context Protocol) alojado da Didit expõe 115 ferramentas em 19 domínios e utiliza Open Authorization (OAuth) 2.1 com Proof Key for Code Exchange (PKCE) e Registo Dinâmico de Clientes.
• O MCP atua como o utilizador Didit com sessão iniciada. Herda a função de organização desse utilizador, para que um agente conectado não possa obter permissões que a pessoa já não tivesse.
• Uma chave de aplicação armazenada num ficheiro de configuração prova a posse de uma credencial, não qual humano delegou uma ação específica. Chaves partilhadas agrupam múltiplos operadores e agentes numa única identidade de aplicação.
• A responsabilização exige tanto a aplicação quanto a prova: tokens com âmbito e verificações de função antes de uma ação, e depois registos de auditoria que mostram quem alterou o quê.

A Didit já disponibilizou o mecanismo. O seu servidor MCP alojado conecta um cliente de IA a operações de identidade e fraude através de um utilizador com sessão iniciada, em vez de tratar o agente como um detentor anónimo de um segredo de aplicação. O endpoint é gratuito, utiliza HTTP Streamable sem estado e expõe 115 ferramentas. A implementação também está disponível no repositório GitHub público com licença MIT.

Esse artefacto muda a questão útil. Em vez de pedir outra definição de KYA, pergunte: quando um agente cria uma sessão de verificação, lê uma decisão ou altera dados de espaço de trabalho, o que prova qual pessoa a autorizou, o que essa pessoa permitiu e qual organização aceitou a ação?

A ligação humana é uma cadeia de delegação

Um nome de agente, identificador de modelo, chave pública ou atestado de software pode ajudar a identificar o ator da máquina. Nenhum deles, por si só, estabelece quem é responsável pelo que o agente faz. A ligação humana precisa de uma cadeia com elos distintos:

• Principal: o utilizador autenticado ou proprietário do serviço em nome de quem o agente atua.
• Cliente: a aplicação de IA que solicitou acesso.
• Delegação: os âmbitos e o consentimento concedidos a esse cliente.
• Contexto de autorização: a função da organização e o limite da aplicação aplicados ao pedido.
• Evidência: um registo auditável da ação e do seu resultado.

Cada elo responde a uma pergunta diferente. A autenticação diz quem iniciou a sessão. O OAuth diz qual cliente recebeu acesso delegado. Os âmbitos dizem quais classes de operação foram aprovadas. As funções dizem o que o utilizador pode fazer dentro da organização. Os registos de auditoria dizem o que realmente aconteceu. Agrupar estes controlos num único selo de “agente verificado” esconde a parte mais importante: a autoridade é contextual e revogável.

Um agente fiável não é meramente identificável. Deve ser capaz de mostrar um caminho ininterrupto de um principal responsável para uma ação específica e permitida.

Porque uma chave num ficheiro de configuração falha no teste de responsabilização

Uma chave de API de aplicação pode ser apropriada para uma integração controlada de servidor para servidor. Não é, por si só, um mecanismo de ligação humano-agente. Uma chave copiada normalmente responde a uma pergunta: “Este chamador possui uma credencial aceite para esta aplicação?” Não responde quem lançou o agente, quem aprovou a tarefa atual, ou se duas chamadas usando a mesma chave vieram de pessoas diferentes.

Os modos de falha são previsíveis. As equipas partilham uma chave em ambientes locais. Um processo de agente herda-a de um ficheiro de configuração. Um segundo agente recebe uma cópia. Os registos então atribuem cada chamada à mesma credencial de aplicação. Revogar essa credencial interrompe todas as cargas de trabalho que a utilizam, enquanto deixa o evento de delegação individual pouco claro.

A Didit, deliberadamente, não oferece um caminho de chave de aplicação para o seu endpoint MCP alojado. As integrações de backend ainda podem usar as APIs REST da Didit com credenciais de aplicação, mas o acesso remoto ao MCP requer um fluxo OAuth de utilizador. Essa separação é importante: a credencial REST representa uma integração de aplicação; o token MCP representa acesso delegado de um utilizador com sessão iniciada.

OAuth 2.1, PKCE e Registo Dinâmico de Clientes

OAuth é a primitiva de delegação neste design. O fluxo não entrega a palavra-passe do utilizador ao agente, e não coloca um segredo de plataforma reutilizável na configuração do MCP. Em vez disso, o cliente de IA obtém um token de acesso limitado depois de o utilizador se autenticar com a Didit e aprovar o acesso.

1. Registar o cliente

O Registo Dinâmico de Clientes permite que um cliente MCP compatível se registe no servidor de autorização da Didit sem um identificador de cliente pré-provisionado manualmente. Isso dá ao servidor de autorização um registo de cliente distinto ao qual pode emitir acesso. O registo identifica o cliente OAuth; não certifica, por si só, que o software do cliente é fiável.

2. Ligar a resposta de autorização ao cliente

O PKCE cria um verificador e um desafio únicos para a tentativa de autorização. O cliente que inicia o fluxo deve apresentar o verificador ao trocar o código de autorização. Isso limita o valor de um código intercetado porque outro processo não pode resgatá-lo sem o verificador.

3. Autenticar e consentir

O utilizador inicia sessão na Consola Empresarial da Didit, que atua como servidor de autorização, e aprova os âmbitos solicitados. A Didit anuncia didit:verification para operações de verificação e didit:management para gestão de espaço de trabalho. Um cliente deve solicitar apenas o âmbito necessário para a tarefa.

4. Validar cada chamada

O servidor de recursos MCP alojado valida o token de portador antes de despachar uma chamada de ferramenta. O token de utilizador validado e o contexto da organização viajam com o pedido para a Didit. O serviço a jusante avalia então a função e as permissões existentes para esse utilizador. O resultado são semânticas de “agir como utilizador”, não uma nova identidade de superutilizador criada para o agente.

O guia de autenticação MCP documenta o fluxo, enquanto a visão geral do MCP explica o endpoint alojado e o modelo de cliente.

Agir como o utilizador torna a autoridade legível

Suponha que um operador de conformidade conecta um cliente de IA à Didit. O cliente primeiro chama didit_context_get, que retorna as organizações e aplicações às quais o utilizador com sessão iniciada pode aceder. Se o utilizador tiver uma organização e aplicação inequívocas, o contexto pode ser resolvido automaticamente. Se houver várias disponíveis, a operação pode ser restringida a uma organização e aplicação explícitas.

O agente pode então chamar didit_session_create para criar uma sessão de verificação e didit_session_get_decision para recuperar o seu resultado. Esses são nomes de ferramentas reais e de domínio no catálogo MCP atual. Um utilizador que não tenha a permissão necessária não a obtém ao conectar um agente; o mesmo limite de autorização da organização ainda se aplica.

Esta é a diferença central de uma credencial de aplicação partilhada. No modelo OAuth, o pedido chega como um utilizador conhecido a operar através de um cliente registado com âmbitos declarados. No modelo de chave partilhada, o sistema a jusante vê a credencial da aplicação, enquanto o humano e o agente por trás de uma chamada específica permanecem indistinguíveis, a menos que um plano de controlo separado forneça esse contexto.

Auditabilidade: de “quem pode agir?” para “quem fez o quê?”

A autorização impede uma ação fora do âmbito. A auditabilidade explica uma ação depois de ocorrer. A Didit expõe didit_audit_log_list para que um utilizador autorizado possa inspecionar as entradas de auditoria da aplicação descrevendo quem alterou o quê. Como cada pedido MCP alojado transporta o token de portador do utilizador com sessão iniciada e o contexto da organização resolvido, a ação é atribuível a esse chamador em vez de a um processo de agente anónimo.

Um registo forense completo também deve preservar as evidências do lado do agente. Para fluxos de trabalho de alto impacto, registe o identificador de execução do agente, o registo do cliente, o âmbito solicitado, a organização e aplicação alvo, o nome da ferramenta, o carimbo de data/hora, o estado de aprovação e uma representação segura das entradas e saídas. Não registe tokens de acesso ou cargas úteis de identidade sensíveis. O registo de auditoria da plataforma e o registo de execução do agente devem ser correlacionáveis sem duplicar segredos ou dados pessoais regulados.

A atribuição não é o mesmo que não-repúdio, e um registo de auditoria não é um substituto para o privilégio mínimo. Os controlos reforçam-se mutuamente:

• Use acesso de curta duração e atualização controlada em vez de credenciais partilhadas permanentes.
• Conceda o âmbito OAuth mais restrito e a função de organização com menos privilégios.
• Exija confirmação humana para operações destrutivas ou de impacto invulgarmente alto.
• Mantenha o contexto da organização e da aplicação explícito quando mais de um alvo estiver disponível.
• Revogue a sessão do utilizador ou a concessão do cliente quando a delegação deve terminar.
• Monitorize os registos de auditoria para atores, ferramentas, alvos ou tempos inesperados.

O que a ligação prova — e o que não prova

Este padrão prova que uma conta Didit autenticada delegou acesso com âmbito a um cliente OAuth e que cada pedido é avaliado com as permissões da organização desse utilizador. Cria uma responsabilização prática para uma conta e uma cadeia auditável para as ações da plataforma.

Não prova automaticamente que o titular da conta tem uma identidade civil verificada, que o binário do cliente aprovado não foi modificado, ou que o humano está a observar ativamente cada passo. Esses requisitos exigem garantia adicional. Se a garantia de identidade legal for necessária, verifique o principal durante o onboarding com controlos de Know Your Customer (KYC) e associe esse resultado à conta. Se a proveniência do software for importante, adicione atestado do cliente e lançamentos assinados. Se a presença for importante, exija aprovação por etapas no momento da ação sensível.

Esta visão em camadas mantém o KYA honesto. Identidade do agente, identidade humana, autorização delegada, política de tempo de execução e evidência de auditoria são controlos relacionados, não rótulos intermutáveis.

Uma implementação prática que pode inspecionar

A implementação da Didit fornece uma referência concreta para equipas que estão a projetar o mesmo limite de responsabilização. O servidor alojado autentica-se como o utilizador Didit com sessão iniciada, herda a função de organização desse utilizador e aplica essa identidade a cada chamada de ferramenta. As suas 115 ferramentas alojadas abrangem 19 domínios, desde sessões de contexto e verificação até fluxos de trabalho, organizações, análises e registos de auditoria. O catálogo de ferramentas atual lista a superfície exata.

Para contexto do produto, o pacote KYC completo custa 0,33 $ e combina Verificação de ID, Liveness Passiva, Face Match e Análise de IP. A Didit inclui 500 verificações gratuitas por mês e é usada por mais de 2.000 empresas em produção. O próprio servidor MCP é gratuito, para que as equipas possam avaliar o modelo de delegação e permissões sem adicionar uma taxa de conector separada.

Para ver como este mecanismo se encaixa em fluxos de trabalho de agente mais amplos, leia como o MCP de identidade e fraude funciona para agentes de IA e a referência de ferramentas Didit MCP.

Ligue o agente antes de confiar na ação

O problema difícil na identidade do agente não é inventar um nome durável para o software. É preservar a responsabilização humana à medida que o software atravessa interfaces e age à velocidade da máquina. OAuth 2.1 fornece acesso delegado. PKCE protege a troca de autorização. O Registo Dinâmico de Clientes identifica o cliente que se conecta. Âmbitos e funções da organização restringem a autoridade. Os registos de auditoria tornam o resultado auditável.

Pode inspecionar a arquitetura no repositório Didit MCP, rever a documentação de autenticação, ou conectar a Didit ao Claude. O teste útil é simples: para qualquer ação de agente proposta, consegue identificar o utilizador responsável, o cliente, o âmbito concedido, o limite da organização e a evidência de auditoria resultante? Se algum elo estiver em falta, o agente não está totalmente ligado.