Progettare un'autenticazione sicura dei chiamanti per gli agenti vocali
- Pubblicato
- Ultimo aggiornamento
AscoltaAscolta questo articolo
Gli agenti vocali si stanno rapidamente evolvendo da semplici sistemi che rispondono alle FAQ a sistemi in grado di eseguire azioni, modificare account, elaborare transazioni e accedere a dati sensibili dei clienti. Questo cambiamento introduce una sfida fondamentale: come autentichi l'identità di un chiamante in un sistema di IA conversazionale in cui non esistono i tradizionali metodi di verifica visiva?
Quando un agente vocale può aggiornare abbonamenti, recuperare saldi dell'account o avviare rimborsi, deve autenticare i chiamanti con lo stesso rigore dei call center umani, ma attraverso un'interazione interamente vocale. A differenza degli operatori umani, che seguono le policy aziendali, gli agenti IA richiedono un'autenticazione deterministica e basata su tool che non dipenda dal giudizio dell'LLM.
Questo articolo illustra modelli di autenticazione collaudati emersi dal nostro lavoro come Forward Deployed Engineers in implementazioni enterprise. Esamineremo cinque approcci principali, dall'autenticazione basata su sessione per widget incorporati ai metodi specifici per la telefonia e alla verifica OTP, spiegando come implementare ciascuno tramite workflow gating deterministico sulla piattaforma ElevenLabs.
Soprattutto, dimostreremo perché l'autenticazione non può essere affidata all'inferenza conversazionale. Deve invece essere progettata tramite sotto-agenti isolati, verifica basata su tool e instradamento condizionale del workflow, così da garantire che solo gli utenti autenticati accedano alle operazioni con privilegi.
In sintesi
- L'autenticazione dei chiamanti per gli agenti vocali deve essere deterministica e basata su tool; non può essere affidata all'inferenza conversazionale dell'LLM.
- L'autenticazione dell'applicazione host passa all'agente i dati di sessione esistenti, così gli utenti che hanno già effettuato l'accesso non devono autenticarsi di nuovo.
- L'autenticazione basata sulla conoscenza verifica i dati forniti dal chiamante, come numero di account o data di nascita, rispetto a un sistema backend tramite una tool call lato server.
- Le implementazioni di telefonia possono usare variabili dinamiche di sistema come il caller ID per autenticare silenziosamente gli utenti, ma questo metodo dovrebbe essere combinato con un secondo fattore, poiché il caller ID può essere falsificato o condiviso.
- La verifica con codice monouso invia un codice tramite SMS o email e lo convalida attraverso un servizio backend.
Le basi architetturali dell'autenticazione deterministica
Per garantire che solo gli utenti autenticati possano accedere alle informazioni relative agli account, consigliamo una rigorosa segregazione di ambienti e accessi tramite i workflow di ElevenLabs. L'autenticazione deve essere sempre implementata mediante una tool call con un output booleano di successo o errore, configurata come dispatch tool nel builder dei workflow di ElevenLabs.
Collegando direttamente la condizione di trasferimento al risultato della tool call, il sotto-agente che ha accesso ai dati dell'account è raggiungibile solo dopo un'autenticazione riuscita e rimane completamente isolato dagli utenti non autenticati. Questo rende l'autenticazione deterministica, senza affidarla 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 per il trasferimento. Queste espressioni fanno riferimento a variabili dinamiche aggiornate tramite i risultati delle tool call.
Esempio di implementazione
Verifica l'utente in Salesforce (tool call). Se la verifica ha esito positivo, recupera i dati sulle transazioni del cliente da Salesforce (un'altra tool call), quindi trasferisci l'utente a un sotto-agente incaricato di usare questi dati per comunicare con il cliente ed eseguire altre azioni, se necessario.
Metodi di autenticazione dell'identità utente
Questi metodi di autenticazione non sono supportati nativamente dalla piattaforma ElevenLabs. Puoi implementarli tramite tool lato server che si integrano con il tuo CRM o backend/database, dove sono archiviati i dati di autenticazione.
Autenticazione dell'applicazione host
Per gli agenti vocali incorporati in un sito web, l'applicazione host può passare i dati di sessione dell'utente, come stato di accesso, ID dell'account o token di sessione, tramite variabili dinamiche durante l'inizializzazione dell'agente/widget. Queste variabili vengono automaticamente inserite nelle tool call tramite le stesse variabili dinamiche, consentendo all'agente di recuperare dati personalizzati dai sistemi integrati senza richiedere un'autenticazione separata.
Questo consente un flusso di assistenza senza interruzioni, perché l'utente è già stato verificato dall'applicazione host. Puoi configurarlo tramite una configurazione personalizzata oppure usare il widget ElevenLabs, passando le variabili a runtime nella configurazione del widget (ad es., <elevenlabs-convai dynamic-variables='{"user_id": "123", "account_tier": "premium"}'>).
Consulta la documentazione sulle variabili dinamiche per la configurazione completa.
Autenticazione basata sulla conoscenza (KBA)
L'agente vocale chiede al chiamante di fornire dati di autenticazione come numero di account, codice postale, data di nascita o risposte a domande di sicurezza. Un tool lato server (webhook o chiamata backend) verifica questi valori rispetto al tuo database, ad esempio un CRM o un archivio di identità. Il tool restituisce un risultato di successo/errore che include sia uno stato booleano (is_error) sia un testo descrittivo.
Puoi implementarlo tramite workflow gating deterministico: dopo aver richiesto le informazioni pertinenti, configura un dispatch tool e usa edge di trasferimento condizionale del workflow che si diramano in base allo stato di successo/errore del tool, instradando gli utenti autenticati verso nodi dell'agente con privilegi.
Questo approccio supporta sia domande di sicurezza statiche sia verifiche dinamiche in stile "out-of-wallet", in base ai tuoi requisiti relativi al rischio di frode.
Per maggiori dettagli, consulta la documentazione su server tools e nodo dispatch tool dei workflow degli agenti.
Variabili dinamiche di sistema (solo telefonia)
Per le conversazioni telefoniche, tramite Twilio o SIP trunk, il tuo agente ha automaticamente accesso alle variabili di sistema specifiche della telefonia, incluso system__caller_id, ovvero il numero di telefono del chiamante. Questa variabile viene popolata automaticamente all'avvio della conversazione.
Puoi farvi riferimento in due modi:
- Nei prompt/messaggi: fai riferimento alle variabili usando doppie parentesi graffe, ad es. {{system__caller_id}}, che verranno sostituite con i valori effettivi.
- Nei parametri del tool: configura i parametri del tool affinché usino queste variabili, abilitando l'autenticazione silenziosa senza menzionarle nel prompt.
Ad esempio, puoi configurare un tool affinché passi automaticamente il caller ID all'endpoint di ricerca del tuo CRM, consentendo all'agente di verificare silenziosamente se il numero in entrata corrisponde a quello registrato dal cliente per l'autenticazione dell'utente. Invece di una tool call, puoi configurare l'autenticazione anche come webhook di avvio della conversazione, eseguito prima che la conversazione inizi.
Nota sulla sicurezza: poiché i chiamanti potrebbero usare numeri diversi da quelli registrati, oppure i numeri archiviati potrebbero essere accessibili a persone non autorizzate, l'autenticazione basata sul caller ID dovrebbe richiedere il consenso preventivo del cliente o essere combinata con metodi di autenticazione aggiuntivi, come domande basate sulla conoscenza.
Per maggiori informazioni, consulta la documentazione sulle variabili dinamiche di sistema e sul webhook di avvio.
Autenticazione avanzata basata sulla conoscenza o su 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 prestabilito di domande. Puoi configurare l'agente affinché selezioni domande casuali da un elenco predefinito, ad esempio data di nascita, codice postale o nome dell'animale domestico, e convalidi le risposte del chiamante tramite una tool call al tuo database.
Il tool di autenticazione restituisce una risposta JSON che include il conteggio corrente delle verifiche riuscite. Tramite le assegnazioni del tool, questo conteggio viene estratto automaticamente e archiviato o aggiornato in una variabile dinamica, ad esempio auth_success_count. Dopo ogni verifica riuscita, la variabile aumenta.
Una volta raggiunto il numero richiesto di verifiche, ad esempio 3, una condizione di espressione del workflow controlla il valore della variabile dinamica e passa a un nodo di sotto-agente con privilegi. L'espressione usa operatori di confronto, ad esempio auth_success_count >= 3, per controllare in modo deterministico l'accesso in base allo stato di autenticazione.
La nostra documentazione su edge e controllo del flusso contiene altre informazioni di riferimento.
Codice monouso
Si tratta di un metodo universale in cui un codice monouso viene inviato al dispositivo dell'utente tramite SMS o email. L'utente deve quindi comunicare il codice all'agente per verificarlo e ottenere l'accesso.
Ecco il workflow di implementazione nel dettaglio:
- Generazione del codice: l'agente avvia il processo con una tool call lato server a un endpoint dedicato. Questa azione genera un codice monouso sicuro 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, gli utenti pronunciano 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 mediante una seconda tool call. Il backend convalida 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 del workflow successiva all'autenticazione tramite una condizione di successo. Errore: se il codice non è corretto, l'agente può chiedere all'utente di inserirlo di nuovo o avviare una procedura di fallback, ad esempio inviare un nuovo codice.
Considerazioni sulla sicurezza: implementa il rate limiting per prevenire tentativi di forza bruta, imposta tempi di scadenza brevi per i codici, da 3 a 5 minuti, e traccia e limita i tentativi ripetuti. Per le interazioni vocali, valuta prompt di conferma per garantire l'accuratezza dello Speech to Text durante l'acquisizione dei codici.
Inizia a usare ElevenAgents per un'autenticazione vocale sicura
Questi metodi di autenticazione sono componenti flessibili, non soluzioni prescrittive. La tua scelta dovrebbe riflettere il tuo specifico profilo di rischio, i requisiti normativi e gli obiettivi relativi all'esperienza utente. Un bot per il servizio clienti richiede un livello di sicurezza diverso da un assistente bancario che gestisce transazioni. La flessibilità della piattaforma consente alla tua strategia di sicurezza di evolvere con il cambiamento delle minacce e la crescita dei requisiti, mantenendo sempre il giusto equilibrio tra protezione ed esperienza utente.
ElevenAgents ti offre il workflow gating deterministico, i dispatch tool e le variabili specifiche per la telefonia descritti sopra, così puoi creare un'autenticazione dei chiamanti che non dipende mai dal giudizio dell'LLM.
Esplora la piattaforma ElevenAgents per vedere il builder di workflow completo, oppure contatta le vendite per iniziare oggi a creare il tuo primo workflow per agenti vocali autenticati.
