Sichere Anruferauthentifizierung für Voice Agents entwickeln
- Veröffentlicht
- Zuletzt aktualisiert
AnhörenArtikel anhören
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 genauso streng authentifizieren wie menschliche Callcenter – jedoch ausschließlich per Sprache. Anders als menschliche Mitarbeitende, die Unternehmensrichtlinien befolgen, benötigen KI-Agenten eine deterministische, toolbasierte Authentifizierung, die nicht auf der Beurteilung durch ein LLM beruht.
Dieser Artikel beschreibt bewährte Authentifizierungsmuster aus unserer Arbeit als Forward Deployed Engineers in Unternehmensimplementierungen. Wir behandeln fünf zentrale Ansätze – von sitzungsbasierter Authentifizierung für eingebettete Widgets über telekommunikationsspezifische Methoden bis zur OTP-Verifizierung – und erklären, wie Sie jeden davon mit deterministischer Workflow-Steuerung auf der ElevenLabs-Plattform umsetzen.
Am wichtigsten ist: Wir zeigen, warum Authentifizierung nicht der Schlussfolgerung aus einem Gespräch überlassen werden darf. Stattdessen muss sie über isolierte Sub-Agenten, toolbasierte Verifizierung und bedingte Workflow-Weiterleitungen aufgebaut sein, damit nur authentifizierte Nutzer privilegierte Vorgänge erreichen.
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. Bereits angemeldete Nutzer müssen sich somit nicht erneut authentifizieren.
- Die wissensbasierte Authentifizierung prüft vom Anrufer angegebene Daten wie Kontonummer oder Geburtsdatum über einen serverseitigen Tool-Aufruf gegen ein Backendsystem.
- Telekommunikationsimplementierungen können zur stillen Authentifizierung dynamische Systemvariablen wie die Anrufer-ID verwenden. Da die Anrufer-ID jedoch gefälscht oder geteilt werden kann, sollte dies mit einem zweiten Faktor kombiniert werden.
- Bei der Einmalcode-Verifizierung wird ein Code per SMS oder E-Mail versendet und über einen Backend-Service validiert.
Die Architekturgrundlage für deterministische Authentifizierung
Damit nur authentifizierte Nutzer auf kontobezogene Informationen zugreifen können, empfehlen wir eine strikte Trennung von Umgebungen und Zugriffsrechten über ElevenLabs-Workflows. Die Authentifizierung sollte immer mit einem Tool-Aufruf umgesetzt werden, der einen booleschen Erfolgs- oder Fehlerwert ausgibt und im ElevenLabs-Workflow-Builder als Dispatch-Tool konfiguriert ist.
Indem Sie die Weiterleitungsbedingung direkt mit dem Ergebnis des Tool-Aufrufs verknüpfen, ist der Sub-Agent mit Zugriff auf Kontodaten erst nach erfolgreicher Authentifizierung erreichbar und bleibt vollständig von nicht authentifizierten Nutzern isoliert. Dadurch ist die Authentifizierung deterministisch, nicht von einer LLM-Entscheidung abhängig, und ein Übergang zu nachgelagerten Knoten ohne verifizierte Identität wird verhindert.
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.
Beispielimplementierung
Verifizieren Sie den Nutzer in Salesforce (Tool-Aufruf). Rufen Sie bei Erfolg die Kundentransaktionsdaten aus Salesforce ab (ein weiterer Tool-Aufruf) und leiten Sie den Nutzer dann an einen Sub-Agenten 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 auf 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 Agenten oder Widgets Nutzersitzungsdaten wie Anmeldestatus, Konto-ID oder Sitzungstokens über dynamische Variablen übergeben. Diese Variablen werden mithilfe derselben dynamischen Variablen automatisch in Tool-Aufrufe eingefügt. So kann der Agent personalisierte Daten aus integrierten Systemen abrufen, ohne eine separate Authentifizierung zu benötigen.
Das ermöglicht einen nahtlosen Support-Ablauf, da der Nutzer bereits von der Host-Anwendung verifiziert wurde. 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"}'>).
Weitere Informationen zur vollständigen Einrichtung finden Sie in der Dokumentation zu dynamischen Variablen.
Wissensbasierte Authentifizierung (KBA)
Der Voice Agent bittet den Anrufer um Authentifizierungsdaten wie Kontonummer, Postleitzahl, Geburtsdatum oder Antworten auf Sicherheitsfragen. 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 einen beschreibenden Text enthält.
Sie können dies durch deterministische Workflow-Steuerung umsetzen: Nachdem die relevanten Informationen abgefragt wurden, konfigurieren Sie einen Tool-Dispatch und verwenden bedingte Weiterleitungskanten im Workflow. Diese verzweigen anhand des Erfolgs- oder Fehlerstatus des Tools und leiten authentifizierte Nutzer zu „privilegierten“ Agentenknoten weiter.
Dieser Ansatz unterstützt je nach Anforderungen an das Betrugsrisiko 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 Agenten-Workflows.
Dynamische Systemvariablen (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 Gesprächsbeginn automatisch befüllt.
Sie können darauf auf zwei Arten verweisen:
- In Prompts/Nachrichten: Verwenden Sie doppelte geschweifte Klammern, z. B. {{system__caller_id}}. Sie werden durch die tatsächlichen Werte ersetzt.
- In Tool-Parametern: Konfigurieren Sie Tool-Parameter für die Verwendung dieser Variablen. So ist eine stille Authentifizierung möglich, 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. Der Agent kann dann still prüfen, ob die eingehende Nummer mit der für die Nutzerauthentifizierung registrierten 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 andere als die hinterlegten Nummern verwenden können oder gespeicherte Nummern unbefugten Personen zugänglich sein könnten, sollte eine Authentifizierung anhand der Anrufer-ID eine vorherige Kundeneinwilligung erfordern oder mit weiteren Authentifizierungsmethoden wie wissensbasierten Fragen kombiniert werden.
Weitere Informationen finden Sie in der Dokumentation zu dynamischen Systemvariablen und zum Initiierungs-Webhook.
Erweiterte wissensbasierte Authentifizierung per Sicherheitsfrage
Der Agent kann einen Nutzer authentifizieren, indem er eine Reihe von Sicherheitsfragen stellt und nur Zugriff gewährt, wenn der Anrufer eine vorab festgelegte 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 Authentifizierungs-Tool gibt eine JSON-Antwort mit der aktuellen Anzahl erfolgreicher Prüfungen zurück. 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 wird die Variable erhöht.
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-Agent-Knoten. Der Ausdruck verwendet Vergleichsoperatoren wie 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 dem Agenten anschließend zur Verifizierung mitteilen, um Zugriff zu erhalten.
Hier ist der Implementierungsablauf im Detail:
- Code-Generierung: 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.
- Nutzerabfrage: Der Agent bittet den Nutzer anschließend, den erhaltenen Code anzugeben. Im Sprachmodus sprechen Nutzer den Code laut aus, der über Speech to Text erfasst wird.
- Code-Verifizierung: Der Agent sendet den vom Nutzer angegebenen Code mit einem zweiten Tool-Aufruf an einen Backend-Verifizierungsdienst. Das Backend prüft, ob der Code übereinstimmt, noch nicht abgelaufen ist und noch nicht verwendet wurde.
- Workflow-Weiterleitung: Der Agent verarbeitet das Ergebnis anhand der Verifizierungsantwort: Erfolg: Wenn der Code korrekt ist, wird der Nutzer über eine Erfolgsbedingung zum Teil des Workflows nach der Authentifizierung weitergeleitet. Fehler: Wenn der Code falsch ist, kann der Agent den Nutzer auffordern, den Code erneut einzugeben, oder ein Fallback-Verfahren starten, etwa einen neuen Code senden.
Sicherheitsaspekte: Zur Vermeidung von Brute-Force-Versuchen sollte Rate Limiting implementiert werden. Codes sollten kurze Ablaufzeiten von 3 bis 5 Minuten haben. Wiederholungsversuche sollten erfasst und begrenzt werden. Erwägen Sie bei Sprachinteraktionen Bestätigungsabfragen, um die Genauigkeit von Speech to Text bei der Erfassung von Codes sicherzustellen.
Starten Sie mit ElevenAgents für sichere Sprachauthentifizierung
Diese Authentifizierungsmethoden sind flexible Bausteine, keine vorgeschriebenen Lösungen. Ihre Auswahl sollte Ihr spezifisches Risikoprofil, regulatorische Anforderungen und Ziele für die Nutzererfahrung berücksichtigen. Ein Kundenservice-Bot benötigt andere Sicherheitsmaßnahmen als ein Bankassistent, der Transaktionen abwickelt. Die Flexibilität der Plattform ermöglicht es Ihnen, Ihre Sicherheitsstrategie an veränderte Bedrohungen und wachsende Anforderungen anzupassen und dabei Schutz und Nutzererfahrung auszubalancieren.
ElevenAgents bietet die oben beschriebenen deterministischen Workflow-Steuerungen, Dispatch-Tools und telefoniespezifischen Variablen. Damit können Sie eine Anruferauthentifizierung erstellen, die nie von der Beurteilung durch ein 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 erstellen.
