Conectando o Agente: Como Vincular um Humano a um Agente de IA

Principais conclusões

• O Know Your Agent (KYA) não é resolvido apenas nomeando um agente. O controle durável é uma cadeia de delegação que vincula uma pessoa autenticada, um cliente registrado, escopos concedidos, um contexto organizacional e cada ação resultante.
• O endpoint do Model Context Protocol (MCP) hospedado da Didit expõe 115 ferramentas em 19 domínios e usa Open Authorization (OAuth) 2.1 com Proof Key for Code Exchange (PKCE) e Registro Dinâmico de Clientes.
• O MCP atua como o usuário logado da Didit. Ele herda a função organizacional desse usuário, de modo que um agente conectado não pode obter permissões que a pessoa já não possuía.
• Uma chave de aplicativo armazenada em um arquivo de configuração prova a posse de uma credencial, não qual humano delegou uma ação específica. Chaves compartilhadas colapsam múltiplos operadores e agentes em uma única identidade de aplicativo.
• A responsabilidade exige tanto a execução quanto a evidência: tokens com escopo e verificações de função antes de uma ação, e então registros de auditoria que mostram quem mudou o quê.

A Didit já lançou o mecanismo. Seu servidor MCP hospedado conecta um cliente de IA a operações de identidade e fraude através de um usuário logado, em vez de tratar o agente como um detentor anônimo de um segredo de aplicativo. O endpoint é gratuito, usa HTTP Streamable sem estado e expõe 115 ferramentas. A implementação também está disponível no repositório público do GitHub com licença MIT.

Esse artefato muda a pergunta ú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 do espaço de trabalho, o que prova qual pessoa o autorizou, o que essa pessoa permitiu e qual organização aceitou a ação?

A vinculaçã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 vinculação humana precisa de uma cadeia com elos distintos:

• Principal: o usuário autenticado ou proprietário do serviço em nome de quem o agente atua.
• Cliente: o aplicativo de IA que solicitou acesso.
• Delegação: os escopos e o consentimento concedidos a esse cliente.
• Contexto de autorização: a função organizacional e o limite do aplicativo aplicados à solicitação.
• Evidência: um registro revisável da ação e seu resultado.

Cada elo responde a uma pergunta diferente. A autenticação diz quem fez login. O OAuth diz qual cliente recebeu acesso delegado. Os escopos dizem quais classes de operação foram aprovadas. As funções dizem o que o usuário pode fazer dentro da organização. Os registros de auditoria dizem o que realmente aconteceu. Colapsar esses controles em um único distintivo de “agente verificado” esconde a parte mais importante: a autoridade é contextual e revogável.

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

Por que uma chave em um arquivo de configuração falha no teste de responsabilidade

Uma chave de API de aplicativo pode ser apropriada para uma integração controlada de servidor para servidor. Não é, por si só, um mecanismo de vinculação humano-agente. Uma chave copiada normalmente responde a uma pergunta: “Este chamador possui uma credencial aceita para este aplicativo?” 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 equipes compartilham uma chave em ambientes locais. Um processo de agente a herda de um arquivo de configuração. Um segundo agente recebe uma cópia. Os logs então atribuem cada chamada à mesma credencial de aplicativo. Revogar essa credencial interrompe todas as cargas de trabalho que a usam, enquanto deixa o evento de delegação individual pouco claro.

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

OAuth 2.1, PKCE e Registro Dinâmico de Clientes

OAuth é a primitiva de delegação neste projeto. O fluxo não entrega a senha do usuário 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 que o usuário se autentica com a Didit e aprova o acesso.

1. Registrar o cliente

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

2. Vincular 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 interceptado porque outro processo não pode resgatá-lo sem o verificador.

3. Autenticar e consentir

O usuário faz login no Didit Business Console, que atua como servidor de autorização, e aprova os escopos solicitados. A Didit anuncia didit:verification para operações de verificação e didit:management para gerenciamento de espaço de trabalho. Um cliente deve solicitar apenas o escopo necessário para a tarefa.

4. Validar cada chamada

O servidor de recursos MCP hospedado valida o token de portador antes de despachar uma chamada de ferramenta. O token de usuário validado e o contexto da organização viajam com a solicitação para a Didit. O serviço downstream então avalia a função e as permissões existentes para esse usuário. O resultado são semânticas de “atuar como usuário”, não uma nova identidade de superusuário criada para o agente.

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

Atuar como usuário torna a autoridade legível

Suponha que um operador de conformidade conecte um cliente de IA à Didit. O cliente primeiro chama didit_context_get, que retorna as organizações e aplicativos que o usuário logado pode acessar. Se o usuário tiver uma organização e aplicativo inequívocos, o contexto pode ser resolvido automaticamente. Se vários estiverem disponíveis, a operação pode ser restringida a uma organização e aplicativo explícitos.

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

Esta é a diferença central de uma credencial de aplicativo compartilhada. No modelo OAuth, a solicitação chega como um usuário conhecido operando através de um cliente registrado com escopos declarados. No modelo de chave compartilhada, o sistema downstream vê a credencial do aplicativo, enquanto o humano e o agente por trás de uma chamada particular permanecem indistinguíveis, a menos que um plano de controle separado forneça esse contexto.

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

A autorização impede uma ação fora do escopo. A auditabilidade explica uma ação depois que ela ocorre. A Didit expõe didit_audit_log_list para que um usuário autorizado possa inspecionar entradas de auditoria de aplicativos descrevendo quem mudou o quê. Como cada solicitação MCP hospedada carrega o token de portador do usuário logado e o contexto da organização resolvido, a ação é atribuível a esse chamador, e não a um processo de agente anônimo.

Um registro forense completo também deve preservar as evidências do lado do agente. Para fluxos de trabalho de alto impacto, registre o identificador de execução do agente, o registro do cliente, o escopo solicitado, a organização e o aplicativo de destino, 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 registre tokens de acesso ou cargas úteis de identidade sensíveis. A trilha de auditoria da plataforma e o log 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 log de auditoria não é um substituto para o princípio do menor privilégio. Os controles se reforçam mutuamente:

• Use acesso de curta duração e atualização controlada em vez de credenciais compartilhadas permanentes.
• Conceda o escopo OAuth mais restrito e a função organizacional de menor privilégio.
• Exija confirmação humana para operações destrutivas ou de impacto incomumente alto.
• Mantenha o contexto da organização e do aplicativo explícito quando mais de um destino estiver disponível.
• Revogue a sessão do usuário ou a concessão do cliente quando a delegação deve terminar.
• Monitore os registros de auditoria para atores, ferramentas, alvos ou tempos inesperados.

O que a vinculação prova – e o que não prova

Este padrão prova que uma conta Didit autenticada delegou acesso com escopo a um cliente OAuth e que cada solicitação é avaliada com as permissões de organização desse usuário. Ele cria responsabilidade prática a uma conta e uma cadeia revisável para ações da plataforma.

Não prova automaticamente que o titular da conta possui uma identidade civil verificada, que o binário do cliente aprovado não foi modificado ou que o humano está observando ativamente cada etapa. Isso exige garantia adicional. Se a garantia de identidade legal for necessária, verifique o principal durante a integração com controles Know Your Customer (KYC) e vincule esse resultado à conta. Se a proveniência do software for importante, adicione atestado de cliente e lançamentos assinados. Se a presença for importante, exija aprovação de step-up no momento da ação sensível.

Essa 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ências de auditoria são controles relacionados, não rótulos intercambiáveis.

Uma implementação prática que você pode inspecionar

A implementação da Didit fornece uma referência concreta para equipes que projetam o mesmo limite de responsabilidade. O servidor hospedado autentica como o usuário logado da Didit, herda a função organizacional desse usuário e aplica essa identidade a cada chamada de ferramenta. Suas 115 ferramentas hospedadas abrangem 19 domínios, desde contexto e sessões de verificação até fluxos de trabalho, organizações, análises e logs de auditoria. O catálogo de ferramentas atual lista a superfície exata.

Para contexto do produto, o pacote KYC completo custa US$ 0,33 e combina Verificação de ID, Liveness Passivo, 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 equipes possam avaliar o modelo de delegação e permissão sem adicionar uma taxa de conector separada.

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

Vincule 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 responsabilidade humana à medida que o software cruza interfaces e age na velocidade da máquina. OAuth 2.1 fornece acesso delegado. O PKCE protege a troca de autorização. O Registro Dinâmico de Clientes identifica o cliente que se conecta. Os escopos e as funções da organização restringem a autoridade. Os registros de auditoria tornam o resultado revisável.

Você pode inspecionar a arquitetura no repositório Didit MCP, revisar a documentação de autenticação ou conectar a Didit ao Claude. O teste útil é simples: para qualquer ação de agente proposta, você consegue identificar o usuário responsável, o cliente, o escopo concedido, o limite da organização e a evidência de auditoria resultante? Se algum elo estiver faltando, o agente não está totalmente vinculado.