Progettare un'autenticazione sicura del chiamante per agenti vocali
- Pubblicato
- Ultimo aggiornamento
AscoltaAscolta questo articolo
Gli agenti vocali stanno evolvendo rapidamente: da semplici risponditori di FAQ stanno diventando 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à di chi chiama in un
Quando un
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.
Riepilogo
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.
La base architetturale per un'autenticazione deterministica
Per garantire che solo utenti autenticati possano accedere a informazioni sugli account, consigliamo un ambiente rigoroso e una segregazione degli 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 dispatch tool all'interno del workflow builder di ElevenLabs.
Collegando la condizione di trasferimento direttamente al risultato della chiamata allo strumento, il sotto-agente con accesso ai dati dell'account è raggiungibile solo dopo un'autenticazione riuscita e resta completamente isolato dagli utenti non autenticati. In questo modo l'autenticazione è deterministica, non lasciata a una decisione dell'LLM, e impedisce qualsiasi avanzamento verso nodi successivi senza un'identità verificata.
In alternativa, puoi usare le espressioni di trasferimento come metodo affidabile: queste fanno riferimento a variabili dinamiche aggiornate dai risultati delle chiamate agli strumenti.

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.
Metodi di autenticazione dell'identità utente
Questi metodi di autenticazione non sono supportati nativamente dalla piattaforma ElevenLabs. Puoi implementarli tramite strumenti server-side che si integrano con il tuo CRM o backend/database dove sono archiviati i dati di autenticazione.
Autenticazione tramite 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 all'inizializzazione dell'agente/widget. Queste variabili vengono automaticamente inserite nelle chiamate agli strumenti usando le stesse variabili dinamiche, permettendo all'agente di recuperare dati personalizzati dai sistemi integrati senza richiedere un'autenticazione separata.
Consulta la
Autenticazione basata su conoscenze (KBA)
L'agente vocale chiede al chiamante di fornire dati di autenticazione come numero di conto, CAP, data di nascita o risposte di sicurezza. Uno strumento server-side (webhook o chiamata backend) 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 una chiamata a uno strumento e usa i trasferimenti condizionali del workflow che instradano gli utenti autenticati verso nodi “privilegiati” dell'agente in base all'esito della verifica.
- https://www.panel.temphost.top/docs/agents-platform/customization/tools/server-tools
- https://www.panel.temphost.top/docs/eleven-agents/customization/agent-workflows#dispatch-tool-node
Consulta la
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, inclusa system__caller_id (il numero di telefono del chiamante). Questa variabile si popola automaticamente all'inizio della conversazione.
Puoi utilizzarla in due modi:
Documentazione su Variabili Dinamiche di Sistema e webhook di inizio:
- https://www.panel.temphost.top/docs/agents-platform/customization/personalization/dynamic-variables#system-dynamic-variables
- https://www.panel.temphost.top/docs/agents-platform/customization/personalization/twilio-personalization
Nota di sicurezza:
Per maggiori informazioni, consulta la documentazione su
Autenticazione avanzata tramite domande di sicurezza / conoscenze
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.

Documentazione qui:https://www.panel.temphost.top/docs/eleven-agents/customization/agent-workflows#edges-and-flow-control
Codice monouso (One-Time Code)
La nostra
Codice monouso
- 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).
- 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.
- 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.
- 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).
Ecco il workflow di implementazione nel dettaglio:
Conclusione
Considerazioni di sicurezza: implementa un rate limiting per prevenire tentativi brute-force, imposta una scadenza breve per i codici (3-5 minuti) e limita i tentativi di ripetizione. Per le interazioni vocali, valuta prompt di conferma per garantire l'accuratezza dello speech-to-text nella raccolta dei codici.



