Como a ClaudIA valida que o usuário é quem diz ser
Quando usar
- O time de segurança da sua empresa pergunta como a identidade do usuário é verificada antes de a ClaudIA entregar um
dado sensível.
- Você vai habilitar operações sensíveis no atendimento automatizado — consultar extrato ou saldo, ver dados de
cadastro, alterar informação da conta.
- Você precisa decidir entre verificar a identidade pelo caminho agêntico ou por Fluxo Controlado.
- Você quer levantar o que precisa ser construído do lado da sua API antes de liberar esse tipo de operação.
Pré-requisitos
- Um canal de atendimento já configurado — web widget, WhatsApp, email, etc.
- Para o web widget: validação de identidade por assinatura (HMAC) habilitada no canal.
- Para o step-up de token: duas APIs do seu lado, uma que dispara o token e uma que valida o token informado.
:::warning Liberar operação sensível em canal aberto sem o step-up de token descrito neste artigo expõe o dado do
usuário final a quem estiver de posse do aparelho. Não habilite esse tipo de operação antes de ter as duas APIs
descritas na seção "O que precisa existir do lado da sua API".
:::
Sobre este artigo
A resposta para "como vocês sabem que é ele mesmo?" muda conforme o canal, e é essa a parte que costuma se perder numa
explicação corrida. Em canal logado, a identidade chega assinada pela sua própria aplicação. Em canal aberto, o número
de origem é o primeiro fator, e o segundo fator é um token que a sua empresa gera, entrega e confere.
A ClaudIA conduz a conversa. A decisão de liberar o dado sensível é sempre da sua aplicação.
Como funciona
A garantia de identidade muda conforme o canal
Cada canal entrega o usuário com um grau diferente de certeza sobre quem ele é. O step-up de token é a camada que os
dois canais compartilham: recomendada onde a identidade é apenas presumida, opcional onde ela já vem verificada.
Os dois canais de atendimento convergem para a mesma camada de step-up de token, que precede a liberação da operação
sensível
Web widget, em área logada: identidade verificada na origem
Quando o atendimento acontece no web widget dentro da sua área logada, o usuário já passou por todos os challenges de
login antes de chegar ao chat. A sua aplicação assina a identidade dele, e o widget valida essa assinatura por HMAC.
Isso tem duas propriedades que importam numa análise de risco. A primeira é que a assinatura pode ser exigida como
obrigatória no canal: sem assinatura válida, a conversa não é aberta — não é um campo opcional que alguém esquece de
preencher. A segunda é que o resultado dessa validação fica registrado no vínculo entre o contato e o canal e continua
consultável depois do atendimento, o que torna a verificação auditável.
Na prática, toda conversa que chega por esse canal já nasce com a identidade verificada.
WhatsApp, em canal aberto: identidade presumida pelo canal
No WhatsApp, a ClaudIA sabe de qual número a mensagem veio. A posse desse número — o aparelho ou uma sessão do WhatsApp
Web — é um primeiro fator legítimo, de posse.
O que ela não cobre é o cenário de um aparelho desbloqueado, ou de uma sessão web que ficou acessível a um terceiro. A
posse do número não distingue o titular de quem está com o aparelho na mão.
Por isso, antes de uma operação sensível nesse canal, entra o step-up de token descrito abaixo. E vale a recíproca: se
você quiser um segundo fator mesmo no web widget — porque o computador pode ter ficado aberto — o mesmo step-up se
aplica lá.
O step-up de token, passo a passo
O exemplo abaixo usa a consulta de extrato da conta, mas vale para qualquer operação que você classifique como sensível.
Diagrama de faixas com os sete momentos do fluxo de token entre o usuário, a ClaudIA e a API do cliente
1. O usuário pede a operação sensível. A ClaudIA já identificou o usuário pelo número e já dispõe da ferramenta que
devolveria o dado.
2. A ClaudIA não entrega o dado. Ela pede a verificação. O agente é instruído a explicar que vai enviar um token e a
pedir que o usuário o informe de volta.
3. A ClaudIA chama a sua API de disparo de token. A ClaudIA não gera o token — ela pede que a sua aplicação gere e
envie.
4. A sua aplicação entrega o token pelo canal que ela considerar mais seguro. E-mail, por exemplo. Uso único. A partir
daqui existem dois fatores em canais distintos: o número do WhatsApp e a caixa de e-mail.
5. O usuário informa o token no chat.
6. A ClaudIA chama a sua API de validação. "Este usuário informou este token — confere?" Quem responde é a sua
aplicação. A ClaudIA não confere o token.
7. Com a confirmação, o dado é liberado.
:::info Na ida, o token não passa pela Cloud Humans. Ele sai da sua aplicação direto para o segundo canal do usuário. A
ClaudIA só vê o valor no momento 5, quando o próprio usuário o digita no chat.
:::
Quem faz o quê
Ficam com a sua aplicação:
- gerar o token;
- escolher o canal de entrega;
- entregar o token ao usuário;
- validar o token informado;
- decidir liberar o dado sensível.
Ficam com a Cloud Humans:
- conduzir a conversa e instruir o agente;
- transportar o token que o usuário informou no chat.
Determinismo: o que está garantido e o que não está
No caminho padrão, a decisão de acionar a verificação antes de uma operação sensível é tomada por um modelo de
linguagem, a partir da instrução dada ao agente. Isso não é determinístico, e vale delimitar com precisão o que
exatamente não está garantido.
Não existe o modo de falha "a ClaudIA aceitou um token inválido". Quem confere o token é a sua API — a ClaudIA não tem
como validar e, portanto, não tem como validar errado.
Existe o modo de falha "o agente deixou de acionar a verificação antes de uma operação sensível". É um escopo estreito,
e é endereçável.
As três formas de fechar a diferença
Em ordem crescente de garantia.
Agetnes Especialistas + Tools, o caminho padrão: A verificação é uma instrução dada ao agente. Usamos modelos de ponta e
não temos histórico de incidentes desse tipo, mas a garantia aqui é estatística, não estrutural. Para a maioria das
operações isso é adequado; para um controle de segurança formal, a distinção importa.
Fluxos Controlados, a alternativa determinística: A verificação passa a ser um passo de script, em lógica de árvore, sem
modelo de linguagem na decisão. Determinístico por construção. O custo é experiência: o atendimento fica mais rígido
para o usuário final, e por isso não é o padrão que recomendamos. Pode ser aplicado apenas ao trecho sensível,
preservando a conversa natural no resto do atendimento.
O que precisa existir do lado da sua API
- Disparo de token. Recebe o identificador do usuário — número, e-mail ou id interno — e envia um token de uso único
pelo canal que você considerar mais seguro.
- Validação de token. Recebe o identificador e o token informado pelo usuário, e responde se é válido. A decisão é
sua.
- Recomendado. A API que devolve o dado sensível consulta o estado de verificação antes de responder. É o que converte
a verificação de instrução em controle estrutural.
Observações
- Persistência da verificação. É configurável: pode valer pelo resto do atendimento, ou ser exigida novamente a cada
operação sensível. A escolha é sua, e é definida na instrução do agente.
- O token fica registrado na conversa. O token que o usuário digita trafega como mensagem do atendimento e fica no
histórico, como qualquer outra mensagem. É por isso que ele deve ser de uso único e de vida curta. A ClaudIA não o
trata como credencial, não o reutiliza, e não o aceita como prova de identidade em atendimentos posteriores.
- Sobre SMS como canal do token. O fluxo funciona igual se a sua aplicação escolher enviar o token por SMS. Avalie
antes o risco de SIM swap e de atraso na entrega — vários times de segurança já descartam SMS como segundo fator por
esses dois motivos.
Exemplo de fluxo controlado executando esse processo:
