Projektowanie bezpiecznego uwierzytelniania rozmówców dla agentów głosowych

Agenci głosowi szybko przestają być prostymi systemami odpowiadającymi na FAQ, a stają się narzędziami, które modyfikują konta, przetwarzają transakcje i uzyskują dostęp do wrażliwych danych klientów. Ta zmiana stawia kluczowe pytanie: jak uwierzytelnić tożsamość dzwoniącego w systemie Conversational AI, w którym nie ma tradycyjnych wizualnych metod weryfikacji?

Gdy agent głosowy może aktualizować subskrypcje, sprawdzać salda kont lub inicjować zwroty, musi uwierzytelniać dzwoniących z taką samą starannością jak pracownicy call center — wyłącznie za pomocą głosu. W przeciwieństwie do pracowników, którzy przestrzegają zasad firmy, agenci AI potrzebują deterministycznego uwierzytelniania opartego na narzędziach, które nie zależy od oceny LLM.

W tym artykule przedstawiamy sprawdzone schematy uwierzytelniania z naszej pracy jako Forward Deployed Engineers przy wdrożeniach dla przedsiębiorstw. Omówimy pięć głównych podejść — od uwierzytelniania opartego na sesji dla osadzonych widgetów po metody telekomunikacyjne i weryfikację OTP — oraz wyjaśnimy, jak wdrożyć je za pomocą deterministycznego kontrolowania workflow na platformie ElevenLabs.

Co najważniejsze, pokażemy, dlaczego uwierzytelniania nie można pozostawić wnioskowaniu podczas rozmowy. Zamiast tego należy je zaprojektować z użyciem odizolowanych podagentów, weryfikacji opartej na narzędziach i warunkowego kierowania w workflow, które zapewni, że tylko uwierzytelnieni użytkownicy dotrą do uprzywilejowanych operacji.

Podsumowanie

• Uwierzytelnianie dzwoniących dla agentów głosowych musi być deterministyczne i oparte na narzędziach; nie można zostawiać go wnioskowaniu LLM podczas rozmowy.
• Uwierzytelnianie przez aplikację hostującą przekazuje do agenta dane istniejącej sesji, więc zalogowani użytkownicy nie muszą uwierzytelniać się ponownie.
• Uwierzytelnianie oparte na wiedzy weryfikuje dane podane przez dzwoniącego, takie jak numer konta lub data urodzenia, w systemie backendu za pomocą wywołania narzędzia po stronie serwera.
• Wdrożenia telefoniczne mogą wykorzystywać systemowe zmienne dynamiczne, takie jak identyfikator dzwoniącego, do cichego uwierzytelniania, ale należy połączyć je z drugim czynnikiem, ponieważ identyfikator dzwoniącego można podszyć lub udostępnić.
• Weryfikacja kodem jednorazowym wysyła kod SMS-em lub e-mailem i sprawdza go przez usługę backendu.

Architektura deterministycznego uwierzytelniania

Aby zapewnić, że tylko uwierzytelnieni użytkownicy mają dostęp do informacji o koncie, zalecamy ścisłe rozdzielenie środowisk i dostępu za pomocą workflow ElevenLabs. Uwierzytelnianie zawsze powinno być realizowane przez wywołanie narzędzia ze zwracanym wynikiem logicznym — powodzeniem lub błędem — skonfigurowane jako dispatch tool w kreatorze workflow ElevenLabs.

Gdy warunek przekazania połączysz bezpośrednio z wynikiem wywołania narzędzia, podagent z dostępem do danych konta będzie dostępny tylko po udanym uwierzytelnieniu i pozostanie całkowicie odizolowany od nieuwierzytelnionych użytkowników. Zapewnia to deterministyczne uwierzytelnianie, niezależne od decyzji LLM, i blokuje przejście do kolejnych węzłów bez zweryfikowanej tożsamości.

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

Przykładowa implementacja

Zweryfikuj użytkownika w Salesforce (wywołanie narzędzia). Jeśli weryfikacja się powiedzie, pobierz z Salesforce dane o transakcjach klienta (kolejne wywołanie narzędzia), a następnie przekaż użytkownika do podagenta, który wykorzysta te dane do komunikacji z klientem i w razie potrzeby wykona inne działania.

Metody uwierzytelniania tożsamości użytkownika

Te metody uwierzytelniania nie są natywnie obsługiwane na platformie ElevenLabs. Możesz je wdrożyć za pomocą narzędzi po stronie serwera, które integrują się z CRM lub backendem/bazą danych, gdzie przechowywane są dane uwierzytelniające.

Uwierzytelnianie przez aplikację hostującą

W przypadku agentów głosowych osadzonych na stronie internetowej aplikacja hostująca może przekazać dane sesji użytkownika — takie jak status logowania, identyfikator konta lub tokeny sesji — przez zmienne dynamiczne podczas inicjalizacji agenta/widgetu. Te zmienne są automatycznie wstawiane do wywołań narzędzi, dzięki czemu agent może pobierać spersonalizowane dane z połączonych systemów bez osobnego uwierzytelniania.

Zapewnia to płynną obsługę, ponieważ użytkownik został już zweryfikowany przez aplikację hostującą. Możesz skonfigurować to samodzielnie lub użyć widgetu ElevenLabs, w którym przekazujesz zmienne w czasie działania przez konfigurację widgetu (np. <elevenlabs-convai dynamic-variables='{"user_id": "123", "account_tier": "premium"}'>).

Pełną konfigurację znajdziesz w dokumentacji zmiennych dynamicznych.

Uwierzytelnianie oparte na wiedzy (KBA) 

Agent głosowy prosi dzwoniącego o dane uwierzytelniające, takie jak numer konta, kod pocztowy, data urodzenia lub odpowiedzi na pytania zabezpieczające. Narzędzie po stronie serwera — webhook lub wywołanie backendu — porównuje te wartości z bazą danych, np. CRM lub magazynem tożsamości. Narzędzie zwraca wynik powodzenia lub błędu, obejmujący zarówno status logiczny (is_error), jak i opisowy tekst.

Możesz wdrożyć to przez deterministyczne kontrolowanie workflow: po poproszeniu o potrzebne informacje skonfiguruj wysyłkę narzędzia i użyj warunkowych krawędzi przekazania workflow, które rozgałęziają się na podstawie statusu powodzenia lub błędu narzędzia, kierując uwierzytelnionych użytkowników do „uprzywilejowanych” węzłów agenta. 

To podejście obsługuje statyczne pytania zabezpieczające oraz dynamiczną weryfikację typu „out-of-wallet”, zależnie od wymagań dotyczących ryzyka oszustw.

Więcej informacji znajdziesz w dokumentacji narzędzi serwerowych i węzła dispatch tool w workflow agentów.

Systemowe zmienne dynamiczne (tylko telefonia)

W rozmowach telefonicznych — przez Twilio lub SIP trunk — agent automatycznie ma dostęp do systemowych zmiennych specyficznych dla telefonii, w tym system__caller_id (numer telefonu dzwoniącego). Ta zmienna jest automatycznie uzupełniana po rozpoczęciu rozmowy.

Możesz odwołać się do niej na dwa sposoby:

1. W promptach/wiadomościach: odwołuj się do niej za pomocą podwójnych nawiasów klamrowych, np. {{system__caller_id}} — zostanie zastąpiona rzeczywistą wartością.
2. W parametrach narzędzia: skonfiguruj parametry narzędzia tak, by używały tych zmiennych, co umożliwi ciche uwierzytelnianie bez wspominania o nich w prompcie.

Możesz na przykład skonfigurować narzędzie, aby automatycznie przekazywało identyfikator dzwoniącego do endpointu wyszukiwania CRM. Pozwoli to agentowi dyskretnie sprawdzić, czy numer przychodzący odpowiada zarejestrowanemu numerowi klienta na potrzeby uwierzytelnienia użytkownika. Zamiast wywołania narzędzia uwierzytelnianie możesz też skonfigurować jako webhook inicjujący rozmowę, wykonywany przed jej rozpoczęciem. 

Uwaga dotycząca bezpieczeństwa: Dzwoniący mogą korzystać z innych numerów niż zapisane w systemie, a zapisane numery mogą być dostępne dla nieupoważnionych osób. Dlatego uwierzytelnianie na podstawie identyfikatora dzwoniącego powinno wymagać wcześniejszej zgody klienta albo być połączone z dodatkowymi metodami uwierzytelniania, np. pytaniami opartymi na wiedzy.

Więcej informacji znajdziesz w dokumentacji systemowych zmiennych dynamicznych oraz webhooka inicjującego.

Zaawansowane uwierzytelnianie oparte na wiedzy / pytaniach zabezpieczających

Agent może uwierzytelnić użytkownika, zadając zestaw pytań zabezpieczających i przyznając dostęp tylko wtedy, gdy dzwoniący udzieli poprawnej, z góry określonej liczby odpowiedzi. Możesz polecić agentowi losowanie pytań z wcześniej zdefiniowanej listy, np. o datę urodzenia, kod pocztowy lub imię zwierzęcia, a następnie weryfikowanie odpowiedzi dzwoniącego przez wywołanie narzędzia do bazy danych.

Narzędzie uwierzytelniające zwraca odpowiedź JSON zawierającą bieżącą liczbę udanych weryfikacji. Dzięki przypisaniom narzędzia liczba ta jest automatycznie wyodrębniana i zapisywana lub aktualizowana w zmiennej dynamicznej, np. auth_success_count. Po każdej udanej weryfikacji wartość zmiennej rośnie.

Po osiągnięciu wymaganej liczby weryfikacji, np. 3, warunek wyrażenia workflow sprawdza wartość zmiennej dynamicznej i przechodzi do uprzywilejowanego węzła podagenta. Wyrażenie używa operatorów porównania, np. auth_success_count >= 3, aby deterministycznie kontrolować dostęp na podstawie statusu uwierzytelnienia.

Więcej informacji znajdziesz w naszej dokumentacji krawędzi i kontroli przepływu.

Kod jednorazowy

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

Oto bardziej szczegółowy workflow implementacji:

1. Generowanie kodu: agent rozpoczyna proces wywołaniem narzędzia serwerowego do dedykowanego endpointu. To działanie generuje bezpieczny kod jednorazowy i wysyła go użytkownikowi preferowanym kanałem — SMS-em lub e-mailem.
2. Prośba do użytkownika: agent prosi użytkownika o podanie otrzymanego kodu. W trybie głosowym użytkownik wypowiada kod na głos, a system rejestruje go za pomocą zamiany mowy na tekst.
3. Weryfikacja kodu: agent wysyła kod podany przez użytkownika do usługi weryfikacyjnej backendu za pomocą drugiego wywołania narzędzia. Backend sprawdza, czy kod jest zgodny, nie wygasł i nie został już użyty.
4. Kierowanie w workflow: agent obsługuje wynik na podstawie odpowiedzi weryfikacji. Powodzenie: jeśli kod jest poprawny, użytkownik zostaje skierowany do części workflow po uwierzytelnieniu przez warunek powodzenia. Błąd: jeśli kod jest nieprawidłowy, agent może poprosić o ponowne wpisanie kodu lub uruchomić procedurę awaryjną, np. wysłać nowy kod.

Kwestie bezpieczeństwa: zastosuj ograniczenie liczby żądań, aby zapobiec próbom brute-force; kody powinny krótko zachowywać ważność — 3–5 minut — a próby ponowienia należy śledzić i ograniczać. W interakcjach głosowych rozważ prośby o potwierdzenie, aby zapewnić dokładność zamiany mowy na tekst podczas rejestrowania kodów.

Zacznij korzystać z ElevenAgents do bezpiecznego uwierzytelniania głosowego

Te metody uwierzytelniania to elastyczne elementy, a nie gotowe rozwiązania. Wybór powinien odzwierciedlać profil ryzyka, wymagania regulacyjne i cele dotyczące doświadczenia użytkownika. Bot obsługi klienta potrzebuje innych zabezpieczeń niż asystent bankowy obsługujący transakcje. Elastyczność platformy pozwala rozwijać strategię bezpieczeństwa wraz ze zmieniającymi się zagrożeniami i rosnącymi wymaganiami, zawsze równoważąc ochronę z doświadczeniem użytkownika.

ElevenAgents zapewnia opisane wyżej deterministyczne kontrolowanie workflow, dispatch tools i zmienne specyficzne dla telefonii, dzięki czemu możesz tworzyć uwierzytelnianie dzwoniących, które nigdy nie zależy od oceny LLM.

Poznaj platformę ElevenAgents i zobacz pełny kreator workflow albo skontaktuj się z działem sprzedaży, aby już dziś zacząć tworzyć swój pierwszy workflow uwierzytelnionego agenta głosowego.

FAQ: bezpieczne przepływy uwierzytelniania tożsamości dzwoniącego