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 agire, modificare account, elaborare transazioni e accedere a dati sensibili dei clienti. Questo cambiamento introduce una sfida cruciale: come autentichi l'identità di chi chiama 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 del conto o avviare rimborsi, deve autenticare chi chiama con lo stesso rigore dei call center gestiti da persone, 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 di un LLM.
Questo articolo illustra modelli di autenticazione collaudati, tratti dal nostro lavoro come Forward Deployed Engineer in implementazioni enterprise. Esamineremo cinque approcci principali, dall'autenticazione basata sulla sessione per widget incorporati ai metodi specifici per la telefonia e alla verifica OTP, e spiegheremo come implementare ciascuno tramite workflow gating deterministico sulla piattaforma ElevenLabs.
Ancora più importante, mostreremo perché l'autenticazione non può essere affidata all'inferenza conversazionale. Deve invece essere progettata tramite sotto-agenti isolati, verifica basata su tool e routing condizionale del workflow, così che solo gli utenti autenticati possano accedere a operazioni privilegiate.
Riepilogo
- L'autenticazione di chi chiama 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 i dati di sessione esistenti all'agente, quindi gli utenti che hanno già effettuato l'accesso non devono autenticarsi di nuovo.
- L'autenticazione basata sulla conoscenza verifica i dati forniti da chi chiama, come un numero di conto o la data di nascita, confrontandoli con 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 l'utente senza interrompere la conversazione, ma andrebbero combinate con un secondo fattore poiché il caller ID può essere falsificato o condiviso.
- La verifica con codice monouso invia un codice via SMS o email e lo convalida tramite un servizio backend.
Le fondamenta architetturali dell'autenticazione deterministica
Per assicurarti che solo gli utenti autenticati possano accedere alle informazioni relative agli account, consigliamo una rigorosa separazione degli ambienti e degli accessi tramite i workflow di ElevenLabs. L'autenticazione dovrebbe sempre essere implementata con una tool call che restituisce un valore booleano di successo o fallimento, configurata come dispatch tool nel workflow builder di ElevenLabs.
Collegando direttamente la condizione di trasferimento al risultato della tool call, il sotto-agente con accesso ai dati dell'account è raggiungibile solo dopo un'autenticazione riuscita e rimane completamente isolato dagli utenti non autenticati. Questo garantisce che l'autenticazione sia deterministica, non affidata 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 di trasferimento affidabile. 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 va a buon fine, recupera i dati sulle transazioni del cliente da Salesforce (un'altra tool call), quindi trasferisci l'utente a un sotto-agente responsabile 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 quando inizializza l'agente o il widget. Queste variabili vengono inserite automaticamente nelle tool call usando 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, a cui passi le variabili a runtime tramite la configurazione del widget (ad esempio, <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 a chi chiama di fornire dati per l'autenticazione, come numero di conto, CAP, data di nascita o risposte a domande di sicurezza. Un tool lato server, come un webhook o una chiamata al backend, verifica questi valori confrontandoli con il tuo database, ad esempio un CRM o un archivio di identità. Il tool restituisce un risultato di successo/fallimento 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/fallimento del tool, indirizzando gli utenti autenticati verso nodi dell'agente “privilegiati”.
Questo approccio supporta sia domande di sicurezza statiche sia verifiche dinamiche in stile "out-of-wallet", a seconda dei requisiti relativi al rischio di frode.
Consulta la documentazione sui tool lato server e sul nodo dispatch tool dei workflow degli agenti per maggiori dettagli.
Variabili dinamiche di sistema (solo telefonia)
Per le 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, ovvero il numero di telefono di chi chiama. Questa variabile viene popolata automaticamente all'avvio della conversazione.
Puoi farvi riferimento in due modi:
- Nei prompt/messaggi: fai riferimento a queste variabili usando le doppie parentesi graffe, ad esempio {{system__caller_id}}, che verranno sostituite con i valori effettivi.
- Nei parametri dei tool: configura i parametri dei tool per usare 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 senza interrompere la conversazione se il numero in entrata corrisponde a quello registrato dal cliente per l'autenticazione dell'utente. Invece di una tool call, puoi anche configurare l'autenticazione come webhook di avvio della conversazione, eseguito prima che questa inizi.
Nota sulla sicurezza: Poiché chi chiama potrebbe usare numeri diversi da quelli registrati, oppure i numeri memorizzati 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 su Variabili dinamiche di sistema e webhook di avvio.
Autenticazione avanzata basata sulla conoscenza / domande di sicurezza
L'agente può autenticare un utente ponendo una serie di domande di sicurezza e concedendo l'accesso solo se chi chiama risponde correttamente a un numero predefinito di domande. Puoi configurare l'agente affinché selezioni domande casuali da un elenco predefinito, ad esempio data di nascita, CAP o nome dell'animale domestico, e convalidi le risposte tramite una tool call al tuo database.
Il tool di autenticazione restituisce una risposta JSON che include il conteggio attuale delle verifiche riuscite. Tramite le assegnazioni dei tool, questo conteggio viene estratto automaticamente e memorizzato o aggiornato in una variabile dinamica, ad esempio auth_success_count. Dopo ogni verifica riuscita, la variabile viene incrementata.
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 privilegiato. 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 ulteriori informazioni di riferimento.
Codice monouso
È 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 affinché venga verificato e possa ottenere l'accesso.
Ecco il workflow di implementazione più nel dettaglio:
- Generazione del codice: l'agente avvia il processo con una tool call lato server verso un endpoint dedicato. Questa azione attiva la generazione di 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 backend di verifica tramite una seconda tool call. Il backend convalida che il codice corrisponda, non sia scaduto e non sia già stato usato.
- Routing del workflow: l'agente gestisce il risultato 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. Fallimento: se il codice non è corretto, l'agente può chiedere all'utente di inserirlo nuovamente o avviare una procedura alternativa, ad esempio inviare un nuovo codice.
Considerazioni sulla sicurezza: dovresti implementare il rate limiting per prevenire tentativi brute-force, i codici dovrebbero avere tempi di scadenza brevi, da 3 a 5 minuti, e i tentativi ripetuti dovrebbero essere monitorati e limitati. Per le interazioni vocali, valuta prompt di conferma per garantire l'accuratezza della sintesi vocale nel rilevamento dei codici.
Inizia a usare ElevenAgents per un'autenticazione vocale sicura
Questi metodi di autenticazione sono elementi flessibili da combinare, non soluzioni prescrittive. La scelta dovrebbe riflettere il tuo profilo di rischio specifico, i requisiti normativi e gli obiettivi in termini di esperienza utente. Un bot per il servizio clienti richiede misure di sicurezza diverse da un assistente bancario che gestisce transazioni. La flessibilità della piattaforma garantisce che la tua strategia di sicurezza possa evolvere al cambiare delle minacce e al crescere dei requisiti, bilanciando sempre 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 di chi chiama che non dipenda mai dal giudizio dell'LLM.
Esplora la piattaforma ElevenAgents per vedere il workflow builder completo, oppure contatta il team vendite per iniziare oggi a creare il tuo primo workflow di agente vocale autenticato.
