Utforma säker uppringarautentisering för röstassistenter

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

När en röstassistent kan uppdatera prenumerationer, hämta kontosaldon eller initiera återbetalningar måste den autentisera uppringare lika noggrant som mänskliga kundtjänstmedarbetare, men helt via röstinteraktion. Till skillnad från mänskliga medarbetare som följer företagets riktlinjer behöver AI-assistenter deterministisk, verktygsbaserad autentisering som inte bygger på LLM-bedömningar.

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

Viktigast av allt är att vi visar varför autentisering inte kan överlåtas åt konversationsbaserad slutledning. I stället måste den utformas med isolerade underassistenter, verktygsbaserad verifiering och villkorlig flödesdirigering som säkerställer att endast autentiserade användare når behörighetsstyrda åtgärder.

Sammanfattning

• Autentisering av uppringare för röstassistenter måste vara deterministisk och verktygsbaserad; den kan inte överlåtas åt LLM:ens konversationsbaserade slutledning.
• Autentisering i värdapplikationen skickar befintliga sessionsdata till assistenten, så användare som redan är inloggade behöver inte autentisera sig igen.
• Kunskapsbaserad autentisering kontrollerar uppgifter som den uppringande anger, till exempel kontonummer eller födelsedatum, mot ett backend-system via ett verktygsanrop på serversidan.
• Telefonilösningar kan använda systemets dynamiska variabler, som 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 via en backend-tjänst.

Den arkitektoniska grunden för deterministisk autentisering

För att säkerställa att endast autentiserade användare får åtkomst till kontorelaterad information rekommenderar vi strikt separation av miljöer och åtkomst via ElevenLabs arbetsflöden. Autentisering bör alltid implementeras med ett verktygsanrop som ger ett booleskt resultat för lyckat eller misslyckat, konfigurerat som ett dispatchverktyg i ElevenLabs arbetsflödesbyggare.

Genom att koppla överföringsvillkoret direkt till resultatet från verktygsanropet kan underassistenten med åtkomst till kontodata endast nås efter lyckad autentisering och förblir helt isolerad från oautentiserade användare. Det säkerställer att autentiseringen är deterministisk och inte överlåts åt ett LLM-beslut, och förhindrar att processen går vidare till efterföljande noder utan en 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 verifieringen lyckas hämtar du kundens transaktionsdata från Salesforce (ett annat verktygsanrop) och överför sedan användaren till en underassistent som använder dessa data 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 inbyggt i ElevenLabs plattform. De kan implementeras med verktyg på serversidan som integreras med ditt CRM eller din backend/databas, där autentiseringsdata lagras.

Autentisering i värdapplikationen

För röstassistenter som är inbäddade på en webbplats kan värdapplikationen skicka användarens sessionsdata, till exempel inloggningsstatus, konto-ID eller sessionstoken, via dynamiska variabler när assistenten/widgeten initieras. Variablerna läggs automatiskt in i verktygsanrop med hjälp av samma dynamiska variabler, vilket gör att assistenten kan hämta personliga data från integrerade system utan separat autentisering.

Detta ger ett smidigt supportflöde eftersom användaren redan har verifierats av värdapplikationen. Du kan konfigurera detta anpassat eller använda ElevenLabs widget, där du skickar variabler vid körning via widgetens konfiguration (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östassistenten ber den uppringande ange autentiseringsuppgifter, såsom kontonummer, postnummer, födelsedatum eller svar på säkerhetsfrågor. Ett verktyg på serversidan (webhook eller backend-anrop) kontrollerar dessa värden mot din databas, till exempel CRM eller ett identitetsregister. Verktyget returnerar ett resultat för lyckat/misslyckat som innehåller både en boolesk status (is_error) och beskrivande text.

Du kan implementera detta genom deterministisk flödesstyrning: Efter att ha begärt in relevant information konfigurerar du ett verktygsanrop och använder villkorliga överföringskanter i arbetsflödet som förgrenar sig utifrån verktygets status för lyckat/misslyckat och dirigerar autentiserade användare till ”behörighetsstyrda” assistentnoder. 

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 dispatchverktygsnod för agentarbetsflöden för mer information.

Systemets dynamiska variabler (endast telefoni)

För telefonsamtal (via Twilio eller SIP-trunk) har assistenten automatiskt åtkomst till telefonspecifika systemvariabler, inklusive system__caller_id (den uppringandes telefonnummer). Variabeln fylls i automatiskt när samtalet startar.

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

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

Du kan till exempel konfigurera ett verktyg för att automatiskt skicka nummerpresentatören till din CRM-sökändpunkt, så att assistenten tyst kan kontrollera 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 samtalet 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å nummerpresentation kräva kundens samtycke i förväg eller kombineras med ytterligare autentiseringsmetoder, till exempel kunskapsbaserade frågor.

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

Avancerad kunskapsbaserad autentisering / autentisering med säkerhetsfrågor

Assistenten kan autentisera en användare genom att ställa flera säkerhetsfrågor och endast ge åtkomst om den uppringande svarar rätt på ett fördefinierat antal. Assistenten kan uppmanas att välja slumpmässiga frågor från en fördefinierad lista, till exempel födelsedatum, postnummer eller husdjurets namn, och validera svaren genom ett verktygsanrop till din databas.

Autentiseringsverktyget returnerar ett JSON-svar som innehåller aktuellt antal lyckade verifieringar. Med verktygstilldelningar extraheras antalet automatiskt och lagras/uppdateras i en dynamisk variabel, till exempel auth_success_count. Efter varje lyckad verifiering ökar variabeln.

När det nödvändiga antalet verifieringar har uppnåtts, till exempel 3, kontrollerar ett villkor i ett arbetsflödesuttryck värdet på den dynamiska variabeln och övergår till en behörighetsstyrd underassistentnod. Uttrycket använder jämförelseoperatorer, till exempel auth_success_count >= 3, för att deterministiskt styra åtkomsten utifrån autentiseringsstatus.

Vår dokumentation om kanter 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 assistenten för att verifieras och få åtkomst.

Så här ser implementeringsflödet ut mer i detalj:

1. Kodgenerering: Assistenten startar processen med ett verktygsanrop på serversidan till en särskild ändpunkt. Åtgärden utlöser genereringen av en säker engångskod och skickar den till användaren via den kanal som användaren föredrar, SMS eller e-post.
2. Uppmaning till användaren: Assistenten ber sedan användaren att ange koden de har fått. I röstläge säger användaren koden högt, och den registreras genom tal-till-text.
3. Kodverifiering: Assistenten skickar koden som användaren angav till en backend-tjänst för verifiering med ett andra verktygsanrop. Backend-systemet kontrollerar att koden stämmer, inte har gått ut och inte redan har använts.
4. Flödesdirigering: Assistenten hanterar utfallet utifrån verifieringssvaret: Lyckat: Om koden är korrekt dirigeras användaren till delen av arbetsflödet efter autentisering via ett lyckat villkor. Misslyckat: Om koden är felaktig kan assistenten be användaren att ange den igen eller starta en reservprocedur, till exempel skicka en ny kod.

Säkerhetsaspekter: Begränsning av antal försök bör implementeras för att förhindra brute force-försök, koder bör ha kort giltighetstid (3–5 minuter) och nya försök bör spåras och begränsas. För röstinteraktioner bör du överväga bekräftelseprompter för att säkerställa att tal-till-text korrekt fångar upp koder.

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

De här autentiseringsmetoderna är flexibla byggstenar, inte färdiga lösningar. Ditt val bör spegla din specifika riskprofil, regulatoriska krav och mål för användarupplevelsen. En kundtjänstbot behöver annan säkerhet ä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, samtidigt som skydd och användarupplevelse alltid balanseras.

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

Utforska ElevenAgents plattform för att se hela arbetsflödesbyggaren, eller kontakta säljteamet för att börja bygga ditt första arbetsflöde för en autentiserad röstassistent redan i dag.

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