Veilige bellerverificatie voor spraakagenten ontwerpen

Spraakagenten ontwikkelen zich snel van eenvoudige beantwoorders van veelgestelde vragen tot systemen die acties uitvoeren, accounts wijzigen, transacties verwerken en toegang hebben tot gevoelige klantgegevens. Deze verandering brengt een cruciale uitdaging met zich mee: hoe verifieer je de identiteit van een beller in een conversationele AI-systeem waarin traditionele visuele verificatiemethoden niet bestaan?

Wanneer een spraakagent abonnementen kan bijwerken, rekeningsaldi kan ophalen of terugbetalingen kan initiëren, moet deze bellers met dezelfde nauwkeurigheid verifiëren als menselijke callcenters, maar volledig via spraakinteractie. Anders dan menselijke agents die bedrijfsbeleid volgen, hebben AI-agents deterministische, toolgebaseerde authenticatie nodig die niet afhankelijk is van het oordeel van een LLM.

In dit artikel bespreken we bewezen authenticatiepatronen uit ons werk als Forward Deployed Engineers bij enterprise-implementaties. We behandelen vijf kernbenaderingen, van sessiegebaseerde authenticatie voor ingebedde widgets tot telefoniespecifieke methoden en OTP-verificatie, en leggen uit hoe je ze implementeert met deterministische workflow gating op het ElevenLabs-platform.

Het belangrijkste is dat we laten zien waarom authenticatie niet aan conversationele gevolgtrekkingen kan worden overgelaten. In plaats daarvan moet deze worden ontworpen met geïsoleerde subagents, toolgebaseerde verificatie en voorwaardelijke workflowroutering, zodat alleen geauthenticeerde gebruikers toegang krijgen tot bevoorrechte bewerkingen.

Samenvatting

• Bellerverificatie voor spraakagenten moet deterministisch en toolgebaseerd zijn; deze kan niet worden overgelaten aan conversationele gevolgtrekkingen van de LLM.
• Authenticatie door de hostapplicatie geeft bestaande sessiegegevens door aan de agent, zodat gebruikers die al zijn ingelogd zich niet opnieuw hoeven te authenticeren.
• Kennisgebaseerde authenticatie controleert gegevens die de beller verstrekt, zoals een rekeningnummer of geboortedatum, aan de hand van een backendsysteem via een server-side tool call.
• Telefonie-implementaties kunnen systeem-dynamische variabelen zoals caller ID gebruiken om stilzwijgend te authenticeren, maar dit moet worden gecombineerd met een tweede factor omdat caller ID kan worden vervalst of gedeeld.
• Verificatie met een eenmalige code verstuurt een code via sms of e-mail en valideert deze via een backendservice.

De architecturale basis voor deterministische authenticatie

Om ervoor te zorgen dat alleen geauthenticeerde gebruikers toegang hebben tot accountgerelateerde informatie, raden we strikte scheiding van omgevingen en toegang aan via de workflows van ElevenLabs. Authenticatie moet altijd worden geïmplementeerd met een tool call met een booleaanse uitvoer voor succes of mislukking, geconfigureerd als dispatch tool in de ElevenLabs-workflowbuilder.

Door de overdrachtsvoorwaarde rechtstreeks te koppelen aan het resultaat van de tool call, is de subagent met toegang tot accountgegevens alleen bereikbaar na succesvolle authenticatie en blijft deze volledig geïsoleerd van niet-geauthenticeerde gebruikers. Zo is authenticatie deterministisch, wordt deze niet overgelaten aan een beslissing van een LLM en wordt voortgang naar vervolgnodes zonder geverifieerde identiteit voorkomen.

Als alternatief kun je transfer expressions gebruiken als betrouwbare overdrachtsmethode. Deze expressies verwijzen naar dynamische variabelen die worden bijgewerkt via resultaten van tool calls.

Voorbeeldimplementatie

Verifieer de gebruiker in Salesforce (tool call). Haal bij succes klanttransactiegegevens op uit Salesforce (nog een tool call) en stuur de gebruiker vervolgens door naar een subagent die deze gegevens gebruikt om met de klant te communiceren en indien nodig andere acties uit te voeren.

Methoden voor authenticatie van gebruikersidentiteit

Deze authenticatiemethoden worden niet standaard ondersteund in het ElevenLabs-platform. Je kunt ze implementeren via server-side tools die integreren met je CRM of backend/database, waar authenticatiegegevens worden opgeslagen.

Authenticatie door de hostapplicatie

Voor spraakagenten die in een website zijn ingebed, kan de hostapplicatie bij het initialiseren van de agent/widget sessiegegevens van gebruikers (zoals inlogstatus, account-ID of sessietokens) doorgeven via dynamische variabelen. Deze variabelen worden automatisch in tool calls ingevoegd met dezelfde dynamische variabelen, zodat de agent gepersonaliseerde gegevens uit geïntegreerde systemen kan ophalen zonder afzonderlijke authenticatie.

Dit maakt een naadloze supportflow mogelijk, omdat de gebruiker al door de hostapplicatie is geverifieerd. Je kunt dit instellen via een aangepaste configuratie of de ElevenLabs-widget gebruiken, waarin je tijdens runtime variabelen doorgeeft via de widgetconfiguratie (bijvoorbeeld <elevenlabs-convai dynamic-variables='{"user_id": "123", "account_tier": "premium"}'>).

Bekijk de documentatie over Dynamic Variables voor de volledige installatie.

Kennisgebaseerde authenticatie (KBA) 

De spraakagent vraagt de beller om authenticatiegegevens te verstrekken, zoals een rekeningnummer, postcode, geboortedatum of antwoorden op beveiligingsvragen. Een server-side tool (webhook of backend call) controleert deze waarden aan de hand van je database (bijvoorbeeld CRM of identiteitsregister). De tool retourneert een resultaat voor succes/mislukking met zowel een booleaanse status (is_error) als beschrijvende tekst.

Je kunt dit implementeren via deterministische workflow gating: vraag eerst de relevante informatie op, configureer vervolgens een tool dispatch en gebruik voorwaardelijke transfer edges in de workflow die vertakken op basis van de succes-/mislukkingsstatus van de tool. Zo stuur je geauthenticeerde gebruikers naar “bevoorrechte” agentnodes. 

Deze aanpak ondersteunt statische beveiligingsvragen en dynamische verificatie in de stijl van "out-of-wallet", afhankelijk van je vereisten voor frauderisico.

Bekijk de documentatie over server tools en de dispatch tool node voor agent workflows voor meer informatie.

Systeem-dynamische variabelen (alleen telefonie)

Voor telefoongesprekken (via Twilio of SIP trunk) heeft je agent automatisch toegang tot telefoniespecifieke systeemvariabelen, waaronder system__caller_id (het telefoonnummer van de beller). Deze variabele wordt automatisch ingevuld zodra het gesprek begint.

Je kunt hier op twee manieren naar verwijzen:

1. In prompts/berichten: Verwijs ernaar met dubbele accolades, bijvoorbeeld {{system__caller_id}}; deze worden vervangen door de werkelijke waarden.
2. In toolparameters: Configureer toolparameters om deze variabelen te gebruiken, zodat stilzwijgende authenticatie mogelijk is zonder ze in de prompt te noemen.

Je kunt bijvoorbeeld een tool configureren om de caller ID automatisch door te geven aan het lookup-endpoint van je CRM. Zo kan de agent stilzwijgend controleren of het inkomende nummer overeenkomt met het geregistreerde nummer van de klant voor gebruikersauthenticatie. In plaats van een tool call kun je de authenticatie ook configureren als een webhook voor gespreksinitiatie die wordt uitgevoerd voordat het gesprek begint. 

Beveiligingsopmerking: Omdat bellers mogelijk andere nummers gebruiken dan de nummers die geregistreerd staan, of omdat opgeslagen nummers toegankelijk kunnen zijn voor onbevoegde personen, moet authenticatie op basis van caller ID voorafgaande opt-in van de klant vereisen of worden gecombineerd met aanvullende authenticatiemethoden (bijvoorbeeld kennisgebaseerde vragen).

Raadpleeg voor meer informatie de documentatie over System Dynamic Variables en Initiation webhook.

Geavanceerde kennisgebaseerde authenticatie / authenticatie met beveiligingsvragen

De agent kan een gebruiker authenticeren door een reeks beveiligingsvragen te stellen en alleen toegang te verlenen als de beller een vooraf bepaald aantal vragen correct beantwoordt. Je kunt de agent vragen willekeurige vragen uit een vooraf gedefinieerde lijst te kiezen (bijvoorbeeld geboortedatum, postcode, naam van huisdier) en de antwoorden van de beller te valideren via een tool call naar je database.

De authenticatietool retourneert een JSON-respons met daarin het huidige aantal geslaagde verificaties. Met tool assignments wordt dit aantal automatisch geëxtraheerd en opgeslagen/bijgewerkt in een dynamische variabele (bijvoorbeeld auth_success_count). Na elke succesvolle verificatie wordt de variabele verhoogd.

Zodra het vereiste aantal verificaties is bereikt (bijvoorbeeld 3), controleert een workflow expression condition de waarde van de dynamische variabele en gaat deze over naar een bevoorrechte subagentnode. De expressie gebruikt vergelijkingsoperatoren (bijvoorbeeld auth_success_count >= 3) om de toegang deterministisch te beperken op basis van de authenticatiestatus.

Onze documentatie over edges en flow control bevat meer informatie die je kunt raadplegen.

Eenmalige code

Dit is een universele methode waarbij een eenmalige code via sms of e-mail naar het apparaat van de gebruiker wordt gestuurd. De gebruiker moet de code vervolgens aan de agent doorgeven om geverifieerd te worden en toegang te krijgen.

Hier volgt de implementatieworkflow in meer detail:

1. Code genereren: De agent start het proces met een server tool call naar een speciaal endpoint. Deze actie genereert een veilige eenmalige code en stuurt deze via het voorkeurskanaal van de gebruiker (sms of e-mail).
2. Prompt voor de gebruiker: De agent vraagt de gebruiker vervolgens om de ontvangen code door te geven. In de spraakmodus spreken gebruikers de code hardop uit; deze wordt vastgelegd via speech-to-text.
3. Code verifiëren: De agent stuurt de door de gebruiker verstrekte code met een tweede tool call naar een backendverificatieservice. De backend controleert of de code overeenkomt, niet is verlopen en nog niet is gebruikt.
4. Workflowroutering: De agent handelt de uitkomst af op basis van de verificatierespons: succes: als de code correct is, wordt de gebruiker via een succesvoorwaarde naar het deel van de workflow na authenticatie geleid. Mislukking: als de code onjuist is, kan de agent de gebruiker vragen de code opnieuw in te voeren of een fallbackprocedure starten (bijvoorbeeld een nieuwe code versturen).

Beveiligingsoverwegingen: implementeer rate limiting om brute-forcepogingen te voorkomen, geef codes een korte vervaltijd (3-5 minuten) en houd nieuwe pogingen bij en beperk ze. Overweeg bij spraakinteracties bevestigingsprompts om de nauwkeurigheid van speech-to-text bij het vastleggen van codes te garanderen.

Ga aan de slag met ElevenAgents voor veilige spraakauthenticatie

Deze verificatiemethoden zijn flexibele bouwstenen, geen voorgeschreven oplossingen. Je keuze moet aansluiten bij je specifieke risicoprofiel, wettelijke vereisten en doelen voor de gebruikerservaring. Een klantenservicebot heeft andere beveiliging nodig dan een bankassistent die transacties afhandelt. Dankzij de flexibiliteit van het platform kan je beveiligingsstrategie meegroeien naarmate bedreigingen veranderen en vereisten toenemen, waarbij bescherming en gebruikerservaring altijd in balans blijven.

ElevenAgents biedt de hierboven beschreven deterministische workflow gating, dispatch tools en telefoniespecifieke variabelen, zodat je bellerverificatie kunt bouwen die nooit afhankelijk is van het oordeel van een LLM.

Verken het ElevenAgents-platform om de volledige workflowbuilder te bekijken, of neem contact op met sales om vandaag te beginnen met het bouwen van je eerste workflow voor een geauthenticeerde spraakagent.

Veelgestelde vragen over flows voor veilige authenticatie van belleridentiteit