Utforma säker uppringarautentisering för röstassistenter

Röstagenter utvecklas snabbt från enkla svarare på vanliga frågor till system som kan ändra konton, behandla transaktioner och få åtkomst till känsliga kunddata. Den här förändringen innebär en avgörande utmaning: Hur autentiserar du en uppringares identitet i ett konversationsbaserat AI-system där traditionella visuella verifieringsmetoder saknas?

När en röstagent kan uppdatera prenumerationer, hämta kontosaldon eller initiera återbetalningar måste den autentisera uppringare med samma noggrannhet som mänskliga kundtjänstcenter, men helt och hållet genom röstinteraktion. Till skillnad från mänskliga agenter som följer företagets policyer kräver AI-agenter deterministisk, verktygsbaserad autentisering som inte förlitar sig på LLM-bedömningar.

I den här artikeln beskriver vi beprövade autentiseringsmönster från vårt arbete som Forward Deployed Engineers i företagsimplementationer. Vi går igenom fem huvudmetoder, från sessionsbaserad autentisering för inbäddade widgetar till telefonspecifika metoder och OTP-verifiering, och förklarar hur du implementerar dem med deterministisk arbetsflödesstyrning på ElevenLabs-plattformen.

Framför allt visar vi varför autentisering inte kan lämnas åt slutsatser i samtalet. Den måste i stället byggas med isolerade underagenter, verktygsbaserad verifiering och villkorlig dirigering i arbetsflödet, så att endast autentiserade användare når behörighetskrävande åtgärder.

Sammanfattning

• Autentisering av uppringare för röstagenter måste vara deterministisk och verktygsbaserad; den kan inte överlåtas åt LLM:ens tolkning av samtalet.
• Autentisering i värdappen skickar befintliga sessionsdata till agenten, så att användare som redan är inloggade inte behöver autentisera sig igen.
• Kunskapsbaserad autentisering verifierar uppgifter som uppringaren anger, exempelvis kontonummer eller födelsedatum, mot ett backend-system via ett verktygsanrop på serversidan.
• Telefonilösningar kan använda dynamiska systemvariabler, till exempel nummerpresentatören, för tyst autentisering, men detta bör kombineras med en andra faktor eftersom nummerpresentatören kan förfalskas eller delas.
• Verifiering med engångskod skickar en kod via SMS eller e-post och validerar den genom en backend-tjänst.

Den arkitektoniska grunden för deterministisk autentisering

För att säkerställa att endast autentiserade användare kan komma åt kontorelaterad information rekommenderar vi strikt separation av miljöer och åtkomst genom ElevenLabs arbetsflöden. Autentisering bör alltid implementeras med ett verktygsanrop som har ett booleskt resultat för lyckat eller misslyckat och konfigureras som ett dispatch-verktyg i ElevenLabs arbetsflödesbyggare.

Genom att koppla överföringsvillkoret direkt till resultatet av verktygsanropet kan underagenten med åtkomst till kontodata bara nås efter lyckad autentisering och förblir helt isolerad från oautentiserade användare. Det säkerställer att autentiseringen är deterministisk, inte lämnas åt ett LLM-beslut, och förhindrar att användaren går vidare till efterföljande noder utan verifierad identitet.

Som alternativ kan överföringsuttryck användas som en tillförlitlig överföringsmetod. Dessa uttryck refererar till dynamiska variabler som uppdateras genom resultat från verktygsanrop.

Exempel på implementation

Verifiera användaren i Salesforce (verktygsanrop). Om det lyckas hämtar du kundens transaktionsdata från Salesforce (ytterligare ett verktygsanrop) och överför sedan användaren till en underagent som ansvarar för att använda datan för att kommunicera med kunden och utföra andra åtgärder vid behov.

Metoder för autentisering av användaridentitet

Dessa autentiseringsmetoder stöds inte direkt i ElevenLabs-plattformen. De kan implementeras med verktyg på serversidan som integreras med ditt CRM-system eller din backend/databas, där autentiseringsdata lagras.

Autentisering i värdappen

För röstagenter som är inbäddade på en webbplats kan värdappen skicka användarens sessionsdata (som inloggningsstatus, konto-ID eller sessionstoken) via dynamiska variabler när agenten/widgeten initieras. Dessa variabler infogas automatiskt i verktygsanrop med samma dynamiska variabler, vilket gör att agenten kan hämta personanpassade data från integrerade system utan separat autentisering.

Det möjliggör ett smidigt supportflöde, eftersom användaren redan har verifierats av värdappen. Du kan konfigurera detta med en egen konfiguration eller använda ElevenLabs-widgeten, där du skickar variabler vid körning via widgetkonfigurationen (t.ex. <elevenlabs-convai dynamic-variables='{"user_id": "123", "account_tier": "premium"}'>).

Se dokumentationen för dynamiska variabler för fullständig konfiguration.

Kunskapsbaserad autentisering (KBA) 

Röstagenter ber uppringaren att ange autentiseringsuppgifter, exempelvis kontonummer, postnummer, födelsedatum eller svar på säkerhetsfrågor. Ett verktyg på serversidan (en webhook eller ett backend-anrop) verifierar uppgifterna mot din databas (t.ex. CRM eller identitetsdatabas). Verktyget returnerar ett resultat som anger lyckat/misslyckat och innehåller både en boolesk status (is_error) och beskrivande text.

Du kan implementera detta med deterministisk arbetsflödesstyrning: När den relevanta informationen har begärts konfigurerar du ett dispatch-verktyg och använder villkorliga överföringsgrenar i arbetsflödet som förgrenas utifrån verktygets status för lyckat/misslyckat och leder autentiserade användare till agentnoder med utökad behörighet. 

Metoden stöder både statiska säkerhetsfrågor och dynamisk verifiering i "out-of-wallet"-stil, beroende på dina krav kring bedrägeririsk.

Se dokumentationen för serververktyg och noden dispatch-verktyg i agentarbetsflöden för mer information.

Dynamiska systemvariabler (endast telefoni)

Vid telefonbaserade samtal (via Twilio eller SIP-trunk) har din agent automatiskt åtkomst till telefonspecifika systemvariabler, inklusive system__caller_id (uppringarens telefonnummer). Variabeln fylls i automatiskt när samtalet startar.

Du kan referera till den på två sätt:

1. I promptar/meddelanden: Referera till dem med dubbla klamrar, t.ex. {{system__caller_id}}, så ersätts de med faktiska värden.
2. I verktygsparametrar: Konfigurera verktygsparametrar att använda dessa variabler, vilket möjliggör tyst autentisering utan att nämna dem i prompten.

Du kan till exempel konfigurera ett verktyg att automatiskt skicka nummerpresentatören till din CRM-sökslutpunkt, så att agenten tyst kan verifiera om det inkommande numret matchar kundens registrerade nummer för användarautentisering. I stället för ett verktygsanrop kan autentiseringen också konfigureras som en webhook för initiering av samtal, som körs innan samtalet börjar. 

Säkerhetsnotering: Eftersom uppringare kan använda andra nummer än de som finns registrerade, eller eftersom lagrade nummer kan vara tillgängliga för obehöriga personer, bör autentisering baserad på nummerpresentatör kräva att kunden har godkänt det i förväg eller kombineras med ytterligare autentiseringsmetoder (t.ex. kunskapsbaserade frågor).

Mer information finns i dokumentationen om dynamiska systemvariabler och webhook för initiering.

Avancerad kunskapsbaserad autentisering/autentisering med säkerhetsfrågor

Agenten kan autentisera en användare genom att ställa en uppsättning säkerhetsfrågor och bara ge åtkomst om uppringaren svarar rätt på ett fördefinierat antal. Agenten kan instrueras att välja slumpmässiga frågor från en fördefinierad lista (t.ex. födelsedatum, postnummer eller husdjurets namn) och validera uppringarens svar genom ett verktygsanrop till din databas.

Autentiseringsverktyget returnerar ett JSON-svar som innehåller det aktuella antalet lyckade verifieringar. Med verktygstilldelningar extraheras detta antal automatiskt och lagras/uppdateras i en dynamisk variabel (t.ex. auth_success_count). Efter varje lyckad verifiering ökar variabeln.

När det erforderliga antalet verifieringar har uppnåtts (t.ex. 3) kontrollerar ett villkor i ett arbetsflödesuttryck värdet på den dynamiska variabeln och övergår till en underagentnod med utökad behörighet. Uttrycket använder jämförelseoperatorer (t.ex. auth_success_count >= 3) för att deterministiskt styra åtkomsten utifrån autentiseringsstatusen.

Vår dokumentation om grenar och flödesstyrning innehåller mer information.

Engångskod

Detta är en universell metod där en engångskod skickas till användarens enhet via SMS eller e-post. Användaren måste sedan uppge koden för agenten så att den kan verifieras och åtkomst beviljas.

Här är implementeringsflödet mer i detalj:

1. Kodgenerering: Agenten startar processen med ett verktygsanrop på serversidan till en särskild slutpunkt. Åtgärden genererar en säker engångskod och skickar den till användaren via den kanal som användaren föredrar (SMS eller e-post).
2. Fråga till användaren: Agenten ber sedan användaren att ange koden de fått. I röstläge läser användaren upp koden, som fångas upp via tal-till-text.
3. Kodverifiering: Agenten skickar koden som användaren har angett till en backend-tjänst för verifiering genom ett andra verktygsanrop. Backend-systemet validerar att koden stämmer, inte har gått ut och inte redan har använts.
4. Dirigering i arbetsflödet: Agenten hanterar resultatet utifrån verifieringssvaret: Lyckat: Om koden är korrekt leds användaren till delen av arbetsflödet efter autentisering via ett framgångsvillkor. Misslyckat: Om koden är felaktig kan agenten be användaren att ange den igen eller starta en reservprocedur (t.ex. skicka en ny kod).

Säkerhetsaspekter: Begränsa antalet försök för att förhindra brute force-attacker, använd korta giltighetstider för koder (3–5 minuter) och spåra samt begränsa återförsök. För röstinteraktioner bör du överväga bekräftelsefrågor för att säkerställa att tal-till-text fångar koder korrekt.

Kom igång med ElevenAgents för säker röstautentisering

Dessa autentiseringsmetoder är flexibla byggblock, inte föreskrivna lösningar. Ditt val bör spegla din specifika riskprofil, regulatoriska krav och mål för användarupplevelsen. En kundtjänstbot behöver en annan säkerhetsnivå än en bankassistent som hanterar transaktioner. Plattformens flexibilitet gör att din säkerhetsstrategi kan utvecklas när hot förändras och kraven ökar, med en ständig balans mellan skydd och användarupplevelse.

ElevenAgents ger dig den deterministiska arbetsflödesstyrningen, dispatch-verktygen och de telefonspecifika variabler som beskrivs ovan, så att du kan skapa autentisering av uppringare som aldrig är beroende av LLM-bedömningar.

Utforska ElevenAgents-plattformen för att se hela arbetsflödesbyggaren, eller kontakta säljteamet för att börja skapa ditt första arbetsflöde för autentiserade röstagenter redan i dag.

Vanliga frågor om säkra flöden för autentisering av uppringares identitet