Utforma säker uppringarautentisering för röstassistenter

Röstassistenter utvecklas snabbt från enkla svarare på vanliga frågor till system som utför åtgärder, ändrar konton, behandlar transaktioner och får åtkomst till känsliga kunduppgifter. Den här förändringen 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 kontaktcenter, men helt genom röstbaserad interaktion. Till skillnad från mänskliga handläggare som följer företagets policyer kräver AI-assistenter deterministisk, verktygsbaserad autentisering som inte bygger på LLM:ens bedömning.

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

Viktigast av allt visar vi varför autentisering inte kan överlåtas åt samtalsbaserad slutledning. Den måste i stället utformas med isolerade underassistenter, verktygsbaserad verifiering och villkorlig routning i arbetsflödet som säkerställer att endast autentiserade användare når behörighetskrävande åtgärder.

Sammanfattning

• Autentisering av uppringare för röstassistenter måste vara deterministisk och verktygsbaserad; den kan inte överlåtas åt LLM:ens samtalsbaserade slutledning.
• Autentisering i värdapplikationen skickar befintliga sessionsdata till assistenten, så användare som redan är inloggade inte behöver autentisera sig igen.
• Kunskapsbaserad autentisering verifierar uppgifter som uppringaren lämnar, till exempel kontonummer eller födelsedatum, mot ett backend-system via ett verktygsanrop på serversidan.
• Telefonilösningar kan använda dynamiska systemvariabler som nummerpresentation för att autentisera utan att användaren märker det, men detta bör kombineras med en andra faktor eftersom nummerpresentation 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 kan få åtkomst till kontorelaterad information rekommenderar vi en strikt separation av miljöer och åtkomst genom ElevenLabs arbetsflöden. Autentisering bör alltid implementeras med ett verktygsanrop som ger ett booleskt resultat för lyckat eller misslyckat, konfigurerat som ett dispatch-verktyg i ElevenLabs arbetsflödesbyggare.

Genom att koppla överföringsvillkoret direkt till resultatet av verktygsanropet kan underassistenten med åtkomst till kontodata endast nås efter lyckad autentisering och förblir helt isolerad från oautentiserade användare. Det gör autentiseringen deterministisk i stället för att överlåta den åt ett LLM-beslut, och förhindrar att flödet 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å implementering

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

Metoder för autentisering av användaridentitet

Dessa autentiseringsmetoder har inte inbyggt stöd i ElevenLabs-plattformen. 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 eller widgeten initieras. Variablerna injiceras automatiskt i verktygsanrop via samma dynamiska variabler, så att assistenten kan hämta personanpassade data från integrerade system utan att kräva separat autentisering.

Det ger ett smidigt supportflöde eftersom användaren redan har verifierats av värdapplikationen. Du kan konfigurera detta själv eller använda ElevenLabs-widgeten, 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 hela konfigurationen.

Kunskapsbaserad autentisering (KBA) 

Röstassistenten ber uppringaren att ange autentiseringsuppgifter, till exempel kontonummer, postnummer, födelsedatum eller säkerhetssvar. Ett verktyg på serversidan (webhook eller backend-anrop) verifierar uppgifterna mot din databas (t.ex. CRM eller identitetsregister). Verktyget returnerar ett resultat för lyckat/misslyckat som omfattar både en boolesk status (is_error) och beskrivande text.

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

Metoden stödjer både statiska säkerhetsfrågor och dynamisk verifiering av typen ”out-of-wallet”, beroende på dina krav kring bedrägeririsk.

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

Dynamiska systemvariabler (endast telefoni)

För telefonsamtal (via Twilio eller SIP-trunk) har din assistent automatiskt åtkomst till telefonspecifika systemvariabler, inklusive system__caller_id (uppringarens telefonnummer). Variabeln fylls i automatiskt när samtalet börjar.

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 verktygsparametrarna så att de använder dessa variabler, vilket möjliggör tyst autentisering utan att nämna dem i prompten.

Du kan till exempel konfigurera ett verktyg så att det automatiskt skickar nummerpresentationen till en uppslagsslutpunkt i ditt CRM. Då kan assistenten utan att användaren märker det 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 samtal som körs innan samtalet börjar. 

Säkerhetsnotering: Eftersom uppringare kan använda andra nummer än det registrerade, eller registrerade nummer kan vara åtkomliga för obehöriga personer, bör autentisering baserad på nummerpresentation kräva kundens förhandsgodkännande 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

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

Autentiseringsverktyget returnerar ett JSON-svar med det aktuella antalet godkända svar. Med verktygstilldelningar extraheras antalet automatiskt och lagras/uppdateras i en dynamisk variabel (t.ex. auth_success_count). Efter varje lyckad verifiering ökar variabeln.

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

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 dedikerad slutpunkt. Det utlöser genereringen av en säker engångskod som skickas till användaren via den kanal användaren föredrar (SMS eller e-post).
2. Uppmaning till användaren: Assistenten ber sedan användaren att ange koden som hen har fått. I röstläge läser användaren upp koden, som fångas upp via tal-till-text.
3. Kodverifiering: Assistenten skickar koden som användaren angav till en backend-tjänst för verifiering genom ett andra verktygsanrop. Backend-systemet kontrollerar att koden stämmer, inte har löpt ut och inte redan har använts.
4. Routning i arbetsflödet: Assistenten hanterar resultatet utifrån verifieringssvaret: Lyckat: Om koden är korrekt leds användaren till delen av arbetsflödet efter autentiseringen via ett lyckat-villkor. Misslyckat: Om koden är felaktig kan assistenten be användaren att ange den igen eller starta en reservrutin (t.ex. skicka en ny kod).

Säkerhetsaspekter: Implementera hastighetsbegränsning för att förhindra brute force-försök, låt koder ha kort giltighetstid (3–5 minuter) och spåra och begränsa antalet återförsök. Vid röstinteraktioner bör du överväga bekräftelsepromptar 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 återspegla din specifika riskprofil, regelkrav 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 balanseras.

ElevenAgents ger dig den deterministiska styrningen av arbetsflöden, dispatch-verktyg och telefonspecifika variabler som beskrivs ovan, så att du kan skapa autentisering av uppringare som aldrig är beroende av LLM:ens bedömning.

Utforska ElevenAgents-plattformen 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 uppringares identitet