Designa säkra autentiseringsflöden för uppringarens identitet för röstagenter

Voice agents are rapidly evolving from simple FAQ responders to action-taking systems that modify accounts, process transactions, and access sensitive customer data. This shift introduces a critical challenge: How do you verify caller identity in a conversational AI system where traditional visual authentication methods don't exist?

När en röstagent kan uppdatera prenumerationer, hämta kontosaldon eller starta återbetalningar måste den autentisera uppringaren lika noggrant som ett bemannat callcenter – men helt via röst. Till skillnad från mänskliga agenter som följer företagets rutiner kräver AI-agenter deterministisk, verktygsbaserad autentisering som inte bygger på LLM-bedömningar.

Den här artikeln går igenom beprövade autentiseringsmönster från vårt arbete som Forward Deployed Engineers i företagsprojekt. Vi tar upp fem centrala metoder, från sessionsbaserad autentisering för inbäddade widgets till telefonspecifika metoder och OTP-verifiering, och visar hur du implementerar varje metod med deterministisk workflow-styrning på ElevenLabs-plattformen.

Framför allt visar vi varför autentisering inte kan överlåtas till konversationsbaserade gissningar. Istället måste den byggas upp med isolerade subagenter, verktygsbaserad verifiering och villkorad workflow-routing som säkerställer att bara autentiserade användare får åtkomst till känsliga funktioner.

Arkitekturen bakom deterministisk autentisering

För att bara autentiserade användare ska kunna komma åt kontoinformation rekommenderar vi strikt miljö- och åtkomstseparering via ElevenLabs workflows. Autentisering ska alltid göras med ett verktygsanrop som ger ett booleskt resultat (lyckad/misslyckad), konfigurerat som ett dispatch-verktyg i ElevenLabs workflow builder.

Genom att koppla överföringsvillkoret direkt till resultatet från verktygsanropet blir subagenten med åtkomst till kontodata bara tillgänglig efter lyckad autentisering och är helt isolerad från icke-autentiserade användare. Det gör autentiseringen deterministisk, inte beroende av LLM-beslut, och förhindrar att någon går vidare i workflowen utan verifierad identitet.

Som alternativ kan transfer expressions användas som en pålitlig överföringsmetod. Dessa uttryck refererar till dynamiska variabler som uppdateras via verktygsanrop.

Exempel på implementation

Verifiera användaren i Salesforce (verktygsanrop). Om det lyckas, hämta kundens transaktionsdata från Salesforce (ytterligare ett verktygsanrop) och överför sedan användaren till en subagent som använder 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 via serverbaserade verktyg som integreras med ditt CRM eller backend/databas där autentiseringsdata lagras.

Autentisering via värdapplikation

För röstagenter som är inbäddade på en webbplats kan värdapplikationen skicka användarsessionsdata (t.ex. inloggningsstatus, konto-ID eller sessionstoken) via dynamiska variabler när agenten/widgeten startas. Dessa variabler injiceras automatiskt i verktygsanrop med samma dynamiska variabler, så att agenten kan hämta personlig data från integrerade system utan separat autentisering.

Det här ger ett smidigt supportflöde eftersom användaren redan verifierats av värdapplikationen. Du kan sätta upp detta via egen konfiguration eller använda ElevenLabs widget, där du skickar variabler vid körning via widget-konfigurationen (t.ex. <elevenlabs-convai dynamic-variables='{"user_id": "123", "account_tier": "premium"}'>).

Documentation on Dynamic Variables:

• https://www.11labs.ru/docs/agents-platform/customization/personalization/dynamic-variables#pass-variables-at-runtime 

Kunskapsbaserad autentisering (KBA)

Röstagenten ber uppringaren ange autentiseringsdata som kontonummer, postnummer, födelsedatum eller säkerhetssvar. Ett serverbaserat verktyg (webhook eller klientbaserat) verifierar dessa värden mot din databas (t.ex. CRM eller identitetsregister). Verktyget returnerar ett resultat med både booleskt status (is_error) och beskrivande text. Du kan implementera detta med deterministisk workflow-styrning: Efter att ha bett om informationen, konfigurera ett verktygsanrop och använd workflow-villkor som styr vidare beroende på om verktyget lyckas eller misslyckas, så att autentiserade användare slussas vidare till “privilegierade” agentnoder.

Denna metod stöder statiska säkerhetsfrågor och dynamisk "out-of-wallet"-verifiering, beroende på dina krav på bedrägeririsk.

Dokumentation om verktyg:

• https://www.11labs.ru/docs/agents-platform/customization/tools/server-tools 
• https://www.11labs.ru/docs/agents-platform/customization/agent-workflows#dispatch-tool-node 

Systemdynamiska variabler (endast telefoni)

Vid telefonsamtal (via Twilio eller SIP trunk) får agenten automatiskt tillgång till telefonspecifika systemvariabler, inklusive system__caller_id (uppringarens telefonnummer). Den här variabeln fylls i automatiskt när samtalet startar och kan användas på två sätt: 1) I prompts/meddelanden: Referera till dem med dubbla klamrar, t.ex. {{system__caller_id}}, så ersätts de med aktuella 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 så att caller ID automatiskt skickas till ditt CRM för uppslagning, så att agenten tyst kan verifiera om det inkommande numret matchar kundens registrerade nummer för autentisering. Istället för ett verktygsanrop kan autentiseringen också konfigureras som en webhook som körs innan samtalet börjar.

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

Dokumentation om systemdynamiska variabler och initierings-webhook:

• https://www.11labs.ru/docs/agents-platform/customization/personalization/dynamic-variables#system-dynamic-variables 
• https://www.11labs.ru/docs/agents-platform/customization/personalization/twilio-personalization 

Avancerad kunskapsbaserad/säkerhetsfrågeautentisering

Agenten kan autentisera en användare genom att ställa ett antal säkerhetsfrågor och bara ge åtkomst om uppringaren svarar rätt på ett förbestämt antal. Agenten kan instrueras att slumpa frågor från en lista (t.ex. födelsedatum, postnummer, husdjursnamn) och validera svaren via ett verktygsanrop till din databas.

Autentiseringsverktyget returnerar ett JSON-svar som inkluderar nuvarande antal lyckade verifieringar. Med verktygsuppdrag sparas och uppdateras detta antal automatiskt i en dynamisk variabel (t.ex. auth_success_count). Efter varje lyckad verifiering ökar variabeln.

När det krävs antal verifieringar uppnåtts (t.ex. 3), kontrollerar ett workflow-uttryck värdet på den dynamiska variabeln och går vidare till en privilegierad subagent. Uttrycket använder jämförelseoperatorer (t.ex. auth_success_count >= 3) för att deterministiskt styra åtkomst baserat på autentiseringsstatus.

Dokumentation här: https://www.11labs.ru/docs/agents-platform/customization/agent-workflows#edges-and-flow-control 

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 bli verifierad.

Implementationsflöde:

1. Kodgenerering: Agenten startar processen med ett serververktygsanrop till en särskild endpoint. Det här genererar en säker engångskod och skickar den till användaren via önskad kanal (SMS eller e-post).
2. Användaruppmaning: Agenten ber sedan användaren ange koden de fått. I röstläge säger användaren koden högt, som fångas upp via speech-to-text.
3. Kodverifiering: Agenten skickar den angivna koden till en backend-tjänst för verifiering via ett andra verktygsanrop. Backend kontrollerar att koden stämmer, inte har gått ut och inte redan använts.
4. Workflow-routing: Agenten hanterar resultatet utifrån verifieringssvaret: Lyckad: Om koden är rätt går användaren vidare till nästa steg i workflowen via ett lyckat villkor. Misslyckad: Om koden är fel kan agenten be användaren försöka 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, koder bör ha kort giltighetstid (3–5 minuter) och antalet försök ska loggas och begränsas. Vid röstinteraktioner kan det vara bra med bekräftelsefrågor för att säkerställa att speech-to-text tolkat koden rätt.

Sammanfattning

Dessa autentiseringsmetoder är flexibla byggblock, inte färdiga lösningar. Ditt val bör spegla din risknivå, regler och användarupplevelse. En kundtjänstbot kräver annan säkerhet än en bankassistent som hanterar transaktioner. Plattformens flexibilitet gör att din säkerhetsstrategi kan utvecklas i takt med nya hot och ökade krav – alltid med balans mellan skydd och användarupplevelse.