Utforma säker uppringarautentisering för röstassistenter

Röstassistenter utvecklas snabbt från enkla FAQ-svarare till system som utför åtgärder, ändrar konton, behandlar transaktioner och får åtkomst till känsliga kunduppgifter. Detta medför en avgörande utmaning: Hur autentiserar du en uppringares identitet i ett Conversational AI-system där traditionella visuella verifieringsmetoder inte finns?

När en röstassistent kan uppdatera prenumerationer, hämta kontosaldon eller initiera återbetalningar måste den autentisera uppringare med samma noggrannhet som mänskliga kundtjänstcenter, men helt via röstbaserad interaktion. Till skillnad från mänskliga agenter som följer företagets riktlinjer kräver AI-agenter 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 telefonianspassade metoder och OTP-verifiering, och förklarar hur du implementerar dem med deterministisk workflow-styrning på ElevenLabs-plattformen.

Framför allt visar vi varför autentisering inte kan överlåtas åt slutledningar i konversationen. I stället måste den utformas med isolerade underagenter, verktygsbaserad verifiering och villkorlig workflow-routning 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 tolkning av konversationen.
• Autentisering via värdapplikationen 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 lämnar, exempelvis 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 i bakgrunden, men 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 komma åt kontorelaterad information rekommenderar vi strikt separering av miljöer och åtkomst genom ElevenLabs workflows. 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 workflow-byggare.

Genom att koppla överföringsvillkoret direkt till resultatet av verktygsanropet blir underagenten med åtkomst till kontodata endast tillgänglig efter lyckad autentisering och förblir helt isolerad från oautentiserade användare. Det säkerställer att autentiseringen är deterministisk, 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 hänvisar till dynamiska variabler som uppdateras via resultat från verktygsanrop.

Exempel på implementering

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 underagent som ansvarar för att använda uppgifterna för att kommunicera med kunden och utföra andra åtgärder vid behov.

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 via värdapplikationen

För röstassistenter som är inbäddade på en webbplats kan värdapplikationen skicka användarens sessionsdata, som inloggningsstatus, konto-ID eller sessionstoken, via dynamiska variabler när agenten/widgeten initieras. Variablerna infogas automatiskt i verktygsanrop med samma dynamiska variabler, så 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ä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 fullständiga instruktioner.

Kunskapsbaserad autentisering (KBA) 

Röstassistenten ber uppringaren lämna autentiseringsuppgifter, till exempel kontonummer, postnummer, födelsedatum eller svar på säkerhetsfrågor. Ett verktyg på serversidan (webhook eller backend-anrop) verifierar uppgifterna mot din databas, exempelvis ett CRM-system 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 med deterministisk workflow-styrning: Efter att du har begärt den relevanta informationen konfigurerar du ett verktygsanrop och använder villkorliga överföringskanter i workflowet som förgrenas utifrån verktygets lyckade/misslyckade status och leder autentiserade användare till agentnoder med utökad behörighet. 

Metoden stöder 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-verktygsnod för agent-workflows för mer information.

Dynamiska systemvariabler (endast telefoni)

För telefonsamtal (via Twilio eller SIP-trunk) har din agent automatiskt åtkomst till telefonianspassade 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 prompts/meddelanden: Referera till dem med dubbla klammerparenteser, 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 och möjliggör autentisering i bakgrunden utan att nämna dem i prompten.

Du kan till exempel konfigurera ett verktyg så att det automatiskt skickar nummerpresentationen till slutpunkten för CRM-sökning, vilket låter agenten i bakgrunden verifiera om det inkommande numret matchar kundens registrerade nummer för användarautentisering. I stället för ett verktygsanrop kan autentiseringen även konfigureras som en webhook för konversationsinitiering som körs innan konversationen börjar. 

Säkerhetsnotering: Eftersom uppringare kan använda andra nummer än de som finns registrerade, eller registrerade nummer kan vara åtkomliga för obehöriga, bör autentisering baserad på nummerpresentation kräva kundens samtycke i förväg eller kombineras med ytterligare autentiseringsmetoder, exempelvis 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 ett antal säkerhetsfrågor och bevilja åtkomst endast 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, till exempel födelsedatum, postnummer eller husdjurets namn, och validera uppringarens svar via ett verktygsanrop till din databas.

Autentiseringsverktyget returnerar ett JSON-svar med aktuellt antal lyckade verifieringar. Med verktygstilldelningar extraheras antalet automatiskt och lagras/uppdateras i en dynamisk variabel, till exempel auth_success_count. Variabeln ökar efter varje lyckad verifiering.

När det nödvändiga antalet verifieringar har uppnåtts, till exempel 3, kontrollerar ett villkor i ett workflow-uttryck den dynamiska variabelns värde och övergår till en underagentnod med utökad behörighet. Uttrycket använder jämförelseoperatorer, till exempel auth_success_count >= 3, för att deterministiskt styra åtkomsten 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 agenten för att verifieras och få åtkomst.

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 önskad kanal, SMS eller e-post.
2. Uppmaning till användaren: Agenten ber sedan användaren att uppge koden som hen fick. I röstläge säger användaren koden högt, och den registreras med tal-till-text.
3. Kodverifiering: Agenten skickar koden som användaren har angett till en backend-tjänst för verifiering med ett andra verktygsanrop. Backend-systemet validerar att koden stämmer, inte har gått ut och inte redan har använts.
4. Workflow-routning: Agenten hanterar resultatet utifrån verifieringssvaret: Lyckat: Om koden är korrekt leds användaren till delen av workflowet efter autentisering via ett villkor för lyckat resultat. Misslyckat: Om koden är felaktig kan agenten be användaren att ange den igen eller starta en reservprocedur, till exempel skicka en ny kod.

Säkerhetsaspekter: Implementera hastighetsbegränsning för att förhindra brute force-försök, ge koder kort giltighetstid (3–5 minuter) och spåra och begränsa antalet nya försök. För röstinteraktioner bör du överväga bekräftelseprompter för att säkerställa tal-till-text-precision när koder registreras.

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 hoten förändras och kraven ökar, samtidigt som du alltid balanserar skydd och användarupplevelse.

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

Utforska ElevenAgents-plattformen för att se hela workflow-byggaren, eller kontakta säljteamet för att börja bygga ditt första workflow för en autentiserad röstassistent redan i dag.

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