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

Agenci głosowi szybko zmieniają się z prostych narzędzi odpowiadających na FAQ w systemy, które modyfikują konta, przetwarzają transakcje i uzyskują dostęp do wrażliwych danych klientów. Ta zmiana rodzi kluczowe pytanie: jak uwierzytelnić tożsamość rozmówcy w systemie Conversational AI, w którym nie ma tradycyjnych metod weryfikacji wizualnej?

Gdy agent głosowy może aktualizować subskrypcje, sprawdzać saldo konta lub inicjować zwroty, musi uwierzytelniać rozmówców równie rygorystycznie jak konsultanci w call center — ale wyłącznie przez głos. W przeciwieństwie do konsultantów, którzy stosują polityki firmy, agenci AI potrzebują deterministycznego uwierzytelniania opartego na narzędziach, a nie ocenie LLM.

W tym artykule przedstawiamy sprawdzone wzorce uwierzytelniania z naszej pracy jako Forward Deployed Engineers przy wdrożeniach dla firm. Omówimy pięć głównych metod — od uwierzytelniania opartego na sesji w osadzonych widgetach po metody telekomunikacyjne i weryfikację OTP — oraz wyjaśnimy, jak wdrożyć je przez deterministyczne bramkowanie workflow na platformie ElevenLabs.

Co najważniejsze, pokażemy, dlaczego uwierzytelniania nie można pozostawić wnioskom z rozmowy. 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 operacji uprzywilejowanych.

Podsumowanie

• Uwierzytelnianie rozmówców przez agentów głosowych musi być deterministyczne i oparte na narzędziach; nie może zależeć od wniosków LLM z rozmowy.
• Uwierzytelnianie przez aplikację hosta przekazuje do agenta istniejące dane sesji, więc zalogowani użytkownicy nie muszą uwierzytelniać się ponownie.
• Uwierzytelnianie oparte na wiedzy porównuje dane podane przez rozmówcę, takie jak numer konta lub data urodzenia, z systemem backendu za pomocą wywołania narzędzia po stronie serwera.
• Wdrożenia telekomunikacyjne mogą używać systemowych zmiennych dynamicznych, takich jak identyfikator rozmówcy, do cichego uwierzytelniania. Należy jednak połączyć je z drugim czynnikiem, ponieważ identyfikator rozmówcy można sfałszować lub może być współdzielony.
• Weryfikacja kodem jednorazowym wysyła kod przez SMS lub e-mail i sprawdza go w usłudze backendu.

Podstawa architektury 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 korzystać z wywołania narzędzia zwracającego logiczny wynik powodzenia lub niepowodzenia, skonfigurowanego jako narzędzie dispatch w kreatorze workflow ElevenLabs.

Po bezpośrednim powiązaniu warunku przekazania z wynikiem wywołania narzędzia podagent z dostępem do danych konta jest osiągalny tylko po pomyślnym uwierzytelnieniu i pozostaje całkowicie odizolowany od nieuwierzytelnionych użytkowników. Dzięki temu uwierzytelnianie jest deterministyczne, nie zależy od decyzji LLM i nie pozwala przejść do kolejnych węzłów bez zweryfikowanej tożsamości.

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

Przykładowe wdrożenie

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ą wbudowane w platformę ElevenLabs. Możesz wdrożyć je 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ę hosta

W przypadku agentów głosowych osadzonych na stronie aplikacja hosta może przekazywać dane sesji użytkownika (takie jak status logowania, identyfikator konta lub tokeny sesji) przez zmienne dynamiczne podczas inicjalizacji agenta/widgetu. Zmienne te 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ę hosta. Możesz skonfigurować to ręcznie lub użyć widgetu ElevenLabs, w którym przekazujesz zmienne w czasie działania przez jego konfigurację (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 rozmówcę 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) sprawdza te wartości w bazie danych, np. CRM lub magazynie tożsamości. Narzędzie zwraca wynik powodzenia/niepowodzenia, zawierający zarówno status logiczny (is_error), jak i opisowy tekst.

Możesz wdrożyć to przez deterministyczne bramkowanie workflow: po zebraniu odpowiednich informacji skonfiguruj dispatch narzędzia i użyj warunkowych krawędzi przekazania w workflow, które rozgałęziają się zależnie od wyniku powodzenia/niepowodzenia narzędzia i kierują 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 narzędzia dispatch w workflow agentów.

Systemowe zmienne dynamiczne (tylko telefonia)

W rozmowach telefonicznych (przez Twilio lub trunk SIP) agent ma automatyczny dostęp do systemowych zmiennych specyficznych dla telefonii, w tym system__caller_id (numeru telefonu rozmówcy). Ta zmienna jest automatycznie uzupełniana na początku 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}}, a zostanie zastąpiona rzeczywistą wartością.
2. W parametrach narzędzia: Skonfiguruj parametry narzędzia tak, aby używały tych zmiennych, co umożliwia ciche uwierzytelnianie bez wspominania o nich w prompcie.

Możesz na przykład skonfigurować narzędzie tak, aby automatycznie przekazywało identyfikator rozmówcy do endpointu wyszukiwania w CRM. Agent może wtedy po cichu sprawdzić, czy numer przychodzący zgadza się z numerem zarejestrowanym przez klienta na potrzeby uwierzytelnienia użytkownika. Zamiast wywołania narzędzia uwierzytelnianie można też skonfigurować jako webhook inicjujący rozmowę, wykonywany przed jej rozpoczęciem. 

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

Więcej informacji znajdziesz w dokumentacji systemowych zmiennych dynamicznych i 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 rozmówca poprawnie odpowie na określoną liczbę z nich. Możesz polecić agentowi losowanie pytań z wcześniej zdefiniowanej listy, np. o datę urodzenia, kod pocztowy lub imię zwierzęcia, a następnie sprawdzanie odpowiedzi przez wywołanie narzędzia do bazy danych.

Narzędzie uwierzytelniające zwraca odpowiedź JSON zawierającą bieżącą liczbę poprawnych odpowiedzi. Dzięki przypisaniom narzędzi liczba ta jest automatycznie wyodrębniana i zapisywana/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 przez SMS lub e-mail. Aby uzyskać dostęp, użytkownik musi przekazać kod agentowi do weryfikacji.

Poniżej szczegóły workflow wdrożenia:

1. Generowanie kodu: Agent rozpoczyna proces wywołaniem narzędzia serwerowego do dedykowanego endpointu. Wywołanie generuje bezpieczny kod jednorazowy i wysyła go użytkownikowi wybranym kanałem — SMS-em lub e-mailem.
2. Prośba do użytkownika: Agent prosi następnie użytkownika o podanie otrzymanego kodu. W trybie głosowym użytkownik wypowiada kod, który jest przechwytywany przez zamianę mowy na tekst.
3. Weryfikacja kodu: Agent wysyła kod podany przez użytkownika do usługi weryfikacyjnej backendu, używając drugiego wywołania narzędzia. Backend sprawdza, czy kod się zgadza, nie wygasł i nie został już użyty.
4. Kierowanie w workflow: Agent obsługuje wynik zgodnie z odpowiedzią weryfikacji. Sukces: jeśli kod jest poprawny, użytkownik trafia do części workflow po uwierzytelnieniu przez warunek sukcesu. Niepowodzenie: jeśli kod jest niepoprawny, agent może poprosić użytkownika o ponowne podanie kodu lub uruchomić procedurę zapasową, np. wysłać nowy kod.

Kwestie bezpieczeństwa: wdroż ograniczanie liczby żądań, aby zapobiec próbom brute force; kody powinny mieć krótki czas ważności (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 odbierania 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ć twój profil ryzyka, wymogi regulacyjne i cele związane z doświadczeniem 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 zmianą zagrożeń i rosnącymi wymaganiami, zawsze równoważąc ochronę z wygodą użytkownika.

ElevenAgents zapewnia opisane wyżej deterministyczne bramkowanie workflow, narzędzia dispatch i zmienne specyficzne dla telefonii. Dzięki temu możesz tworzyć uwierzytelnianie rozmówców, które nigdy nie zależy od oceny LLM.

Poznaj platformę ElevenAgents i zobacz pełny kreator workflow lub 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 rozmówcy