Desenvolvendo fluxos seguros de autenticação de identidade de chamadores para agentes de voz

Voice agents are rapidly evolving from simple FAQ responders to action-taking systems that modify accounts, process transactions, and access sensitive customer data. This shift introduces a critical challenge: How do you verify caller identity in a conversational AI system where traditional visual authentication methods don't exist?

Quando um agente de voz pode atualizar assinaturas, consultar saldos ou iniciar reembolsos, ele precisa autenticar o usuário com o mesmo rigor de um call center humano, mas usando apenas a interação por voz. Diferente de agentes humanos que seguem políticas da empresa, agentes de IA exigem autenticação determinística, baseada em ferramentas, sem depender do julgamento do LLM.

Neste artigo, mostramos padrões de autenticação comprovados a partir da nossa experiência como engenheiros de implantação em grandes empresas. Vamos apresentar cinco abordagens principais, desde autenticação baseada em sessão para widgets integrados até métodos específicos de telefonia e verificação por OTP, explicando como implementar cada uma usando controle determinístico de fluxo na plataforma ElevenLabs.

O mais importante é mostrar por que a autenticação não pode depender apenas da interpretação da conversa. Ela precisa ser estruturada com subagentes isolados, verificação por ferramentas e roteamento condicional de fluxos, garantindo que só usuários autenticados tenham acesso a operações privilegiadas.

A base arquitetural para autenticação determinística

Para garantir que apenas usuários autenticados acessem informações de conta, recomendamos uma separação rigorosa de ambiente e acesso usando os workflows da ElevenLabs. A autenticação deve sempre ser feita por meio de uma chamada de ferramenta com resultado booleano de sucesso ou falha, configurada como ferramenta de despacho no construtor de workflows da ElevenLabs.

Ao vincular a condição de transferência diretamente ao resultado da chamada de ferramenta, o subagente com acesso aos dados da conta só pode ser acessado após autenticação bem-sucedida e permanece totalmente isolado de usuários não autenticados. Isso garante que a autenticação seja determinística, sem depender da decisão do LLM, e impede qualquer avanço para etapas seguintes sem identidade verificada.

Como alternativa, expressões de transferência podem ser usadas como método confiável de transição. Essas expressões referenciam variáveis dinâmicas que são atualizadas conforme os resultados das chamadas de ferramenta.

Exemplo de implementação

Verifique o usuário no Salesforce (chamada de ferramenta). Se for bem-sucedido, recupere os dados de transações do cliente no Salesforce (outra chamada de ferramenta) e então transfira o usuário para um subagente responsável por usar esses dados para se comunicar com o cliente e realizar outras ações, se necessário.

Métodos de autenticação de identidade do usuário

Esses métodos de autenticação não são suportados nativamente na plataforma ElevenLabs. Eles podem ser implementados por meio de ferramentas no servidor que se integram ao seu CRM ou backend/banco de dados, onde os dados de autenticação ficam armazenados.

Autenticação pela aplicação hospedeira

Para agentes de voz integrados em um site, a aplicação hospedeira pode passar dados de sessão do usuário (como status de login, ID da conta ou tokens de sessão) por variáveis dinâmicas ao iniciar o agente/widget. Essas variáveis são automaticamente inseridas nas chamadas de ferramenta usando as mesmas variáveis dinâmicas, permitindo que o agente recupere dados personalizados dos sistemas integrados sem exigir autenticação separada.

Isso permite um fluxo de suporte mais simples, já que o usuário já foi verificado pela aplicação hospedeira. Você pode configurar isso por meio de configuração personalizada ou usar o widget da ElevenLabs, passando variáveis em tempo de execução na configuração do widget (exemplo: <elevenlabs-convai dynamic-variables='{"user_id": "123", "account_tier": "premium"}'>).

Documentation on Dynamic Variables:

• https://www.11labs.ru/docs/agents-platform/customization/personalization/dynamic-variables#pass-variables-at-runtime 

Autenticação baseada em conhecimento (KBA)

O agente de voz pede que o usuário forneça dados de autenticação como número da conta, CEP, data de nascimento ou respostas de segurança. Uma ferramenta no servidor (webhook ou lado do cliente) verifica esses valores no seu banco de dados (por exemplo, CRM ou base de identidade). A ferramenta retorna um resultado de sucesso/falha, incluindo um status booleano (is_error) e um texto descritivo. Você pode implementar isso com controle determinístico de fluxo: após solicitar as informações, configure o despacho da ferramenta e use transferências condicionais no workflow que direcionam usuários autenticados para nós “privilegiados” do agente.

Essa abordagem suporta perguntas de segurança estáticas e verificação dinâmica no estilo "fora da carteira", dependendo dos seus requisitos de risco de fraude.

Documentação sobre Ferramentas:

• https://www.11labs.ru/docs/agents-platform/customization/tools/server-tools 
• https://www.11labs.ru/docs/agents-platform/customization/agent-workflows#dispatch-tool-node 

Variáveis dinâmicas do sistema (apenas telefonia)

Para conversas por telefone (via Twilio ou SIP trunk), seu agente tem acesso automático a variáveis do sistema específicas de telefonia, incluindo system__caller_id (número de telefone do usuário). Essa variável é preenchida automaticamente no início da conversa e pode ser usada de duas formas: 1) Em prompts/mensagens: Referencie usando chaves duplas, ex: {{system__caller_id}}, e ela será substituída pelo valor real; 2) Em parâmetros de ferramenta: Configure os parâmetros da ferramenta para usar essas variáveis, permitindo autenticação silenciosa sem mencionar no prompt.

Por exemplo, você pode configurar uma ferramenta para passar automaticamente o caller ID para o endpoint de consulta do seu CRM, permitindo que o agente verifique silenciosamente se o número recebido corresponde ao número cadastrado do cliente para autenticação. Em vez de uma chamada de ferramenta, a autenticação também pode ser feita como um webhook de início de conversa, executado antes do início do atendimento.

Nota de segurança: Como o usuário pode ligar de números diferentes dos cadastrados, ou números salvos podem ser acessados por pessoas não autorizadas, a autenticação baseada em caller ID deve exigir consentimento prévio do cliente ou ser combinada com outros métodos de autenticação (ex: perguntas de conhecimento).

Documentação sobre Variáveis Dinâmicas do Sistema e webhook de início:

• https://www.11labs.ru/docs/agents-platform/customization/personalization/dynamic-variables#system-dynamic-variables 
• https://www.11labs.ru/docs/agents-platform/customization/personalization/twilio-personalization 

Autenticação avançada por perguntas de segurança/conhecimento

O agente pode autenticar o usuário fazendo um conjunto de perguntas de segurança e concedendo acesso apenas se o usuário acertar uma quantidade pré-definida. O agente pode ser instruído a selecionar perguntas aleatórias de uma lista (ex: data de nascimento, CEP, nome do animal de estimação) e validar as respostas por meio de uma chamada de ferramenta ao seu banco de dados.

A ferramenta de autenticação retorna uma resposta JSON incluindo a contagem atual de acertos. Usando atribuições de ferramenta, essa contagem é extraída e armazenada/atualizada automaticamente em uma variável dinâmica (ex: auth_success_count). Após cada verificação bem-sucedida, a variável é incrementada.

Quando o número necessário de verificações for atingido (ex: 3), uma condição de expressão no workflow verifica o valor da variável dinâmica e faz a transição para um nó privilegiado do subagente. A expressão usa operadores de comparação (ex: auth_success_count >= 3) para controlar o acesso de forma determinística conforme o status da autenticação.

Documentação aqui: https://www.11labs.ru/docs/agents-platform/customization/agent-workflows#edges-and-flow-control 

Código único (One-Time Code)

Esse é um método universal em que um código único é enviado ao dispositivo do usuário por SMS ou e-mail. O usuário precisa informar o código ao agente para ser autenticado e obter acesso.

Fluxo de implementação:

1. Geração do código: O agente inicia o processo com uma chamada de ferramenta no servidor para um endpoint dedicado. Isso gera um código seguro e único, enviado ao usuário pelo canal escolhido (SMS ou e-mail).
2. Solicitação ao usuário: O agente pede que o usuário informe o código recebido. No modo voz, o usuário fala o código, que é capturado por reconhecimento de fala.
3. Verificação do código: O agente envia o código informado pelo usuário para um serviço de verificação no backend usando uma segunda chamada de ferramenta. O backend valida se o código confere, não expirou e não foi usado antes.
4. Roteamento do fluxo: O agente lida com o resultado conforme a resposta da verificação: Sucesso: Se o código estiver correto, o usuário segue para a próxima etapa do fluxo via condição de sucesso. Falha: Se o código estiver incorreto, o agente pode pedir para o usuário tentar novamente ou iniciar um procedimento alternativo (ex: enviar um novo código).

Considerações de segurança: É importante implementar limite de tentativas para evitar ataques de força bruta, definir tempo curto de expiração do código (3-5 minutos) e controlar o número de tentativas. Para interações por voz, considere prompts de confirmação para garantir a precisão do reconhecimento de fala ao capturar códigos.

Conclusão

Esses métodos de autenticação são blocos de construção flexíveis, não soluções prontas. Sua escolha deve refletir o perfil de risco, exigências regulatórias e objetivos de experiência do usuário do seu caso. Um bot de atendimento ao cliente precisa de um nível de segurança diferente de um assistente bancário que lida com transações. A flexibilidade da plataforma garante que sua estratégia de segurança possa evoluir conforme surgem novas ameaças e requisitos, sempre equilibrando proteção e experiência do usuário.