Sichere Anruferauthentifizierung für Voice Agents entwickeln

Voice Agents entwickeln sich schnell von einfachen FAQ-Beantwortern zu Systemen, die Aktionen ausführen, Konten ändern, Transaktionen verarbeiten und auf sensible Kundendaten zugreifen. Dieser Wandel bringt eine entscheidende Herausforderung mit sich: Wie authentifizieren Sie die Identität eines Anrufers in einem dialogorientierten KI-System, in dem herkömmliche visuelle Verifizierungsmethoden nicht verfügbar sind?

Wenn ein Voice Agent Abonnements aktualisieren, Kontostände abrufen oder Rückerstattungen veranlassen kann, muss er Anrufer genauso sorgfältig authentifizieren wie menschliche Callcenter – aber ausschließlich per Sprache. Im Gegensatz zu menschlichen Mitarbeitenden, die Unternehmensrichtlinien befolgen, benötigen KI-Agenten eine deterministische, toolbasierte Authentifizierung, die nicht auf der Einschätzung eines LLM beruht.

Dieser Artikel beschreibt bewährte Authentifizierungsmuster aus unserer Arbeit als Forward Deployed Engineers bei Enterprise-Implementierungen. Wir behandeln fünf zentrale Ansätze – von sitzungsbasierter Authentifizierung für eingebettete Widgets bis zu telefoniespezifischen Methoden und OTP-Verifizierung – und erklären, wie Sie jeden davon mit deterministischer Workflow-Steuerung auf der ElevenLabs-Plattform umsetzen.

Am wichtigsten ist: Authentifizierung darf nicht der Interpretation eines Gesprächs überlassen werden. Stattdessen muss sie über isolierte Sub-Agents, toolbasierte Verifizierung und bedingte Workflow-Weiterleitung umgesetzt werden, damit nur authentifizierte Nutzer auf privilegierte Vorgänge zugreifen können.

Zusammenfassung

• Die Anruferauthentifizierung für Voice Agents muss deterministisch und toolbasiert sein; sie darf nicht der Gesprächsinterpretation durch das LLM überlassen werden.
• Bei der Authentifizierung über die Host-Anwendung werden vorhandene Sitzungsdaten an den Agent übergeben, sodass bereits angemeldete Nutzer sich nicht erneut authentifizieren müssen.
• Die wissensbasierte Authentifizierung prüft vom Anrufer angegebene Daten wie Kontonummer oder Geburtsdatum über einen serverseitigen Tool-Aufruf mit einem Backend-System ab.
• Telefonie-Implementierungen können System-Dynamic-Variables wie die Anrufer-ID zur unauffälligen Authentifizierung verwenden. Da Anrufer-IDs manipuliert oder geteilt werden können, sollte dies mit einem zweiten Faktor kombiniert werden.
• Die Einmalcode-Verifizierung sendet einen Code per SMS oder E-Mail und validiert ihn über einen Backend-Service.

Die architektonische Grundlage für deterministische Authentifizierung

Damit nur authentifizierte Nutzer auf kontobezogene Informationen zugreifen können, empfehlen wir eine strikte Trennung von Umgebungen und Zugriffen über ElevenLabs-Workflows. Die Authentifizierung sollte immer über einen Tool-Aufruf mit einem booleschen Erfolgs- oder Fehlerergebnis erfolgen, der im ElevenLabs Workflow Builder als Dispatch Tool konfiguriert ist.

Wenn Sie die Weiterleitungsbedingung direkt mit dem Ergebnis des Tool-Aufrufs verknüpfen, ist der Sub-Agent mit Zugriff auf Kontodaten nur nach erfolgreicher Authentifizierung erreichbar und bleibt vollständig von nicht authentifizierten Nutzern isoliert. So bleibt die Authentifizierung deterministisch, wird nicht einer LLM-Entscheidung überlassen und verhindert ohne verifizierte Identität jeden Übergang zu nachgelagerten Knoten.

Alternativ können Transfer Expressions als zuverlässige Methode zur Weiterleitung verwendet werden. Diese Ausdrücke referenzieren dynamische Variablen, die durch Ergebnisse von Tool-Aufrufen aktualisiert werden.

Beispielimplementierung

Verifizieren Sie den Nutzer in Salesforce (Tool-Aufruf). Rufen Sie bei Erfolg die Transaktionsdaten des Kunden aus Salesforce ab (ein weiterer Tool-Aufruf) und leiten Sie den Nutzer anschließend an einen Sub-Agent weiter, der diese Daten zur Kommunikation mit dem Kunden und bei Bedarf für weitere Aktionen verwendet.

Methoden zur Authentifizierung der Nutzeridentität

Diese Authentifizierungsmethoden werden von der ElevenLabs-Plattform nicht nativ unterstützt. Sie können über serverseitige Tools implementiert werden, die mit Ihrem CRM oder Backend bzw. Ihrer Datenbank integriert sind, in denen die Authentifizierungsdaten gespeichert werden.

Authentifizierung über die Host-Anwendung

Bei Voice Agents, die in eine Website eingebettet sind, kann die Host-Anwendung beim Initialisieren des Agents oder Widgets Nutzersitzungsdaten wie Anmeldestatus, Konto-ID oder Sitzungstokens über dynamische Variablen übergeben. Diese Variablen werden automatisch in Tool-Aufrufe eingefügt und ermöglichen dem Agent, personalisierte Daten aus integrierten Systemen abzurufen, ohne eine separate Authentifizierung zu verlangen.

Das ermöglicht einen nahtlosen Supportablauf, da die Host-Anwendung den Nutzer bereits verifiziert hat. Sie können dies über eine benutzerdefinierte Konfiguration einrichten oder das ElevenLabs-Widget verwenden, bei dem Sie Variablen zur Laufzeit über die Widget-Konfiguration übergeben (z. B. <elevenlabs-convai dynamic-variables='{"user_id": "123", "account_tier": "premium"}'>).

Die vollständige Einrichtung finden Sie in der Dokumentation zu Dynamic Variables.

Wissensbasierte Authentifizierung (KBA)

Der Voice Agent fordert den Anrufer auf, Authentifizierungsdaten wie Kontonummer, Postleitzahl, Geburtsdatum oder Antworten auf Sicherheitsfragen anzugeben. Ein serverseitiges Tool (Webhook oder Backend-Aufruf) prüft diese Werte gegen Ihre Datenbank, etwa ein CRM oder einen Identitätsspeicher. Das Tool gibt ein Erfolgs- oder Fehlerergebnis zurück, das sowohl einen booleschen Status (is_error) als auch beschreibenden Text enthält.

Sie können dies mit deterministischer Workflow-Steuerung umsetzen: Nachdem die relevanten Informationen abgefragt wurden, konfigurieren Sie einen Tool-Dispatch und verwenden bedingte Weiterleitungskanten im Workflow, die anhand des Erfolgs- oder Fehlerstatus des Tools verzweigen und authentifizierte Nutzer an „privilegierte“ Agent-Knoten weiterleiten.

Je nach Ihren Anforderungen an das Betrugsrisiko unterstützt dieser Ansatz statische Sicherheitsfragen und dynamische Verifizierung im „Out-of-Wallet“-Stil.

Weitere Details finden Sie in der Dokumentation zu Server Tools und zum Dispatch-Tool-Knoten für Agent-Workflows.

System-Dynamic-Variables (nur Telefonie)

Bei telefongestützten Gesprächen über Twilio oder einen SIP-Trunk hat Ihr Agent automatisch Zugriff auf telefoniespezifische Systemvariablen, einschließlich system__caller_id (der Telefonnummer des Anrufers). Diese Variable wird beim Start des Gesprächs automatisch befüllt.

Sie können darauf auf zwei Arten verweisen:

1. In Prompts/Nachrichten: Verwenden Sie doppelte geschweifte Klammern, z. B. {{system__caller_id}}. Sie werden durch die tatsächlichen Werte ersetzt.
2. In Tool-Parametern: Konfigurieren Sie Tool-Parameter so, dass sie diese Variablen verwenden. Das ermöglicht eine unauffällige Authentifizierung, ohne sie im Prompt zu erwähnen.

Sie können beispielsweise ein Tool so konfigurieren, dass es die Anrufer-ID automatisch an den Lookup-Endpunkt Ihres CRM übergibt. So kann der Agent unauffällig prüfen, ob die eingehende Nummer zur beim Kunden hinterlegten Nummer für die Nutzerauthentifizierung passt. Statt über einen Tool-Aufruf kann die Authentifizierung auch als Webhook zur Gesprächsinitiierung konfiguriert werden, der vor Beginn des Gesprächs ausgeführt wird.

Sicherheitshinweis: Da Anrufer andere als die hinterlegten Nummern verwenden können oder gespeicherte Nummern unbefugten Personen zugänglich sein können, sollte eine auf der Anrufer-ID basierende Authentifizierung eine vorherige Kundeneinwilligung erfordern oder mit zusätzlichen Authentifizierungsmethoden wie wissensbasierten Fragen kombiniert werden.

Weitere Informationen finden Sie in der Dokumentation zu System Dynamic Variables und zum Initiation Webhook.

Erweiterte wissensbasierte Authentifizierung mit Sicherheitsfragen

Der Agent kann einen Nutzer authentifizieren, indem er mehrere Sicherheitsfragen stellt und nur Zugriff gewährt, wenn der Anrufer eine vordefinierte Anzahl korrekt beantwortet. Der Agent kann angewiesen werden, zufällige Fragen aus einer vordefinierten Liste auszuwählen, etwa Geburtsdatum, Postleitzahl oder Name des Haustiers, und die Antworten des Anrufers über einen Tool-Aufruf mit Ihrer Datenbank abzugleichen.

Das Authentifizierungstool gibt eine JSON-Antwort mit der aktuellen Anzahl erfolgreicher Prüfungen zurück. Mithilfe von Tool Assignments wird diese Anzahl automatisch extrahiert und in einer dynamischen Variable gespeichert oder aktualisiert, etwa auth_success_count. Nach jeder erfolgreichen Verifizierung wird die Variable erhöht.

Sobald die erforderliche Anzahl an Verifizierungen erreicht ist, z. B. 3, prüft eine Workflow-Expressionsbedingung den Wert der dynamischen Variable und wechselt zu einem privilegierten Sub-Agent-Knoten. Der Ausdruck verwendet Vergleichsoperatoren wie auth_success_count >= 3, um den Zugriff anhand des Authentifizierungsstatus deterministisch zu steuern.

Weitere Informationen finden Sie in unserer Dokumentation zu Kanten und Ablaufsteuerung.

Einmalcode

Bei dieser universellen Methode wird ein Einmalcode per SMS oder E-Mail an das Gerät des Nutzers gesendet. Der Nutzer muss den Code dem Agent zur Verifizierung mitteilen, um Zugriff zu erhalten.

Der Implementierungsablauf im Detail:

1. Codegenerierung: Der Agent startet den Prozess mit einem serverseitigen Tool-Aufruf an einen dedizierten Endpunkt. Dadurch wird ein sicherer Einmalcode generiert und über den bevorzugten Kanal des Nutzers versendet, per SMS oder E-Mail.
2. Nutzerabfrage: Der Agent fordert den Nutzer dann auf, den erhaltenen Code anzugeben. Im Sprachmodus sprechen Nutzer den Code laut aus, der per Speech to Text erfasst wird.
3. Codeverifizierung: Der Agent übermittelt den vom Nutzer angegebenen Code über einen zweiten Tool-Aufruf an einen Backend-Verifizierungsdienst. Das Backend prüft, ob der Code übereinstimmt, nicht abgelaufen ist und noch nicht verwendet wurde.
4. Workflow-Weiterleitung: Der Agent verarbeitet das Ergebnis anhand der Verifizierungsantwort: Erfolg: Ist der Code korrekt, wird der Nutzer über eine Erfolgsbedingung zum Teil des Workflows nach der Authentifizierung geleitet. Fehler: Ist der Code falsch, kann der Agent den Nutzer auffordern, ihn erneut einzugeben, oder ein Fallback-Verfahren starten, etwa einen neuen Code senden.

Sicherheitsaspekte: Um Brute-Force-Versuche zu verhindern, sollte Rate Limiting implementiert werden. Codes sollten nur kurz gültig sein, etwa 3–5 Minuten, und Wiederholungsversuche sollten erfasst und begrenzt werden. Bei Sprachinteraktionen sollten Sie Bestätigungsabfragen erwägen, um die Genauigkeit von Speech to Text bei der Codeerfassung sicherzustellen.

Starten Sie mit ElevenAgents für sichere Sprachauthentifizierung

Diese Authentifizierungsmethoden sind flexible Bausteine, keine vorgeschriebenen Lösungen. Ihre Wahl sollte Ihr spezifisches Risikoprofil, regulatorische Anforderungen und Ziele für die Nutzererfahrung berücksichtigen. Ein Kundenservice-Bot benötigt andere Sicherheitsmaßnahmen als ein Banking-Assistent, der Transaktionen verarbeitet. Die Flexibilität der Plattform sorgt dafür, dass sich Ihre Sicherheitsstrategie an veränderte Bedrohungen und wachsende Anforderungen anpassen kann und dabei Schutz und Nutzererfahrung ausbalanciert.

ElevenAgents bietet die oben beschriebene deterministische Workflow-Steuerung, Dispatch Tools und telefoniespezifische Variablen. Damit können Sie eine Anruferauthentifizierung entwickeln, die niemals von der Einschätzung eines LLM abhängt.

Entdecken Sie die ElevenAgents-Plattform mit dem vollständigen Workflow Builder oder kontaktieren Sie den Vertrieb, um noch heute Ihren ersten Workflow für einen authentifizierten Voice Agent zu entwickeln.

FAQ zu sicheren Abläufen für die Anruferidentitätsprüfung