Progettare flussi di autenticazione sicura dell’identità del chiamante per agenti vocali

Gli agenti vocali stanno evolvendo rapidamente: da semplici risponditori di FAQ a sistemi in grado di eseguire azioni, modificare account, gestire transazioni e accedere a dati sensibili dei clienti. Questo cambiamento introduce una sfida fondamentale: come verifichi l’identità del chiamante in un sistema di IA conversazionale dove i metodi di autenticazione visiva tradizionali non esistono?

Quando un agente vocale può aggiornare abbonamenti, recuperare saldi o avviare rimborsi, deve autenticare i chiamanti con la stessa precisione di un call center umano, ma tramite un’interazione interamente vocale. A differenza degli operatori umani che seguono le policy aziendali, gli agenti IA richiedono un’autenticazione deterministica, basata su strumenti, che non si affida al giudizio di un LLM.

In questo articolo presentiamo schemi di autenticazione collaudati, sviluppati come Forward Deployed Engineers in progetti enterprise. Vedremo cinque approcci principali: dall’autenticazione basata su sessione per widget integrati, ai metodi specifici per la telefonia e la verifica OTP, spiegando come implementarli tramite gating deterministico dei workflow sulla piattaforma ElevenLabs.

Soprattutto, mostreremo perché l’autenticazione non può essere affidata all’inferenza conversazionale. Deve invece essere progettata tramite sub-agent isolati, verifiche basate su strumenti e routing condizionale dei workflow, così che solo gli utenti autenticati possano accedere alle operazioni privilegiate.

La base architetturale per un’autenticazione deterministica

Per garantire che solo utenti autenticati possano accedere a informazioni relative all’account, consigliamo una rigorosa separazione di ambiente e accessi tramite i workflow di ElevenLabs. L’autenticazione va sempre implementata tramite una chiamata a uno strumento che restituisce un risultato booleano di successo o fallimento, configurato come tool di dispatch all’interno del workflow builder di ElevenLabs.

Collegando la condizione di trasferimento direttamente al risultato della chiamata allo strumento, il sub-agent con accesso ai dati dell’account diventa raggiungibile solo dopo l’autenticazione riuscita e resta completamente isolato dagli utenti non autenticati. In questo modo l’autenticazione è deterministica, non affidata a una decisione dell’LLM, e si impedisce qualsiasi avanzamento verso nodi successivi senza un’identità verificata.

In alternativa, puoi usare espressioni di trasferimento come metodo affidabile: queste fanno riferimento a variabili dinamiche aggiornate dai risultati delle chiamate agli strumenti.

Esempio di implementazione

Verifica l’utente in Salesforce (chiamata a uno strumento). Se la verifica ha esito positivo, recupera i dati delle transazioni del cliente da Salesforce (altra chiamata a uno strumento) e poi trasferisci l’utente a un subagent incaricato di utilizzare questi dati per comunicare con il cliente e svolgere altre azioni se necessario.

Metodi di autenticazione dell’identità utente

Questi metodi di autenticazione non sono supportati nativamente dalla piattaforma ElevenLabs. Puoi implementarli tramite strumenti lato server che si integrano con il tuo CRM o backend/database dove sono archiviati i dati di autenticazione.

Autenticazione dell’applicazione host

Per agenti vocali integrati in un sito web, l’applicazione host può passare i dati di sessione utente (come stato di login, ID account o token di sessione) tramite variabili dinamiche durante l’inizializzazione dell’agente/widget. Queste variabili vengono automaticamente inserite nelle chiamate agli strumenti, permettendo all’agente di recuperare dati personalizzati dai sistemi integrati senza richiedere un’autenticazione separata.

Questo consente un flusso di supporto senza interruzioni, perché l’utente è già stato verificato dall’applicazione host. Puoi configurarlo tramite impostazioni personalizzate oppure usare il widget ElevenLabs, passando le variabili a runtime nella configurazione del widget (es: <elevenlabs-convai dynamic-variables='{"user_id": "123", "account_tier": "premium"}'>).

Documentazione sulle Variabili Dinamiche:

• https://elevenlabs.io/docs/agents-platform/customization/personalization/dynamic-variables#pass-variables-at-runtime 

Autenticazione basata su conoscenza (KBA)

L’agente vocale chiede al chiamante di fornire dati di autenticazione come numero di account, CAP, data di nascita o risposte di sicurezza. Uno strumento lato server (webhook o client-side) verifica questi valori confrontandoli con il tuo database (ad esempio CRM o identity store). Lo strumento restituisce un risultato di successo/fallimento che include sia uno stato booleano (is_error) sia un testo descrittivo. Puoi implementare questo metodo tramite gating deterministico del workflow: dopo aver richiesto le informazioni necessarie, configura un dispatch dello strumento e usa i trasferimenti condizionali del workflow che instradano gli utenti autenticati verso nodi “privilegiati” dell’agente.

Questo approccio supporta sia domande di sicurezza statiche sia verifiche dinamiche “out-of-wallet”, a seconda delle tue esigenze di rischio frode.

Documentazione sugli Strumenti:

• https://elevenlabs.io/docs/agents-platform/customization/tools/server-tools 
• https://elevenlabs.io/docs/eleven-agents/customization/agent-workflows#dispatch-tool-node 

Variabili dinamiche di sistema (solo telefonia)

Per conversazioni telefoniche (tramite Twilio o SIP trunk), il tuo agente ha automaticamente accesso a variabili di sistema specifiche per la telefonia, tra cui system__caller_id (il numero di telefono del chiamante). Questa variabile viene popolata automaticamente all’avvio della conversazione e può essere usata in due modi: 1) Nei prompt/messaggi: richiamala con doppie parentesi graffe, es: {{system__caller_id}}, e verrà sostituita con il valore reale; 2) Nei parametri degli strumenti: configura i parametri degli strumenti per usare queste variabili, abilitando l’autenticazione silenziosa senza menzionarle nel prompt.

Ad esempio, puoi configurare uno strumento che passa automaticamente il caller ID al tuo endpoint CRM, così l’agente verifica in modo silenzioso se il numero in ingresso corrisponde a quello registrato per l’utente. In alternativa alla chiamata a uno strumento, l’autenticazione può essere configurata come webhook di inizio conversazione che si attiva prima dell’avvio.

Nota di sicurezza: Poiché i chiamanti possono usare numeri diversi da quelli registrati, o i numeri archiviati possono essere accessibili a persone non autorizzate, l’autenticazione basata su caller ID dovrebbe richiedere il consenso preventivo del cliente o essere combinata con altri metodi di autenticazione (es: domande di sicurezza).

Documentazione su Variabili Dinamiche di Sistema e webhook di inizio:

• https://elevenlabs.io/docs/agents-platform/customization/personalization/dynamic-variables#system-dynamic-variables 
• https://elevenlabs.io/docs/agents-platform/customization/personalization/twilio-personalization 

Autenticazione avanzata tramite domande di sicurezza

L’agente può autenticare un utente ponendo una serie di domande di sicurezza e concedendo l’accesso solo se il chiamante risponde correttamente a un numero predefinito di domande. L’agente può essere istruito a selezionare domande casuali da una lista (es: data di nascita, CAP, nome dell’animale domestico) e a validare le risposte tramite una chiamata a uno strumento collegato al tuo database.

Lo strumento di autenticazione restituisce una risposta JSON che include il conteggio attuale delle risposte corrette. Usando le assegnazioni degli strumenti, questo conteggio viene estratto e salvato/aggiornato in una variabile dinamica (es: auth_success_count). Dopo ogni verifica riuscita, la variabile viene incrementata.

Quando viene raggiunto il numero richiesto di verifiche (es: 3), una condizione di espressione del workflow controlla il valore della variabile dinamica e passa a un nodo sub-agent privilegiato. L’espressione usa operatori di confronto (es: auth_success_count >= 3) per regolare in modo deterministico l’accesso in base allo stato di autenticazione.

Documentazione qui:https://elevenlabs.io/docs/eleven-agents/customization/agent-workflows#edges-and-flow-control 

Codice monouso (One-Time Code)

Questo è un metodo universale in cui un codice monouso viene inviato al dispositivo dell’utente tramite SMS o email. L’utente deve poi comunicare il codice all’agente per ottenere l’accesso.

Workflow di implementazione:

1. Generazione del codice: L’agente avvia il processo con una chiamata a uno strumento server verso un endpoint dedicato. Questa azione genera un codice sicuro monouso e lo invia all’utente tramite il canale preferito (SMS o email).
2. Richiesta all’utente: L’agente chiede quindi all’utente di fornire il codice ricevuto. In modalità vocale, l’utente pronuncia il codice ad alta voce, che viene acquisito tramite speech-to-text.
3. Verifica del codice: L’agente invia il codice fornito dall’utente a un servizio di verifica backend tramite una seconda chiamata a uno strumento. Il backend verifica che il codice corrisponda, non sia scaduto e non sia già stato utilizzato.
4. Instradamento del workflow: L’agente gestisce l’esito in base alla risposta di verifica: Successo: se il codice è corretto, l’utente viene indirizzato alla parte post-autenticazione del workflow tramite una condizione di successo. Fallimento: se il codice è errato, l’agente può chiedere di reinserirlo o avviare una procedura alternativa (es: invio di un nuovo codice).

Considerazioni di sicurezza: È importante implementare limiti di tentativi per prevenire attacchi brute force, impostare una scadenza breve per i codici (3-5 minuti) e monitorare i tentativi di inserimento. Per le interazioni vocali, valuta prompt di conferma per garantire l’accuratezza dello speech-to-text nella raccolta dei codici.

Conclusione

Questi metodi di autenticazione sono elementi flessibili da combinare, non soluzioni rigide. La scelta dipende dal tuo profilo di rischio, dai requisiti normativi e dagli obiettivi di esperienza utente. Un bot di assistenza clienti richiede una sicurezza diversa rispetto a un assistente bancario che gestisce transazioni. La flessibilità della piattaforma ti permette di adattare la strategia di sicurezza man mano che cambiano le minacce e crescono le esigenze, mantenendo sempre il giusto equilibrio tra protezione ed esperienza utente.