Sichere Anruferauthentifizierung für Voice Agents entwickeln

Voice Agents entwickeln sich rasant von einfachen FAQ-Beantwortern zu Systemen, die Aktionen ausführen, Konten ändern, Transaktionen verarbeiten und auf sensible Kundendaten zugreifen. Dieser Wandel bringt eine zentrale Herausforderung mit sich: Wie authentifizieren Sie die Identität eines Anrufers in einem Conversational-AI-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 mit derselben Sorgfalt authentifizieren wie menschliche Callcenter-Mitarbeiter – jedoch ausschließlich per Sprache. Im Gegensatz zu menschlichen Mitarbeitern, die Unternehmensrichtlinien befolgen, benötigen KI-Agenten eine deterministische, toolbasierte Authentifizierung, die nicht auf der Beurteilung 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 über telefoniespezifische Methoden bis zur OTP-Verifizierung – und erklären, wie Sie jeden davon mit deterministischer Workflow-Steuerung auf der ElevenLabs-Plattform umsetzen.

Vor allem zeigen wir, warum Authentifizierung nicht der Schlussfolgerung aus Gesprächen überlassen werden darf. Stattdessen muss sie durch isolierte Sub-Agenten, toolbasierte Verifizierung und bedingte Workflow-Weiterleitung aufgebaut sein, sodass 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 Schlussfolgerung des LLM aus dem Gespräch überlassen werden.
• Die Authentifizierung über die Host-Anwendung übergibt bestehende Sitzungsdaten an den Agenten, sodass bereits angemeldete Nutzer sich nicht erneut authentifizieren müssen.
• Die wissensbasierte Authentifizierung prüft vom Anrufer angegebene Daten wie Kontonummer oder Geburtsdatum per serverseitigem Tool-Aufruf gegen ein Backend-System.
• Telefonie-Implementierungen können Systemvariablen wie die Anrufer-ID für eine stille Authentifizierung nutzen. Da die Anrufer-ID gefälscht oder geteilt werden kann, sollte dies jedoch mit einem zweiten Faktor kombiniert werden.
• Die Einmalcode-Verifizierung sendet einen Code per SMS oder E-Mail und prüft ihn über einen Backend-Service.

Die Architektur für deterministische Authentifizierung

Um sicherzustellen, dass nur authentifizierte Nutzer auf kontobezogene Informationen zugreifen können, empfehlen wir eine strikte Trennung von Umgebungen und Zugriffsrechten durch ElevenLabs-Workflows. Die Authentifizierung sollte stets über einen Tool-Aufruf mit einem booleschen Ergebnis für Erfolg oder Fehler erfolgen, der im ElevenLabs-Workflow-Builder als Dispatch-Tool konfiguriert ist.

Wenn die Weiterleitungsbedingung direkt mit dem Ergebnis des Tool-Aufrufs verknüpft ist, wird der Sub-Agent mit Zugriff auf Kontodaten erst 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-Ausdrücke als zuverlässige Methode zur Weiterleitung verwendet werden. Diese Ausdrücke verweisen auf dynamische Variablen, die durch Ergebnisse von Tool-Aufrufen aktualisiert werden.

Implementierungsbeispiel

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

Methoden zur Authentifizierung der Nutzeridentität

Diese Authentifizierungsmethoden werden von der ElevenLabs-Plattform nicht nativ unterstützt. Sie können über serverseitige Tools umgesetzt werden, die sich in Ihr CRM oder Backend bzw. Ihre Datenbank integrieren, wo die Authentifizierungsdaten gespeichert sind.

Authentifizierung über die Host-Anwendung

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

Dies ermöglicht einen nahtlosen Support-Ablauf, da der Nutzer bereits durch die Host-Anwendung verifiziert wurde. Sie können dies per benutzerdefinierter Konfiguration einrichten oder das ElevenLabs-Widget verwenden. Dabei übergeben Sie Variablen zur Laufzeit über die Widget-Konfiguration, z. B. <elevenlabs-convai dynamic-variables='{"user_id": "123", "account_tier": "premium"}'>).

Eine vollständige Anleitung finden Sie in der Dokumentation zu dynamischen Variablen.

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, z. B. CRM oder Identitätsspeicher. Das Tool gibt ein Ergebnis für Erfolg oder Fehler zurück, das sowohl einen booleschen Status (is_error) als auch einen beschreibenden Text enthält.

Sie können dies durch deterministische Workflow-Steuerung umsetzen: Konfigurieren Sie nach der Abfrage der relevanten Informationen ein Tool-Dispatch und verwenden Sie bedingte Weiterleitungs-Kanten im Workflow, die anhand des Erfolgs- oder Fehlerstatus des Tools verzweigen und authentifizierte Nutzer an „privilegierte“ Agentenknoten weiterleiten. 

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

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

System-Dynamikvariablen (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 automatisch gefüllt, wenn das Gespräch beginnt.

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 stille 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 still prüfen, ob die eingehende Nummer mit der für die Nutzerauthentifizierung hinterlegten Kundennummer übereinstimmt. Statt eines Tool-Aufrufs kann die Authentifizierung auch als Webhook zur Gesprächsinitiierung konfiguriert werden, der vor Beginn des Gesprächs ausgeführt wird. 

Sicherheitshinweis: Da Anrufer möglicherweise andere Nummern als die hinterlegten verwenden oder gespeicherte Nummern für Unbefugte zugänglich sein können, sollte eine auf der Anrufer-ID basierende Authentifizierung eine vorherige Kundeneinwilligung erfordern oder mit zusätzlichen Authentifizierungsmethoden kombiniert werden, z. B. wissensbasierten Fragen.

Weitere Informationen finden Sie in der Dokumentation zu System-Dynamikvariablen und zum Initiierungs-Webhook.

Erweiterte wissensbasierte Authentifizierung über Sicherheitsfragen

Der Agent kann einen Nutzer authentifizieren, indem er eine Reihe von Sicherheitsfragen stellt und nur Zugriff gewährt, wenn der Anrufer eine vorab definierte 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 per Tool-Aufruf gegen Ihre Datenbank zu prüfen.

Das Authentifizierungstool gibt eine JSON-Antwort zurück, die die aktuelle Anzahl erfolgreicher Prüfungen enthält. Mithilfe von Tool-Zuweisungen wird diese Anzahl automatisch extrahiert und in einer dynamischen Variablen gespeichert bzw. aktualisiert, z. B. auth_success_count. Nach jeder erfolgreichen Verifizierung erhöht sich die Variable.

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

Unsere Dokumentation zu Kanten und Ablaufsteuerung enthält weitere Informationen.

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 dann zur Verifizierung an den Agenten übermitteln, um Zugriff zu erhalten.

Der Implementierungsablauf im Detail:

1. Code-Erstellung: 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 – SMS oder E-Mail – gesendet.
2. Nutzeraufforderung: Der Agent fordert den Nutzer anschließend auf, den erhaltenen Code anzugeben. Im Sprachmodus sprechen Nutzer den Code laut aus; er wird über Speech to Text erfasst.
3. Code-Verifizierung: Der Agent sendet 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 weitergeleitet. Fehler: Ist der Code falsch, kann der Agent den Nutzer auffordern, ihn erneut einzugeben, oder ein Fallback-Verfahren starten, z. B. einen neuen Code senden.

Sicherheitsaspekte: Um Brute-Force-Versuche zu verhindern, sollte Rate Limiting implementiert werden. Codes sollten kurze Ablaufzeiten von 3–5 Minuten haben. Wiederholungsversuche sollten erfasst und begrenzt werden. Erwägen Sie bei Sprachinteraktionen Bestätigungsaufforderungen, um die Genauigkeit von Speech to Text bei der Code-Erfassung sicherzustellen.

Starten Sie mit ElevenAgents für sichere Sprachauthentifizierung

Diese Authentifizierungsmethoden sind flexible Bausteine, keine vorgegebenen 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 stellt sicher, dass sich Ihre Sicherheitsstrategie mit veränderten Bedrohungen und wachsenden Anforderungen weiterentwickeln kann – stets im Gleichgewicht zwischen Schutz und Nutzererfahrung.

ElevenAgents bietet die oben beschriebene deterministische Workflow-Steuerung, Dispatch-Tools und telefoniespezifischen Variablen. So können Sie eine Anruferauthentifizierung entwickeln, die nie von der Beurteilung eines LLM abhängt.

Entdecken Sie die ElevenAgents-Plattform, um den vollständigen Workflow-Builder zu sehen, 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ätsauthentifizierung