Progettare un'autenticazione sicura dei chiamanti per gli agenti vocali
- Pubblicato
- Ultimo aggiornamento
AscoltaAscolta questo articolo
Agenti vocali si stanno evolvendo rapidamente 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 cruciale: come si autentica 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 di account o avviare rimborsi, deve autenticare chi chiama 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 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 aziendali. Tratteremo cinque approcci fondamentali, dall'autenticazione basata sulla sessione per widget incorporati ai metodi specifici per la telefonia e alla verifica OTP, spiegando come implementare ciascuno tramite il controllo deterministico del workflow sulla piattaforma ElevenLabs.
Soprattutto, mostreremo 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, per garantire che solo gli utenti autenticati accedano alle operazioni privilegiate.
In sintesi
- 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 della sessione esistente 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 numero di account o data di nascita, rispetto a un sistema backend tramite una chiamata a un tool lato server.
- Le implementazioni telefoniche possono usare variabili dinamiche di sistema come il caller ID per autenticare in modo silenzioso, ma questo metodo va combinato 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.
La base architetturale dell'autenticazione deterministica
Per garantire che solo gli utenti autenticati possano accedere alle informazioni relative agli account, consigliamo una rigorosa separazione di ambienti e accessi tramite i workflow di ElevenLabs. L'autenticazione deve sempre essere implementata usando una chiamata a un tool con un output booleano di successo o errore, configurato come dispatch tool nel builder di workflow di ElevenLabs.
Collegando direttamente la condizione di trasferimento al risultato della chiamata al tool, 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 di procedere ai 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 chiamate ai tool.
Esempio di implementazione
Verifica l'utente in Salesforce (chiamata a un tool). Se la verifica ha esito positivo, recupera i dati delle transazioni del cliente da Salesforce (un'altra chiamata a un tool), quindi trasferisci l'utente a un sotto-agente responsabile dell'uso di 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 inserite automaticamente nelle chiamate ai tool tramite le stesse variabili dinamiche, consentendo all'agente di recuperare dati personalizzati dai sistemi integrati senza richiedere un'autenticazione separata.
In questo modo il 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 tramite la 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 a chi chiama di fornire dati di autenticazione, come numero di account, 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 rispetto al tuo database, ad esempio un CRM o un archivio delle identità. Il tool restituisce un risultato di successo/errore che include sia uno stato booleano (is_error) sia un testo descrittivo.
Puoi implementarla tramite il controllo deterministico del workflow: dopo aver richiesto le informazioni pertinenti, configura un tool dispatch e usa i collegamenti di trasferimento condizionale del workflow, che si diramano in base allo stato di successo/errore del tool e instradano gli utenti autenticati verso nodi dell'agente “privilegiati”.
Questo approccio supporta sia domande di sicurezza statiche sia verifiche dinamiche in stile “out-of-wallet”, in base ai 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 trunk SIP, il tuo agente ha automaticamente accesso a variabili di sistema specifiche per la telefonia, inclusa 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 con doppie parentesi graffe, ad esempio {{system__caller_id}}, e verranno sostituite con i valori effettivi.
- Nei parametri del tool: configura i parametri del tool in modo che usino queste variabili, consentendo un'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 al numero registrato del cliente per l'autenticazione dell'utente. Invece di una chiamata a un tool, l'autenticazione può anche essere configurata come webhook di avvio della conversazione, eseguito prima dell'inizio della conversazione.
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, ad esempio 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 / su 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 istruire l'agente a selezionare domande casuali da un elenco predefinito, ad esempio data di nascita, CAP o nome dell'animale domestico, e a convalidare le risposte di chi chiama tramite una chiamata a un tool del tuo database.
Il tool di autenticazione restituisce una risposta JSON che include il conteggio corrente dei successi. Tramite le assegnazioni del tool, questo conteggio viene estratto automaticamente e archiviato/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 ed effettua la transizione 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 collegamenti e controllo del flusso contiene altre informazioni utili.
Codice monouso
È un metodo universale in cui un codice monouso viene inviato al dispositivo dell'utente via SMS o email. L'utente deve poi 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 chiamata a un tool 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 tramite una seconda chiamata a un tool. 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 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, tra 3 e 5 minuti, e monitora 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 elementi flessibili da combinare, non soluzioni prescrittive. La tua scelta dovrebbe riflettere il tuo profilo di rischio, i requisiti normativi e gli obiettivi relativi all'esperienza utente. Un bot per il servizio clienti richiede misure di sicurezza diverse da un assistente bancario che gestisce transazioni. La flessibilità della piattaforma consente alla tua strategia di sicurezza di evolversi al cambiare delle minacce e alla crescita dei requisiti, bilanciando sempre protezione ed esperienza utente.
ElevenAgents ti offre il controllo deterministico del workflow, i dispatch tool e le variabili specifiche per la telefonia descritti sopra: puoi quindi creare un'autenticazione di chi chiama che non dipenda mai dal giudizio dell'LLM.
Esplora la piattaforma ElevenAgents per vedere il builder di workflow completo oppure contatta il team vendite per iniziare oggi a creare il tuo primo workflow per agenti vocali autenticati.
