Projektowanie bezpiecznych przepływów uwierzytelniania tożsamości dzwoniących dla agentów głosowych

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?

Gdy agent głosowy może zmieniać subskrypcje, sprawdzać saldo czy inicjować zwroty, musi uwierzytelniać użytkowników tak samo dokładnie jak ludzie w call center – ale całość odbywa się głosowo. W przeciwieństwie do ludzi, którzy trzymają się procedur, AI potrzebuje jednoznacznego, narzędziowego uwierzytelniania, które nie opiera się na ocenie LLM.

W tym artykule pokazujemy sprawdzone sposoby uwierzytelniania, które wypracowaliśmy jako Forward Deployed Engineers przy wdrożeniach w firmach. Opiszemy pięć głównych metod – od uwierzytelniania sesyjnego dla osadzonych widgetów, przez telekomunikacyjne, po weryfikację kodem OTP – i pokażemy, jak wdrożyć każdą z nich, korzystając z deterministycznego sterowania workflow w ElevenLabs.

Najważniejsze: nie można zostawiać uwierzytelniania domysłom AI. Trzeba je zaprojektować przez wydzielone sub-agenty, narzędziową weryfikację i warunkowe przekierowania w workflow, tak by tylko uwierzytelnieni użytkownicy mieli dostęp do wrażliwych operacji.

Podstawy architektury deterministycznego uwierzytelniania

Aby tylko uwierzytelnieni użytkownicy mieli dostęp do danych konta, zalecamy ścisłe rozdzielenie środowisk i dostępów przez workflow ElevenLabs. Uwierzytelnianie zawsze powinno być realizowane przez wywołanie narzędzia, które zwraca wynik typu sukces/porażka (boolean), skonfigurowane jako dispatch tool w kreatorze workflow ElevenLabs.

Łącząc warunek przekazania bezpośrednio z wynikiem narzędzia, sub-agent z dostępem do danych konta jest osiągalny tylko po pomyślnym uwierzytelnieniu i pozostaje całkowicie odizolowany od niezweryfikowanych użytkowników. Dzięki temu uwierzytelnianie jest deterministyczne, nie zależy od decyzji LLM i nie pozwala przejść dalej bez potwierdzonej tożsamości.

Alternatywnie można użyć wyrażeń transferowych jako niezawodnej metody przekierowania. Odwołują się one do dynamicznych zmiennych aktualizowanych przez wyniki narzędzi.

Przykład wdrożenia

Zweryfikuj użytkownika w Salesforce (wywołanie narzędzia). Jeśli się uda, pobierz dane transakcji klienta z Salesforce (kolejne wywołanie narzędzia), a następnie przekaż użytkownika do subagenta, który wykorzysta te dane do rozmowy i innych działań.

Metody uwierzytelniania tożsamości użytkownika

Te metody uwierzytelniania nie są natywnie dostępne w ElevenLabs. Możesz je wdrożyć przez narzędzia po stronie serwera, które integrują się z twoim CRM lub bazą danych, gdzie przechowywane są dane do uwierzytelniania.

Uwierzytelnianie przez aplikację hostującą

Dla agentów głosowych osadzonych na stronie, aplikacja hostująca może przekazać dane sesji użytkownika (np. status zalogowania, ID konta, tokeny sesji) przez dynamiczne zmienne podczas inicjalizacji agenta/widgetu. Te zmienne są automatycznie wstrzykiwane do wywołań narzędzi, dzięki czemu agent pobiera spersonalizowane dane z systemów bez osobnego uwierzytelniania.

Dzięki temu wsparcie jest płynne, bo użytkownik został już zweryfikowany przez aplikację hostującą. Możesz to ustawić przez własną konfigurację lub użyć widgetu ElevenLabs, przekazując zmienne w konfiguracji widgetu (np. <elevenlabs-convai dynamic-variables='{"user_id": "123", "account_tier": "premium"}'>).

Documentation on Dynamic Variables:

• https://www.11labs.ru/docs/agents-platform/customization/personalization/dynamic-variables#pass-variables-at-runtime 

Uwierzytelnianie na podstawie wiedzy (KBA)

Agent głosowy prosi użytkownika o podanie danych uwierzytelniających, np. numeru konta, kodu pocztowego, daty urodzenia lub odpowiedzi na pytania bezpieczeństwa. Narzędzie po stronie serwera (webhook lub po stronie klienta) sprawdza te dane w twojej bazie (np. CRM lub magazynie tożsamości). Narzędzie zwraca wynik sukces/porażka (boolean) i opis. Możesz to wdrożyć przez deterministyczne sterowanie workflow: po zebraniu danych ustaw dispatch tool i warunkowe przekierowania, które na podstawie wyniku kierują uwierzytelnionych użytkowników do „uprzywilejowanych” węzłów agenta.

To podejście obsługuje statyczne pytania zabezpieczające i dynamiczną weryfikację w stylu "out-of-wallet", w zależności od twoich wymagań dotyczących ryzyka oszustwa.

Dokumentacja narzędzi:

• https://www.11labs.ru/docs/agents-platform/customization/tools/server-tools 
• https://www.11labs.ru/docs/agents-platform/customization/agent-workflows#dispatch-tool-node 

Systemowe zmienne dynamiczne (tylko telefony)

Przy rozmowach telefonicznych (przez Twilio lub SIP trunk) agent ma automatyczny dostęp do systemowych zmiennych telekomunikacyjnych, w tym system__caller_id (numer telefonu dzwoniącego). Ta zmienna pojawia się automatycznie na początku rozmowy i można jej użyć na dwa sposoby: 1) W promptach/wiadomościach: odwołuj się do niej przez podwójne klamry, np. {{system__caller_id}}, a zostanie zastąpiona prawdziwą wartością; 2) W parametrach narzędzi: ustaw parametry narzędzi, by korzystały z tych zmiennych, co pozwala na ciche uwierzytelnianie bez wspominania o tym w promptach.

Możesz np. ustawić narzędzie, które automatycznie przekazuje caller ID do twojego endpointu CRM, by agent mógł po cichu sprawdzić, czy numer dzwoniącego zgadza się z numerem klienta. Zamiast wywołania narzędzia, uwierzytelnianie można też ustawić jako webhook inicjujący rozmowę, który uruchamia się przed jej rozpoczęciem.

Uwaga bezpieczeństwa: Ponieważ użytkownicy mogą dzwonić z innych numerów lub ktoś nieuprawniony może mieć dostęp do numeru, uwierzytelnianie przez caller ID powinno wymagać wcześniejszej zgody klienta lub być łączone z innymi metodami (np. pytaniami weryfikacyjnymi).

Dokumentacja o systemowych zmiennych dynamicznych i webhooku inicjującym:

• https://www.11labs.ru/docs/agents-platform/customization/personalization/dynamic-variables#system-dynamic-variables 
• https://www.11labs.ru/docs/agents-platform/customization/personalization/twilio-personalization 

Zaawansowane uwierzytelnianie przez pytania bezpieczeństwa

Agent może uwierzytelnić użytkownika, zadając zestaw pytań bezpieczeństwa i dając dostęp tylko, jeśli użytkownik odpowie poprawnie na ustaloną liczbę z nich. Agent może losować pytania z listy (np. data urodzenia, kod pocztowy, imię zwierzaka) i sprawdzać odpowiedzi przez wywołanie narzędzia do bazy danych.

Narzędzie do uwierzytelniania zwraca odpowiedź JSON z aktualną liczbą poprawnych odpowiedzi. Dzięki przypisaniom narzędzi ta liczba jest automatycznie zapisywana i aktualizowana w dynamicznej zmiennej (np. auth_success_count). Po każdej poprawnej odpowiedzi zmienna się zwiększa.

Gdy wymagana liczba weryfikacji zostanie osiągnięta (np. 3), warunek w workflow sprawdza wartość zmiennej i przechodzi do uprzywilejowanego subagenta. Wyrażenie używa operatorów porównania (np. auth_success_count >= 3), by jednoznacznie sterować dostępem na podstawie statusu uwierzytelnienia.

Dokumentacja tutaj:https://www.11labs.ru/docs/agents-platform/customization/agent-workflows#edges-and-flow-control 

Kod jednorazowy

To uniwersalna metoda, w której kod jednorazowy jest wysyłany na urządzenie użytkownika SMS-em lub mailem. Użytkownik musi podać kod agentowi, by uzyskać dostęp.

Przebieg wdrożenia:

1. Generowanie kodu: Agent zaczyna proces przez wywołanie narzędzia do odpowiedniego endpointu. To generuje bezpieczny kod jednorazowy i wysyła go użytkownikowi wybranym kanałem (SMS lub e-mail).
2. Prośba o kod: Agent prosi użytkownika o podanie otrzymanego kodu. W trybie głosowym użytkownik wypowiada kod, który jest rozpoznawany przez speech-to-text.
3. Weryfikacja kodu: Agent przesyła podany kod do usługi weryfikacyjnej przez kolejne wywołanie narzędzia. Backend sprawdza, czy kod się zgadza, nie wygasł i nie został już użyty.
4. Przekierowanie w workflow: Agent reaguje na wynik weryfikacji: Sukces – jeśli kod jest poprawny, użytkownik trafia do dalszej części workflow przez warunek sukcesu. Porażka – jeśli kod jest zły, agent może poprosić o ponowne podanie kodu lub wysłać nowy.

Bezpieczeństwo: Warto wdrożyć limity prób, by zapobiec atakom brute force, ustawić krótki czas ważności kodów (3-5 minut) i ograniczyć liczbę powtórzeń. Przy rozmowach głosowych warto dodać potwierdzenie, by upewnić się, że kod został poprawnie rozpoznany przez speech-to-text.

Podsumowanie

Te metody uwierzytelniania to elastyczne elementy, które możesz dopasować do swoich potrzeb. Wybierz rozwiązanie zgodne z poziomem ryzyka, wymogami prawnymi i oczekiwaniami użytkowników. Bot obsługi klienta potrzebuje innego poziomu bezpieczeństwa niż asystent bankowy. Elastyczność platformy pozwala rozwijać strategię zabezpieczeń wraz ze zmianą zagrożeń i wymagań – zawsze z myślą o równowadze między ochroną a wygodą użytkownika.