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

Agenci głosowi szybko ewoluują — od prostych systemów odpowiadających na FAQ do systemów wykonujących działania, które zmieniają dane 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, gdzie nie ma tradycyjnych metod weryfikacji wizualnej?

Gdy agent głosowy może aktualizować subskrypcje, pobierać salda kont lub inicjować zwroty, musi uwierzytelniać rozmówców równie rygorystycznie jak ludzkie centra obsługi telefonicznej, lecz wyłącznie głosowo. W przeciwieństwie do ludzkich agentów, którzy stosują polityki firmy, agenci AI wymagają deterministycznego uwierzytelniania opartego na narzędziach, bez polegania na ocenie LLM.

W tym artykule przedstawiamy sprawdzone schematy uwierzytelniania z naszej pracy jako Forward Deployed Engineers przy wdrożeniach dla firm. Omówimy pięć głównych podejść — od uwierzytelniania sesyjnego dla osadzonych widgetów po metody specyficzne dla telefonii 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 zostawić wnioskowaniu na podstawie rozmowy. Należy je zaprojektować z użyciem odizolowanych podagentów, weryfikacji opartej na narzędziach i warunkowego routingu workflow, który zapewnia dostęp do uprzywilejowanych operacji wyłącznie uwierzytelnionym użytkownikom.

Podsumowanie

• Uwierzytelnianie rozmówców dla agentów głosowych musi być deterministyczne i oparte na narzędziach; nie może zależeć od wnioskowania LLM na podstawie rozmowy.
• Uwierzytelnianie przez aplikację hostującą 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 przez wywołanie narzędzia po stronie serwera.
• Wdrożenia telefoniczne mogą używać systemowych zmiennych dynamicznych, takich jak identyfikator rozmówcy, do dyskretnego uwierzytelniania, ale warto połączyć je z drugim czynnikiem, ponieważ identyfikator można sfałszować lub udostępnić.
• Weryfikacja kodem jednorazowym wysyła kod SMS-em lub e-mailem i sprawdza go przez usługę backendową.

Architektoniczne podstawy deterministycznego uwierzytelniania

Aby zapewnić dostęp do informacji o koncie wyłącznie uwierzytelnionym użytkownikom, zalecamy ścisłe rozdzielenie środowisk i dostępu przez workflow ElevenLabs. Uwierzytelnianie zawsze należy wdrażać przez wywołanie narzędzia z logicznym wynikiem sukcesu lub porażki, skonfigurowane jako dispatch tool w kreatorze workflow ElevenLabs.

Po bezpośrednim powiązaniu warunku transferu z wynikiem wywołania narzędzia podagent z dostępem do danych konta jest dostępny 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 uniemożliwia przejście do kolejnych węzłów bez zweryfikowanej tożsamości.

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

Przykład wdrożenia

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 w rozmowie z klientem i w razie potrzeby wykona inne działania.

Metody uwierzytelniania tożsamości użytkownika

Te metody uwierzytelniania nie są natywnie dostępne na platformie ElevenLabs. Możesz je wdrożyć przez narzędzia po stronie serwera, zintegrowane 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 aplikacja hostująca może przekazać dane sesji użytkownika — takie jak status zalogowania, ID 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ę hostującą. Możesz skonfigurować to niestandardowo 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 Dynamic Variables.

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 sukcesu lub porażki, obejmujący zarówno status logiczny (is_error), jak i opisowy tekst.

Możesz wdrożyć to przez deterministyczne bramkowanie workflow: po zebraniu potrzebnych informacji skonfiguruj dispatch narzędzia oraz warunkowe krawędzie transferu workflow, które rozgałęziają się według statusu sukcesu lub porażki 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 dispatch tool w workflow agentów.

Systemowe zmienne dynamiczne (tylko telefonia)

W rozmowach telefonicznych (przez Twilio lub SIP trunk) twój agent automatycznie ma 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: Użyj podwójnych nawiasów klamrowych, np. {{system__caller_id}}, a zostaną one zastąpione rzeczywistymi wartościami.
2. W parametrach narzędzia: Skonfiguruj parametry narzędzia tak, aby używały tych zmiennych, co pozwoli dyskretnie uwierzytelnić użytkownika bez wspominania o nich w prompcie.

Możesz na przykład skonfigurować narzędzie, aby automatycznie przekazywało identyfikator rozmówcy do endpointu wyszukiwania CRM. Dzięki temu agent dyskretnie 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ę, uruchamiany przed jej rozpoczęciem. 

Uwaga dotycząca bezpieczeństwa: Rozmówcy mogą dzwonić z innych numerów niż zapisane w systemie, a do zapisanych numerów mogą mieć dostęp osoby nieuprawnione. Dlatego uwierzytelnianie oparte na identyfikatorze rozmówcy powinno wymagać wcześniejszej zgody klienta lub być łączone z dodatkowymi metodami uwierzytelniania, np. pytaniami opartymi na wiedzy.

Więcej informacji znajdziesz w dokumentacji System Dynamic Variables oraz Initiation webhook.

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 predefiniowanej listy, np. o datę urodzenia, kod pocztowy lub imię zwierzęcia, oraz sprawdzanie odpowiedzi rozmówcy przez wywołanie narzędzia do twojej bazy danych.

Narzędzie uwierzytelniające zwraca odpowiedź JSON z bieżącą liczbą udanych weryfikacji. Za pomocą przypisań 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 wzrasta.

Gdy osiągnięta zostanie wymagana liczba 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 następnie podać kod agentowi do weryfikacji.

Oto szczegółowy workflow wdrożenia:

1. Generowanie kodu: Agent rozpoczyna proces wywołaniem narzędzia serwerowego do dedykowanego endpointu. Powoduje to wygenerowanie bezpiecznego kodu jednorazowego i wysłanie 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 na głos, a system przechwytuje go 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. Routing workflow: Agent obsługuje wynik na podstawie odpowiedzi weryfikacyjnej. Sukces: jeśli kod jest poprawny, użytkownik zostaje skierowany do części workflow po uwierzytelnieniu przez warunek sukcesu. Porażka: jeśli kod jest nieprawidłowy, agent może poprosić użytkownika o ponowne podanie kodu lub uruchomić procedurę awaryjną, np. wysłać nowy kod.

Kwestie bezpieczeństwa: wdroż limitowanie liczby żądań, aby zapobiegać próbom brute force; kody powinny krótko działać (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 przechwytywania kodów.

Zacznij korzystać z ElevenAgents do bezpiecznego uwierzytelniania głosowego

Te metody uwierzytelniania to elastyczne elementy składowe, a nie gotowe rozwiązania. Wybór powinien odzwierciedlać twój profil ryzyka, wymogi 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, zachowując równowagę między ochroną a doświadczeniem użytkownika.

ElevenAgents udostępnia opisane wyżej deterministyczne bramkowanie workflow, dispatch tools i zmienne specyficzne dla telefonii, dzięki czemu możesz zbudować 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ś stworzyć pierwszy workflow uwierzytelnionego agenta głosowego.

FAQ: bezpieczne procesy uwierzytelniania tożsamości rozmówców