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 ontwikkeling 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 opvragen of terugbetalingen kan starten, moet deze bellers met dezelfde zorgvuldigheid verifiëren als menselijke callcenters, maar volledig via spraakinteractie. In tegenstelling tot menselijke agents die bedrijfsbeleid volgen, vereisen AI-agents deterministische, toolgebaseerde authenticatie die niet afhankelijk is van het oordeel van een LLM.

Dit artikel beschrijft beproefde authenticatiepatronen uit ons werk als Forward Deployed Engineers bij implementaties voor bedrijven. We behandelen vijf kernbenaderingen, van sessiegebaseerde authenticatie voor ingesloten widgets tot telefoniespecifieke methoden en OTP-verificatie, en leggen uit hoe je elke methode implementeert met deterministische workflowgating op het ElevenLabs-platform.

Het belangrijkste is dat we laten zien waarom authenticatie niet aan conversatie-inferentie kan worden overgelaten. Deze moet in plaats daarvan worden ontworpen met geïsoleerde subagents, toolgebaseerde verificatie en voorwaardelijke workflowroutering, zodat alleen geauthenticeerde gebruikers bevoorrechte bewerkingen bereiken.

Samenvatting

• Bellerverificatie voor spraakagenten moet deterministisch en toolgebaseerd zijn; deze kan niet worden overgelaten aan conversatie-inferentie door 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 verifieert door de beller verstrekte gegevens, zoals een rekeningnummer of geboortedatum, met een backend-systeem via een server-side tool call.
• Telefonie-implementaties kunnen systeem-dynamische variabelen zoals caller ID gebruiken voor stille authenticatie, 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 een 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 blijft authenticatie deterministisch, wordt deze niet aan een beslissing van een LLM overgelaten en kan er zonder geverifieerde identiteit niet worden doorgegaan naar vervolgnodes.

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 draag de gebruiker vervolgens over aan een subagent die deze gegevens gebruikt om met de klant te communiceren en zo 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, waarin authenticatiegegevens worden opgeslagen.

Authenticatie door hostapplicatie

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

Dit zorgt voor een naadloze supportflow, 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 (bijv. <elevenlabs-convai dynamic-variables='{"user_id": "123", "account_tier": "premium"}'>).

Bekijk de documentatie over Dynamic Variables voor de volledige configuratie.

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 (bijv. CRM of identiteitsopslag). De tool retourneert een resultaat voor succes/mislukking met zowel een booleaanse status (is_error) als beschrijvende tekst.

Je kunt dit implementeren via deterministische workflowgating: configureer na het opvragen van de relevante informatie een tool dispatch en gebruik voorwaardelijke transfer edges in de workflow die vertakken op basis van de succes-/mislukkingsstatus van de tool. Zo worden geauthenticeerde gebruikers naar 'bevoorrechte' agentnodes geleid. 

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

Bekijk de documentatie over servertools en dispatch-toolnode 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 wanneer het gesprek begint.

Je kunt er 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 stille authenticatie mogelijk is zonder ze in de prompt te vermelden.

Je kunt bijvoorbeeld een tool configureren om caller ID automatisch door te geven aan je CRM-lookup-endpoint, zodat de agent stilzwijgend kan verifiëren of het binnenkomende 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 opgeslagen nummers toegankelijk kunnen zijn voor onbevoegden, moet authenticatie op basis van caller ID voorafgaande opt-in van de klant vereisen of worden gecombineerd met aanvullende authenticatiemethoden (bijv. kennisgebaseerde vragen).

Raadpleeg voor meer informatie de documentatie over Systeemdynamische variabelen en Initiatiewebhook.

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 juist beantwoordt. Je kunt de agent vragen om willekeurige vragen uit een vooraf gedefinieerde lijst te selecteren (bijv. 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-response met het huidige aantal successen. Met tool assignments wordt dit aantal automatisch geëxtraheerd en opgeslagen of bijgewerkt in een dynamische variabele (bijv. auth_success_count). Na elke succesvolle verificatie wordt de variabele verhoogd.

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

Onze documentatie over edges en flow control bevat meer informatie.

Eenmalige code

Dit is een universele methode waarbij een eenmalige code via sms of e-mail naar het apparaat van de gebruiker wordt verstuurd. De gebruiker moet de code vervolgens aan de agent doorgeven om deze te verifiëren 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 die naar de gebruiker via het voorkeurskanaal (sms of e-mail).
2. Prompt voor gebruiker: De agent vraagt de gebruiker vervolgens om de ontvangen code door te geven. In spraakmodus spreken gebruikers de code hardop uit, die wordt vastgelegd via spraak-naar-tekst.
3. Code verifiëren: De agent verstuurt de door de gebruiker verstrekte code via een tweede tool call naar een backendverificatieservice. De backend valideert dat de code overeenkomt, niet is verlopen en nog niet eerder is gebruikt.
4. Workflowroutering: De agent verwerkt de uitkomst op basis van het verificatieantwoord: Succes: als de code juist is, wordt de gebruiker via een succesvoorwaarde naar het gedeelte 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 (bijv. 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 deze. Overweeg bij spraakinteracties bevestigingsprompts om de nauwkeurigheid van speech-to-text te garanderen bij het vastleggen van codes.

Ga aan de slag met ElevenAgents voor veilige spraakauthenticatie

Deze authenticatiemethoden 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 verwerkt. Dankzij de flexibiliteit van het platform kan je beveiligingsstrategie meegroeien met veranderende dreigingen en toenemende vereisten, waarbij bescherming en gebruikerservaring altijd in balans blijven.

ElevenAgents biedt de hierboven beschreven deterministische workflowgating, 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 veilige flows voor verificatie van de identiteit van bellers