
Revolut selects ElevenLabs Agents to bolster customer support
Reducing time to ticket resolution by 8x with multilingual conversational agents.


Da Sprachagenten sensible, kontobezogene Aktionen übernehmen, ist eine robuste und deterministische Anruferauthentifizierung zu einer zentralen architektonischen Anforderung geworden.
Voice agents are rapidly evolving from simple FAQ responders to action-taking systems that modify accounts, process transactions, and access sensitive customer data. This shift introduces a critical challenge: How do you verify caller identity in a conversational AI system where traditional visual authentication methods don't exist?
Wenn ein Sprachagent Abonnements aktualisieren, Kontostände abrufen oder Rückerstattungen einleiten kann, muss er Anrufer genauso zuverlässig authentifizieren wie menschliche Callcenter – jedoch ausschließlich über Sprache. Im Gegensatz zu menschlichen Agenten, die Unternehmensrichtlinien befolgen, benötigen KI-Agenten eine deterministische, toolbasierte Authentifizierung, die nicht auf LLM-Entscheidungen basiert.
Dieser Artikel stellt bewährte Authentifizierungsmuster aus unserer Arbeit als Forward Deployed Engineers bei Unternehmenseinsätzen vor. Wir zeigen fünf zentrale Ansätze – von sitzungsbasierter Authentifizierung für eingebettete Widgets bis hin zu telefoniespezifischen Methoden und OTP-Verifizierung – und erklären, wie Sie diese mit deterministischen Workflow-Gates auf der ElevenLabs-Plattform umsetzen.
Vor allem zeigen wir, warum Authentifizierung nicht auf konversationelle Schlussfolgerungen gestützt werden darf. Sie muss durch isolierte Subagenten, toolbasierte Verifizierung und bedingte Workflow-Steuerung umgesetzt werden, sodass nur authentifizierte Nutzer Zugriff auf privilegierte Funktionen erhalten.
Um sicherzustellen, dass nur authentifizierte Nutzer auf kontobezogene Informationen zugreifen können, empfehlen wir eine strikte Trennung von Umgebung und Zugriff durch ElevenLabs-Workflows. Die Authentifizierung sollte immer über einen Tool-Call mit booleschem Erfolgs- oder Fehlerausgang erfolgen, der als Dispatch-Tool im ElevenLabs Workflow-Builder konfiguriert wird.
Durch die direkte Verknüpfung der Transferbedingung mit dem Tool-Call-Ergebnis ist der Subagent mit Zugriff auf Kontodaten erst nach erfolgreicher Authentifizierung erreichbar und bleibt vollständig von nicht authentifizierten Nutzern isoliert. So ist die Authentifizierung deterministisch, nicht von LLM-Entscheidungen abhängig, und verhindert jeden weiteren Zugriff ohne verifizierte Identität.
Alternativ können Transferausdrücke als zuverlässige Transfermethode genutzt werden. Diese Ausdrücke beziehen sich auf dynamische Variablen, die durch Tool-Call-Ergebnisse aktualisiert werden.
Beispielimplementierung
Authentifizieren Sie den Nutzer in Salesforce (Tool-Call). Bei Erfolg rufen Sie Kundentransaktionsdaten aus Salesforce ab (weiterer Tool-Call) und leiten den Nutzer dann an einen Subagenten weiter, der diese Daten für die Kommunikation und weitere Aktionen nutzt.

Diese Authentifizierungsmethoden werden auf der ElevenLabs-Plattform nicht nativ unterstützt. Sie können jedoch über serverseitige Tools umgesetzt werden, die mit Ihrem CRM oder Backend/der Datenbank integriert sind, in der Authentifizierungsdaten gespeichert werden.
Bei Sprachagenten, die in eine Website eingebettet sind, kann die Host-Anwendung Sitzungsdaten des Nutzers (z. B. Login-Status, Konto-ID oder Session-Token) beim Initialisieren des Agenten/Widgets über dynamische Variablen übergeben. Diese Variablen werden automatisch in Tool-Calls übernommen, sodass der Agent personalisierte Daten aus integrierten Systemen abrufen kann, ohne eine separate Authentifizierung zu verlangen.
Dadurch entsteht ein nahtloser Support-Prozess, da der Nutzer bereits durch die Host-Anwendung verifiziert wurde. Sie können dies über eine individuelle Konfiguration oder das ElevenLabs-Widget einrichten, indem Sie Variablen zur Laufzeit über die Widget-Konfiguration übergeben (z. B. <elevenlabs-convai dynamic-variables='{"user_id": "123", "account_tier": "premium"}'>).
Documentation on Dynamic Variables:
Der Sprachagent fordert den Anrufer auf, Authentifizierungsdaten wie Kontonummer, Postleitzahl, Geburtsdatum oder Sicherheitsantworten anzugeben. Ein serverseitiges Tool (Webhook oder clientseitig) prüft diese Werte gegen Ihre Datenbank (z. B. CRM oder Identitätsspeicher). Das Tool liefert ein Erfolgs-/Fehlerergebnis mit booleschem Status (is_error) und erläuterndem Text zurück. Sie können dies über deterministische Workflow-Gates umsetzen: Nach Abfrage der relevanten Informationen konfigurieren Sie einen Tool-Dispatch und nutzen bedingte Workflow-Transfers, die je nach Tool-Ergebnis authentifizierte Nutzer zu privilegierten Agenten-Nodes weiterleiten.
Dieser Ansatz unterstützt statische Sicherheitsfragen und dynamische "Out-of-Wallet"-Verifizierung, je nach Ihren Anforderungen an das Betrugsrisiko.
Dokumentation zu Tools:
Bei telefonbasierten Gesprächen (über Twilio oder SIP-Trunk) hat Ihr Agent automatisch Zugriff auf telefoniespezifische Systemvariablen, darunter system__caller_id (die Telefonnummer des Anrufers). Diese Variable wird beim Gesprächsstart automatisch befüllt und kann auf zwei Arten verwendet werden: 1) In Prompts/Nachrichten: Mit doppelten geschweiften Klammern referenzieren, z. B. {{system__caller_id}}, und sie werden durch die tatsächlichen Werte ersetzt. 2) In Tool-Parametern: Tool-Parameter können so konfiguriert werden, dass sie diese Variablen nutzen, was eine stille Authentifizierung ohne Erwähnung im Prompt ermöglicht.
Sie können beispielsweise ein Tool so konfigurieren, dass die Caller-ID automatisch an Ihr CRM-Lookup-Endpunkt übergeben wird, sodass der Agent still prüft, ob die eingehende Nummer mit der beim Kunden hinterlegten Nummer übereinstimmt. Alternativ kann die Authentifizierung auch als Konversations-Start-Webhook eingerichtet werden, der vor Gesprächsbeginn ausgeführt wird.
Sicherheitshinweis: Da Anrufer andere Nummern als die hinterlegten verwenden oder gespeicherte Nummern unbefugten Personen zugänglich sein können, sollte eine Authentifizierung per Caller-ID nur nach vorheriger Zustimmung des Kunden oder in Kombination mit weiteren Methoden (z. B. wissensbasierte Fragen) erfolgen.
Dokumentation zu Systemdynamischen Variablen und Initiation-Webhook:
Der Agent kann einen Nutzer authentifizieren, indem er eine Reihe von Sicherheitsfragen stellt und nur dann Zugriff gewährt, wenn der Anrufer eine festgelegte Anzahl korrekt beantwortet. Der Agent kann angewiesen werden, zufällige Fragen aus einer vordefinierten Liste (z. B. Geburtsdatum, Postleitzahl, Name des Haustiers) auszuwählen und die Antworten des Anrufers per Tool-Call mit Ihrer Datenbank abzugleichen.
Das Authentifizierungs-Tool liefert eine JSON-Antwort mit der aktuellen Erfolgsanzahl. Mithilfe von Tool-Zuweisungen wird dieser Wert automatisch extrahiert und in einer dynamischen Variable (z. B. auth_success_count) gespeichert/aktualisiert. Nach jeder erfolgreichen Verifizierung wird die Variable erhöht.
Sobald die erforderliche Anzahl an Verifizierungen erreicht ist (z. B. 3), prüft eine Workflow-Bedingung den Wert der dynamischen Variable und leitet zum privilegierten Subagenten weiter. Der Ausdruck nutzt Vergleichsoperatoren (z. B. auth_success_count >= 3), um den Zugriff deterministisch anhand des Authentifizierungsstatus zu steuern.

Dokumentation hier:https://www.11labs.ru/docs/agents-platform/customization/agent-workflows#edges-and-flow-control
Dies ist eine universelle Methode, bei der ein Einmal-Code per SMS oder E-Mail an das Gerät des Nutzers gesendet wird. Der Nutzer muss den Code dann dem Agenten mitteilen, um Zugriff zu erhalten.
Implementierungs-Workflow:
Sicherheitsaspekte: Es sollte eine Rate-Limitierung implementiert werden, um Brute-Force-Versuche zu verhindern. Codes sollten eine kurze Gültigkeit (3–5 Minuten) haben, und Wiederholungsversuche müssen begrenzt und protokolliert werden. Bei Sprachinteraktionen empfiehlt sich eine Bestätigungsabfrage, um die Sprache-zu-Text-Genauigkeit beim Erfassen der Codes sicherzustellen.
Diese Authentifizierungsmethoden sind flexible Bausteine, keine festen Vorgaben. Ihre Auswahl sollte sich an Ihrem spezifischen Risikoprofil, regulatorischen Anforderungen und den Zielen der Nutzererfahrung orientieren. Ein Kundenservice-Bot benötigt andere Sicherheitsmaßnahmen als ein Banking-Assistent für Transaktionen. Die Flexibilität der Plattform ermöglicht es, Ihre Sicherheitsstrategie an neue Bedrohungen und wachsende Anforderungen anzupassen – immer mit dem richtigen Gleichgewicht zwischen Schutz und Nutzererlebnis.

Reducing time to ticket resolution by 8x with multilingual conversational agents.
.webp&w=3840&q=95)
Yampa leverages ElevenLabs Flash V2.5 to scale human-like outbound voice agents with ultra-low latency and massive concurrency.