Bezpieczna dla przeglądarki sztuczna inteligencja w czasie rzeczywistym za pośrednictwem bramy API: tokeny tymczasowe, zasady dzierżawy i kontrola sesji głosowej
Praktyczna architektura dla przeglądarki i mobilnej sztucznej inteligencji głosowej: utrzymuj niskie opóźnienia multimediów w czasie rzeczywistym dzięki krótkotrwałym poświadczeniom klienta, podczas gdy brama wymusza egzekwowanie zasad najemcy, kontroli budżetu, kontroli narzędzi i ścieżek audytu.
Przeglądarki i aplikacje mobilne nie powinny otrzymywać długotrwałych kluczy API dostawcy. Jednak w przypadku sztucznej inteligencji głosowej działającej w czasie rzeczywistym wysyłanie każdego pakietu audio przez bramę może zwiększyć opóźnienia, koszty operacyjne i tryby awarii. Lepszym wzorcem jest utrzymanie bramy w płaszczyźnie kontroli: uwierzytelnianie użytkownika, egzekwowanie zasad dzierżawy, rezerwowanie budżetu, tworzenie wąskich, krótkotrwałych poświadczeń w czasie rzeczywistym i pozwalanie, aby media wrażliwe na opóźnienia korzystały z transportu w czasie rzeczywistym dostawcy, tam gdzie to konieczne.
W tym artykule opisano wzorzec implementacji dla zespołów tworzących agentów głosowych, asystentów połączeń, mobilnych nauczycieli, drugich pilotów wsparcia lub interfejsy głosowe w aplikacji za pośrednictwem bramy API AI. Celem jest bezpieczeństwo przeglądarki bez utraty zarządzania dzierżawą.
Problem: bezpośrednie połączenia w czasie rzeczywistym omijają kontrolę
Zwykły serwer proxy po stronie serwera jest atrakcyjny, ponieważ centralizuje klucze i obserwowalność. W przypadku standardowych żądań tekstowych jest to często właściwy model. Dźwięk w czasie rzeczywistym jest inny. Sesja głosowa może obejmować ciągły sygnał wejściowy z mikrofonu, dwukierunkowe wyjście audio, przerwy, wywołania narzędzi i rygorystyczne oczekiwania dotyczące opóźnień. Przesyłanie wszystkich multimediów przez bramę może przekształcić bramę w przekaźnik multimediów wymagający dużej przepustowości zamiast usługi ustalania zasad i rozliczeń.
Bezpośrednie połączenia przeglądarki z dostawcą rozwiązują opóźnienia, ale tworzą inny problem:
- Przeglądarka nie może bezpiecznie przechowywać klucza API standardowego dostawcy.
- Sprawdzanie budżetu najemcy może zostać pominięte, jeśli aplikacja łączy się bezpośrednio.
- Ograniczenia dotyczące modelu, regionu, głosu, modalności i narzędzi stają się obietnicami po stronie klienta.
- Przypisanie użycia staje się niekompletne lub opóźnione.
- Zespoły ds. bezpieczeństwa tracą możliwy do sprawdzenia punkt decyzyjny przed rozpoczęciem sesji.
Praktyczny projekt nie polega na „proxowaniu każdego bajtu”. Jest to „broker każdej sesji”.
Fakty, rekomendacje i przewidywania
Fakty: Dostawcy sztucznej inteligencji czasu rzeczywistego coraz częściej obsługują transporty o małych opóźnieniach, takie jak WebRTC, WebSocket i SIP. Publiczna dokumentacja interfejsu Realtime API OpenAI opisuje interfejsy czasu rzeczywistego o niskim opóźnieniu, w tym WebRTC. Wskazówki dotyczące WebRTC w czasie rzeczywistym platformy Azure OpenAI opisują aplikację przeglądarki korzystającą z usługi tokenu zaplecza w celu pobrania tokenu tymczasowego przed rozpoczęciem połączenia WebRTC i ostrzegają przed użyciem standardowego klucza interfejsu API w aplikacji klienckiej. Wskazówki dotyczące pakietu SDK OpenAI Agents dotyczące czasu rzeczywistego zalecają również przepływ, w którym backend tworzy krótkotrwały, efemeryczny token klienta, a przeglądarka używa go do nawiązania połączenia WebRTC.
Zalecenia: traktuj bramę jako organ sesji. Powinien decydować, czy może istnieć sesja w czasie rzeczywistym, z jakim modelem, w jakim regionie, dla jakiego najemcy, w ramach jakiego budżetu i za pomocą jakich narzędzi. Klient powinien otrzymać jedynie minimalne, krótkotrwałe dane uwierzytelniające potrzebne do rozpoczęcia zatwierdzonej sesji.
Przewidywania: Interfejsy API dostawców działających w czasie rzeczywistym przez jakiś czas pozostaną nierówne. Okresy istnienia tokenów, pola konfiguracji sesji, elementy sterujące rozłączaniem po stronie serwera, zdarzenia użycia i obsługa regionu będą się różnić. Bramy powinny jawnie modelować możliwości dostawcy, zamiast udawać, że wszystkie interfejsy API czasu rzeczywistego są doskonale przenośne.
Architektura referencyjna: brama jako płaszczyzna sterowania w czasie rzeczywistym
Bezpieczny dla przeglądarki przepływ w czasie rzeczywistym składa się z pięciu części:
- Aplikacja kliencka: przeglądarka lub aplikacja mobilna żądająca sesji głosowej.
- Zaplecze aplikacji: uwierzytelnia użytkownika końcowego i wywołuje bramę lub osadza logikę generowania tokenów bramy, jeśli brama jest częścią stosu zaplecza.
- Brama interfejsu API AI: egzekwuje zasady najemcy, rozwiązuje profil modelu, rezerwuje budżet, rejestruje sesję i tworzy tymczasowy sekret klienta dostawcy.
- Dostawca czasu rzeczywistego: kończy WebRTC lub inny transport w czasie rzeczywistym.
- Księga i statystyki: rozlicza wykorzystanie, gdy dostępne są zdarzenia dostawcy, dane o czasie trwania lub końcowe raporty użycia.
Brama nie musi przekazywać każdej ramki audio, aby zachować wiarygodność. Musi być właścicielem decyzji o utworzeniu sesji i ścieżki uzgadniania.
Zalecany przepływ żądań
- Użytkownik otwiera funkcję głosową w aplikacji klienckiej.
- Klient wywołuje Twój backend:
POST /voice/sessions. - Zaplecze weryfikuje sesję użytkownika i przekazuje żądanie Mint do bramy zawierające identyfikator dzierżawcy, identyfikator użytkownika, zamierzoną funkcję, metadane urządzenia i pochodzenie.
- Brama ocenia politykę i budżet.
- Brama tworzy lokalny rekord
realtime_sessionprzed skontaktowaniem się z dostawcą. - Brama wywołuje dostawcę za pomocą chronionych danych uwierzytelniających środowiska wykonawczego i tworzy efemeryczną sesję w czasie rzeczywistym o wąskim zakresie.
- Brama zwraca do przeglądarki tylko tymczasowy sekret klienta i zatwierdzone metadane sesji.
- Przeglądarka nawiązuje połączenie WebRTC bezpośrednio z dostawcą.
- Brama przetwarza zdarzenia związane z użyciem dostawcy, wywołania zwrotne, wyniki ankiety lub ostrożne szacunki oparte na czasie trwania.
- Księga rozlicza zarezerwowany budżet i zapisuje zdarzenia audytowe.
Sprawdzanie zasad przed premierą
Najważniejszy moment egzekwowania prawa ma miejsce przed wybiciem efemerycznego żetonu. Gdy przeglądarka ma krótkotrwałe dane uwierzytelniające, egzekwowanie w trakcie sesji może być ograniczone, chyba że dostawca obsługuje kontrolę aktualizacji sesji, rozłączania, obserwatora lub wywołania zwrotnego.
Brama powinna co najmniej sprawdzić:
- Stan najemcy: aktywny, zawieszony, próbny, opłacony z góry, zafakturowany lub poddany kwarantannie.
- Uprawnienia użytkownika: czy ten użytkownik może korzystać z głosu w czasie rzeczywistym, a nie tylko z czatu tekstowego.
- Dozwolony profil modelu: zatwierdzony model lub wdrożenie w czasie rzeczywistym, a nie dowolne identyfikatory modelu dostarczone przez klienta.
- Zasady dotyczące regionu i przechowywania: czy wybrany region dostawcy i zestaw funkcji są zgodne z regułami dotyczącymi danych dzierżawcy.
- Maksymalny czas trwania sesji: na przykład według planu 5, 15 lub 30 minut.
- Dozwolone tryby: wejście audio, wyjście audio, tekst, obraz lub wywołania narzędzi.
- Szablon głosu i instrukcji: ustalony lub ograniczony zasadami.
- Dostępny budżet: saldo przedpłacone, zarezerwowany limit miesięczny lub pułap wydatków na funkcję.
- Współbieżność: aktywne sesje głosowe na poziomie dzierżawy i użytkownika.
- Kontrola nadużyć: flagi ryzyka użytkownika, reputacja źródła, nietypowa prędkość połączenia lub wyłącznik awaryjny dzierżawy.
Bezpiecznym ustawieniem domyślnym jest odrzucanie niejednoznacznych żądań. Jeśli klient poprosi o model, narzędzie, głos lub region, którego nie obejmuje polityka czasu rzeczywistego dzierżawcy, brama powinna zwrócić wyraźny błąd zasad zamiast dyskretnie rozszerzać dostęp.
Projekt zapisu sesji
Przed utworzeniem danych uwierzytelniających dostawcy utwórz rekord sesji po stronie bramy. Daje to kotwicę audytu, nawet jeśli utworzenie dostawcy zakończy się pomyślnie, ale przeglądarka nigdy się nie połączy.
{ "session_id": "rt_01j...", "ident_dzierżawcy": "dzierżawa_123", "end_user_id": "user_hash_456", "dostawca": "dostawca_a", "provider_session_id": null, "model_profile": "standard obsługi głosu", "upstream_model_or_deployment": "model-x w czasie rzeczywistym", "region": "wschód", "session_config_hash": "sha256:...", „allowed_modalities”: [„wejście_audio”, „wyjście_audio”], „allowed_tools”: [„lookup_order_status”], "tool_approval_policy": "approve_side_effects", "budget_reservation_id": "resv_789", „max_duration_sekundy”: 900, "issued_at": "2026-08-21T10:00:00Z", "expires_at": "2026-08-21T10:01:00Z", "client_origin": "https://app.example.com", "device_id_hash": "sha256:...", „status”: „bicie”
Domyślnie nie przechowuj nieprzetworzonego dźwięku mikrofonu ani pełnych podpowiedzi. Przechowuj skróty konfiguracji, identyfikatory, decyzje dotyczące zasad i minimalne metadane wystarczające do audytu, pomocy technicznej i rozliczeń. Jeśli wymagane jest nagrywanie, zrób to wyraźnie, uwzględniając zgodę i kierując się zasadami najemcy.
Punkt końcowy bicia tokenów tymczasowych
Punkt końcowy skierowany na bramę może wyglądać tak:
POST /v1/realtime/sessions
Autoryzacja: Nośnik
Typ zawartości: aplikacja/json
{
"ident_dzierżawcy": "dzierżawa_123",
"end_user_id": "user_hash_456",
"feature": "support_voice_agent",
"pochodzenie": "https://aplikacja.example.com",
"device_nonce": "8f3b...",
"requested_profile": "standard obsługi głosu"
Odpowiedź nie powinna ujawniać klucza wykonawczego nadrzędnego:
{ "session_id": "rt_01j...", "dostawca": "dostawca_a", "transport": "webrtc", "client_secret": "efemeryczny_secret_tutaj", "expires_at": "2026-08-21T10:01:00Z", „zatwierdzone”: { "model_profile": "standard obsługi głosu", „max_duration_sekundy”: 900, „modalności”: [„wejście_audio”, „wyjście_audio”], "narzędzia": ["lookup_order_status"] }
Powiąż wystawienie ze źródłem, sesją uwierzytelnionego użytkownika, dzierżawcą i wartością jednorazową. Dostawca może nie obsługiwać natywnie wszystkich tych powiązań, więc egzekwuj wszystko, co możesz na bramie: ograniczaj próby wydawania monet, odrzucaj nieoczekiwane źródła, rejestruj metadane urządzenia i dbaj o krótki czas życia tokena.
Szablony sesji: domyślnie wąskie
Szablon sesji w czasie rzeczywistym powinien być bardziej restrykcyjny niż ogólna prośba o dokończenie czatu. Sesje głosowe są interaktywne, trudniejsze do kontrolowania w czasie rzeczywistym i mogą trwać dłużej, niż oczekiwano.
Zalecane pola szablonu obejmują:
- Stały model lub wdrożenie: wybierane na podstawie profilu modelu po stronie bramy.
- Instrukcje: kontrolowany przez serwer szablon podpowiedzi ze zmiennymi zatwierdzonymi przez najemcę.
- Głos: wybrany z listy dozwolonych.
- Modalności: wyłączaj tryby tekstu, obrazu lub narzędzi, chyba że produkt ich potrzebuje.
- Ustawienia dźwięku wejściowego: wykrywanie włączenia, zachowanie transkrypcji lub obsługa wyciszenia, jeśli jest to obsługiwane.
- Ograniczenia wyjściowe: maksymalna długość odpowiedzi lub zachowanie odpowiedzi, jeśli jest obsługiwane.
- Lista dozwolonych narzędzi: tylko narzędzia wymagane dla tej funkcji.
- Czas trwania sesji: krótki okres ważności danych uwierzytelniających plus maksymalny czas trwania połączenia.
Rygorystyczne szablony zmniejszają elastyczność, ale ułatwiają koszty, zgodność i pomoc techniczną. Jeśli zespoły produktowe potrzebują dynamicznych głosów lub instrukcji, udostępnij kontrolowane warianty profili zamiast przekazywać dostawcom dowolną konfigurację klienta.
Kontrola budżetu dla głosu w czasie rzeczywistym
Wycena wykorzystania w czasie rzeczywistym przed ostatecznym wykorzystaniem usług przez dostawcę może być trudniejsza. Sesja może trwać pięć sekund lub dwadzieścia minut. Może obejmować wejście audio, wyjście audio, transkrypcję, wywołania narzędzi i tokeny tekstowe. Bramka powinna zatem łączyć rezerwację, ograniczenia i uzgadnianie.
Przed wybiciem
- Oszacuj najgorszy lub konserwatywny koszt sesji na podstawie maksymalnego czasu trwania, modelu, warunków i planu najemcy.
- Zarezerwuj budżet przed wydaniem klucza tajnego klienta.
- Odrzuć nowe sesje, jeśli najemca nie ma wystarczającej równowagi lub osiągnął dzienny limit głosu.
W trakcie sesji
- Śledź aktywne sesje i oczekiwane tempo spalania.
- Zastosuj ograniczenia współbieżności dzierżawy i użytkownika.
- Użyj obsługiwanych przez dostawcę funkcji kończenia lub aktualizacji sesji, jeśli są dostępne.
- Wyzwalaj alerty w przypadku nieprawidłowego czasu trwania sesji, powtarzających się ponownych połączeń lub nietypowego użycia głosu.
Po sesji
- Przechwytuj zdarzenia użycia dostawcy lub końcowe raporty użycia, jeśli są dostępne.
- Rozlicz zarezerwowany budżet z kosztem rzeczywistym.
- Jeśli dokładne wykorzystanie jest opóźnione lub niekompletne, zachowaj konserwatywną rezerwację do czasu uzgodnienia.
- Przypisz użycie do dzierżawcy, użytkownika, funkcji, profilu modelu i identyfikatora sesji.
Jest to mniej dokładne niż synchroniczne naliczanie opłat za SMS w momencie odpowiedzi, ale jest bezpieczniejsze operacyjnie niż wydawanie bezpośrednich danych uwierzytelniających bez zastrzeżeń.
Wywołania narzędzi w sesjach w czasie rzeczywistym
Agenci głosowi działający w czasie rzeczywistym często stają się bardziej przydatni, gdy mogą wywoływać narzędzia: przeszukiwać konto, rezerwować spotkanie, aktualizować zgłoszenie lub uruchamiać przepływ pracy. Traktuj wykonanie narzędzia oddzielnie od transportu audio.
Połączenie multimedialne przeglądarki nie powinno oznaczać pozwolenia na wykonywanie efektów ubocznych. Brama lub backend powinny wymuszać:
- Rejestr narzędzi: każde narzędzie ma właściciela, schemat, zakresy i poziom ryzyka.
- Listy dozwolonych: szablony sesji zawierają dokładną listę dostępnych narzędzi.
- Bramy zatwierdzające: działania uboczne wymagają potwierdzenia użytkownika, zgody człowieka lub zatwierdzenia zasad.
- Oddzielne dane uwierzytelniające: dane uwierzytelniające narzędzia nigdy nie są osadzane w sesji przeglądarki.
- Dołączona ścieżka audytu: każde wywołanie narzędzia odwołuje się do identyfikatora sesji w czasie rzeczywistym.
Na przykład agent pomocy głosowej może mieć możliwość automatycznego wywoływania lookup_order_status, ale refund_payment może wymagać wyraźnego potwierdzenia i zdarzenia zatwierdzenia zaplecza. Dostawca czasu rzeczywistego może zorganizować rozmowę, ale Twoja brama powinna regulować granice uprawnień.
Widoczność bez proxy każdego bajtu
Bezpośredni przepływ multimediów WebRTC zmniejsza opóźnienia bramy i obciążenie przepustowości, ale widoczność staje się bardziej zależna od zdarzeń dostawcy i własnych metadanych sesji. Projektuj analizy w oparciu o wiele źródeł dowodów:
- Rekordy tworzenia sesji z bramy.
- Zdarzenia cyklu życia po stronie klienta, takie jak połączenie, rozłączenie, próba ponownego połączenia, odmowa dostępu do mikrofonu lub zakończenie połączenia.
- Identyfikatory sesji dostawcy, zdarzenia użycia lub końcowe zapisy użytkowania.
- Szacunki oparte na czasie trwania w przypadku opóźnienia w korzystaniu z usług dostawcy.
- Dzienniki wywołań narzędzi połączone identyfikatorem sesji.
- Ewidencja rezerwacji i rozliczeń budżetu.
Nie czekaj na idealną telemetrię dostawcy przed uruchomieniem kontroli. Zacznij od konserwatywnych rezerwacji i jasnego przypisania, a następnie zwiększ dokładność rozliczeń w miarę dojrzewania raportów dotyczących wykorzystania dostawcy.
Lista kontrolna bezpieczeństwa
- Nigdy nie wysyłaj kluczy API standardowego dostawcy do przeglądarki lub klientów mobilnych.
- Używaj krótkotrwałych, efemerycznych sekretów klienta do uruchamiania sesji w czasie rzeczywistym.
- Uwierzytelnij użytkownika końcowego przed wybiciem tokena.
- Jeśli to możliwe, powiąż decyzje dotyczące mennictwa z dzierżawcą, użytkownikiem, źródłem, wartością jednorazową i metadanymi urządzenia.
- Przechowuj poświadczenia środowiska wykonawczego dostawcy w skarbcu zaplecza lub tajnym magazynie bramy.
- Zarejestruj wiersz audytu sesji przed wybraniem dostawcy.
- Używaj szablonów sesji zatwierdzonych przez dzierżawcę zamiast dowolnej konfiguracji klienta.
- Zastosuj limity współbieżności, dziennego użycia i maksymalnego czasu trwania.
- Skorzystaj z list dozwolonych narzędzi i bramek zatwierdzeń, aby uniknąć skutków ubocznych.
- Domyślnie minimalizuj zachowywanie nieprzetworzonych podpowiedzi i dźwięku.
- Utrzymuj macierz możliwości dostawcy pod kątem czasów życia tokenów, regionów, narzędzi, zdarzeń użycia i kontroli zakończenia.
Macierz możliwości dostawcy
Ponieważ interfejsy API czasu rzeczywistego różnią się od siebie, modeluj adapter bramy w oparciu o możliwości, a nie założenia. Prosta macierz może wpływać na decyzje dotyczące routingu i polityki:
{ "dostawca_a": { "transporty": ["webrtc", "websocket"], „ephemeral_client_tokens”: prawda, „token_ttl_sekundy”: 60, „server_side_disconnect”: prawda, „session_update”: prawda, "usage_events": "ostateczny i_przyrostowy", „regiony”: [„nas”, „eu”], „tool_approval_supported”: prawda }, "dostawca_b": { "transporty": ["websocket"], „ephemeral_client_tokens”: prawda, „token_ttl_sekundy”: 120, „server_side_disconnect”: fałsz, „session_update”: fałsz, "usage_events": "final_only", „regiony”: [„nas”], „tool_approval_supported”: fałsz }
Jeśli dzierżawca wymaga miejsca zamieszkania w UE i zakończenia po stronie serwera, brama powinna kierować tylko do dostawców i wdrożeń spełniających oba wymagania. Jeśli żaden dostawca nie spełnia tych zasad, awaria zostaje zamknięta.
Ścieżka migracji
Nie musisz tworzyć wszystkich elementów sterujących od pierwszego dnia. Praktyczne wdrożenie to:
- Tylko tworzenie sesji proxy: zapewnia bezpośredni dostęp do multimediów, ale wymaga, aby wszystkie sesje w czasie rzeczywistym były uruchamiane przez backend lub bramę.
- Dodaj szablony zasad: zamień dostarczony przez klienta model i pola instrukcji na zatwierdzone profile.
- Dodaj rezerwację budżetu: zarezerwuj konserwatywny koszt sesji przed wydaniem tokena.
- Dodaj analizę cyklu życia: zbieraj dane dotyczące rozpoczęcia sesji, połączenia, rozłączenia, czasu trwania, identyfikatora sesji dostawcy i statusu rozliczenia.
- Dodaj zarządzanie narzędziami: wymagaj list dozwolonych i zatwierdzeń dla wywołań narzędzi w czasie rzeczywistym.
- Dodaj routing możliwości dostawcy: wybierz dostawców według regionu, modalności, obsługi zdarzeń i kontroli zakończenia.
- Dodaj opcjonalne przepływy pracy obserwatora lub nagrywania: tylko w przypadku zgodności, zgody i zgody najemcy.
Wniosek, który można zastosować
W przypadku sztucznej inteligencji głosowej działającej w czasie rzeczywistym brama API AI nie powinna automatycznie stać się przekaźnikiem multimediów. Bezpieczniejsza architektura o niższych opóźnieniach polega na utrzymywaniu bramy odpowiedzialnej za płaszczyznę kontroli: uwierzytelnianie użytkowników, egzekwowanie zasad dzierżawy, rezerwowanie budżetu, tworzenie rekordu audytu, tworzenie tymczasowych poświadczeń o wąskim zakresie i uzgadnianie wykorzystania po sesji.
Podstawowa zasada implementacji jest prosta: przeglądarki mogą otrzymywać krótkotrwałe sekrety sesji, a nigdy długotrwałe klucze dostawcy. Wszystko inne wynika z tej granicy: ścisłe szablony, bicie uwzględniające pochodzenie, ograniczenia sesji równoczesnych, zatwierdzenia narzędzi, rozliczanie użytkowania i macierze możliwości dostawców. Dzięki temu zespoły produktowe mogą korzystać z usług głosowych w czasie rzeczywistym bez konieczności rezygnacji z zarządzania kluczami API, kontroli kosztów API AI, zarządzania API zespołu czy analityki wykorzystania AI.