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.
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.
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.
-
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.
-
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.
-
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.
-
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.
-
O usuário informa o token no chat.
-
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.
-
Com a confirmação, o dado é liberado.
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:
