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

Agenci głosowi szybko zmieniają się z prostych systemów odpowiadających na FAQ w systemy, które wykonują działania: modyfikują konta, przetwarzają transakcje i uzyskują dostęp do wrażliwych danych klientów. Ta zmiana rodzi 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 równie rygorystycznie jak ludzkie centra obsługi, lecz wyłącznie głosowo. W przeciwieństwie do ludzkich agentów, którzy działają zgodnie z zasadami 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 firm. Omówimy pięć głównych podejść — od uwierzytelniania opartego na sesji dla osadzonych widgetów po metody specyficzne dla telefonii i weryfikację OTP — oraz wyjaśnimy, jak wdrożyć każde z nich przez deterministyczne bramkowanie workflow na platformie ElevenLabs.

Co najważniejsze, pokażemy, dlaczego uwierzytelniania nie można pozostawić wnioskowaniu z rozmowy. Zamiast tego należy je oprzeć na odizolowanych podagentach, weryfikacji narzędziowej i warunkowym kierowaniu workflow, aby tylko uwierzytelnieni użytkownicy trafiali do operacji uprzywilejowanych.

Podsumowanie

• Uwierzytelnianie dzwoniących przez agentów głosowych musi być deterministyczne i oparte na narzędziach; nie może zależeć od wnioskowania LLM z rozmowy.
• Uwierzytelnianie przez aplikację hostującą przekazuje agentowi istniejące dane sesji, więc użytkownicy, którzy są już zalogowani, nie muszą uwierzytelniać się ponownie.
• Uwierzytelnianie oparte na wiedzy weryfikuje dane podane przez dzwoniącego, takie jak numer konta czy data urodzenia, względem systemu backendowego przez wywołanie narzędzia po stronie serwera.
• Wdrożenia telefoniczne mogą używać systemowych zmiennych dynamicznych, takich jak caller ID, do cichego uwierzytelniania, ale należy połączyć je z drugim czynnikiem, ponieważ caller ID 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ą.

Architektura deterministycznego uwierzytelniania

Aby zapewnić dostęp do informacji o koncie wyłącznie uwierzytelnionym użytkownikom, zalecamy ścisłe oddzielenie środowisk i dostępu za pomocą workflow ElevenLabs. Uwierzytelnianie zawsze należy wdrażać przez wywołanie narzędzia z logicznym wynikiem powodzenia lub niepowodzenia, skonfigurowanego 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 przekazywania. 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 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 przez platformę ElevenLabs. Możesz je wdrożyć za pomocą narzędzi po stronie serwera, które integrują się z Twoim 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, 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 ze zintegrowanych systemów bez osobnego uwierzytelniania.

Umożliwia to płynną obsługę, ponieważ użytkownik został już zweryfikowany przez aplikację hostującą. Możesz to skonfigurować ręcznie albo użyć widgetu ElevenLabs, w którym przekazujesz zmienne podczas 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 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) sprawdza te wartości względem Twojej bazy danych (np. CRM lub bazy tożsamości). Narzędzie zwraca wynik powodzenia/niepowodzenia, obejmują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 transferu w workflow, które rozgałęziają się zależnie od statusu powodzenia/niepowodzenia 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 agenta.

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 nich za pomocą podwójnych nawiasów klamrowych, np. {{system__caller_id}} — zostaną zastąpione rzeczywistymi wartościami.
2. W parametrach narzędzia: Skonfiguruj parametry narzędzia tak, aby używały tych zmiennych, co pozwala na ciche uwierzytelnianie bez wspominania o nich w prompcie.

Możesz na przykład skonfigurować narzędzie tak, aby automatycznie przekazywało caller ID do endpointu wyszukiwania w CRM. Agent może wtedy po cichu sprawdzić, czy numer przychodzący odpowiada zarejestrowanemu numerowi klienta na potrzeby uwierzytelniania użytkownika. Zamiast wywołania narzędzia uwierzytelnianie możesz też skonfigurować jako webhook inicjujący rozmowę, który wykona się 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 caller ID 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 i 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 dzwoniący poprawnie odpowie na wcześniej określoną liczbę pytań. Możesz polecić agentowi wybieranie losowych pytań z wcześniej zdefiniowanej listy (np. data urodzenia, kod pocztowy, imię zwierzęcia) i sprawdzanie odpowiedzi dzwoniącego przez wywołanie narzędzia do Twojej 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 pobierana 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 uwierzytelniania.

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 następnie przekazać kod agentowi do weryfikacji.

Oto szczegółowy przebieg wdrożenia:

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 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 za pomocą drugiego wywołania narzędzia. Backend sprawdza, czy kod jest zgodny, nie wygasł i nie został już użyty.
4. Kierowanie workflow: Agent obsługuje wynik na podstawie odpowiedzi weryfikacyjnej. Powodzenie: jeśli kod jest prawidłowy, użytkownik trafia do części workflow po uwierzytelnieniu dzięki warunkowi powodzenia. Niepowodzenie: jeśli kod jest nieprawidłowy, agent może poprosić użytkownika o ponowne podanie kodu albo uruchomić procedurę awaryjną (np. wysłać nowy kod).

Kwestie bezpieczeństwa: aby zapobiec próbom brute-force, wdroż ograniczanie liczby żądań. 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, by 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, a nie gotowe rozwiązania. Wybór powinien zależeć od twojego profilu ryzyka, wymogów prawnych i celów związanych 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 zachowując równowagę między ochroną a wygodą użytkownika.

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

FAQ o bezpiecznych procesach uwierzytelniania tożsamości dzwoniących