Безопасен за браузър AI в реално време чрез API шлюз: Ефемерни токени, политика на клиента и контроли на гласови сесии

Браузърите и мобилните приложения не трябва да получават дълготрайни API ключове на доставчика. За гласов AI в реално време обаче изпращането на всеки аудио пакет през шлюз може да добави латентност, оперативни разходи и режими на повреда. По-добрият модел е да запазите шлюза в контролната равнина: удостоверете потребителя, наложете политиката на наемателя, резервирайте бюджет, изсечете тесни краткотрайни идентификационни данни в реално време и оставете чувствителните към забавяне медии да използват транспорта в реално време на доставчика, където е подходящо.

Тази статия описва модел на внедряване за екипи, изграждащи гласови агенти, асистенти за обаждания, мобилни преподаватели, помощни пилоти или гласови интерфейси в приложението чрез шлюз на AI API. Целта е безопасността на браузъра, без да се губи управлението на клиента.

Проблемът: директните връзки в реално време заобикалят вашите контроли

Обикновеният сървърен прокси е привлекателен, защото централизира ключовете и възможността за наблюдение. За стандартни текстови заявки това често е правилният модел. Аудиото в реално време е различно. Гласовата сесия може да включва непрекъснат вход от микрофона, двупосочен аудио изход, прекъсвания, извиквания на инструменти и строги очаквания за латентност. Проксирането на цялата медия през вашия шлюз може да превърне шлюза в медийно предаване с голяма честотна лента, вместо в услуга за политика и таксуване.

Директните връзки браузър-доставчик решават забавянето, но създават различен проблем:

• Браузърът не може безопасно да поддържа стандартен API ключ на доставчик.
• Проверките на бюджета на наемателя може да бъдат пропуснати, ако приложението се свързва директно.
• Ограниченията за модел, регион, глас, модалност и инструменти стават обещания от страна на клиента.
• Приписването на използването става непълно или забавено.
• Екипите по сигурността губят подлежаща на проверка точка за вземане на решение преди началото на сесията.

Практическият дизайн не е „прокси всеки байт“. Той е „брокер на всяка сесия“.

Факти, препоръки и прогнози

Факти: Доставчиците на AI в реално време все повече поддържат транспорти с ниска латентност като WebRTC, WebSocket и SIP. Публичната документация за API за реално време на OpenAI описва интерфейси с ниска латентност в реално време, включително WebRTC. Насоките за WebRTC в реално време на Azure OpenAI описват приложение за браузър, използващо услуга за бекенд токен за извличане на краткотраен токен преди стартиране на WebRTC връзката и предупреждава срещу използването на стандартен API ключ в клиентско приложение. Указанията за OpenAI Agents SDK в реално време също препоръчват поток, при който бекендът създава краткотраен ефимерен клиентски токен и браузърът го използва, за да установи WebRTC връзка.

Препоръки: Третирайте шлюза като орган за управление на сесията. Той трябва да реши дали може да съществува сесия в реално време, с кой модел, в кой регион, за кой наемател, при кой бюджет и с какви инструменти. Клиентът трябва да получи само минималните краткотрайни идентификационни данни, необходими за стартиране на тази одобрена сесия.

Прогнози: API на доставчиците в реално време ще останат неравномерни за известно време. Животът на токена, полетата за конфигурация на сесията, контролите за прекъсване на връзката от страната на сървъра, събитията за използване и поддръжката на региона ще се различават. Шлюзовете трябва изрично да моделират възможностите на доставчика, вместо да се преструват, че всички API в реално време са перфектно преносими.

Референтна архитектура: шлюз като контролна равнина в реално време

Потокът в реално време, безопасен за браузър, има пет части:

1. Клиентско приложение: Браузър или мобилно приложение, изискващо гласова сесия.
2. Бекенд на приложението: Удостоверява крайния потребител и извиква шлюза или вгражда логика за изсичане на токени на шлюза, ако шлюзът е част от стека на бекенда.
3. Шлюз на AI API: Налага политиката на клиента, разрешава профил на модела, резервира бюджет, записва сесията и изсича краткотрайна клиентска тайна на доставчик.
4. Доставчик в реално време: Прекратява WebRTC или друг транспорт в реално време.
5. Книга и анализи: Урежда използването, след като са налични събития от доставчика, данни за продължителността или окончателни отчети за използване.

Шлюзът не трябва да предава всеки аудио кадър, за да остане авторитетен. Той трябва да притежава решението за създаване на сесия и пътя за съгласуване.

Препоръчителен поток от заявки

1. Потребителят отваря гласова функция в клиентското приложение.
2. Клиентът извиква вашия бекенд: POST /voice/sessions.
3. Бекендът проверява потребителската сесия и препраща минимална заявка към шлюза с ИД на клиента, потребителски ИД, предназначена функция, метаданни на устройството и произход.
4. Шлюзът оценява политиката и бюджета.
5. Шлюзът създава локален запис realtime_session, преди да се свърже с доставчика.
6. Шлюзът се обажда на доставчика със своите защитени идентификационни данни за изпълнение и създава краткотрайна сесия в реално време с тесен обхват.
7. Шлюзът връща на браузъра само краткотрайната клиентска тайна и метаданните за одобрената сесия.
8. Браузърът установява WebRTC връзка директно с доставчика.
9. Шлюзът поглъща събития за използване на доставчика, обратни повиквания, резултати от анкети или консервативни оценки, базирани на продължителност.
10. Главната книга урежда резервирания бюджет и записва одитни събития.

Проверки на политиката преди мен

Най-важната точка на прилагане е преди изсичането на ефимерния токен. След като браузърът има краткотрайни идентификационни данни, налагането по средата на сесията може да бъде ограничено, освен ако доставчикът не поддържа актуализация на сесията, прекъсване на връзката, наблюдател или контроли за обратно извикване.

Шлюзът трябва да провери най-малко:

• Статус на наемател: активен, спрян, пробен, предплатен, фактуриран или поставен под карантина.
• Права на потребителя: дали този потребител може да използва гласов чат в реално време, а не само текстов чат.
• Позволен профил на модел: одобрен модел или внедряване в реално време, а не произволни идентификационни номера на модели, предоставени от клиента.
• Правила за регион и задържане: дали избраният регион на доставчик и набор от функции отговарят на правилата за данни на клиента.
• Максимална продължителност на сесията: например 5, 15 или 30 минути по план.
• Разрешени модалности: аудио вход, аудио изход, текст, изображение или извиквания на инструменти.
• Шаблон за гласови и инструкции: фиксирани или ограничени от правилата.
• Наличен бюджет: предплатен баланс, запазена месечна надбавка или таван на разходите за всяка функция.
• Едновременност: активни гласови сесии на ниво наемател и на ниво потребител.
• Контрол на злоупотреба: сигнали за потребителски риск, репутация на произход, необичайна скорост на повикване или превключвател за изключване на клиента.

Безопасно по подразбиране е да се отхвърлят двусмислени заявки. Ако клиентът поиска модел, инструмент, глас или регион, който не е в политиката в реално време на наемателя, шлюзът трябва да върне ясна грешка в политиката, вместо тихо да разширява достъпа.

Дизайн на запис на сесия

Създайте запис на сесия от страна на шлюза, преди да изсечете идентификационните данни на доставчика. Това ви дава закрепване за проверка дори ако създаването на доставчик е успешно, но браузърът никога не се свързва.

<пре><код>{ "session_id": "rt_01j...", "tenant_id": "tenant_123", "end_user_id": "user_hash_456", "доставчик": "доставчик_a", "provider_session_id": нула, "model_profile": "стандарт за поддръжка на глас", "upstream_model_or_deployment": "модел-x в реално време", "регион": "изток", "session_config_hash": "sha256:...", "allowed_modalities": ["audio_input", "audio_output"], "allowed_tools": ["lookup_order_status"], "tool_approval_policy": "одобрени_странични_ефекти", "budget_reservation_id": "resv_789", "max_duration_seconds": 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:...", "статус": "сечене" }

По подразбиране не съхранявайте сурово аудио от микрофона или пълни подкани. Съхранявайте конфигурационни хешове, идентификатори, решения за политики и минимални метаданни, достатъчни за одит, поддръжка и таксуване. Ако се изисква записване, направете го изрично, съобразено със съгласието и управлявано от правилата на наемателя.

Крайна точка за сечене на ефемерни токени

Крайна точка, обърната към шлюза, може да изглежда така:

POST /v1/realtime/sessions
Упълномощаване: Носител 
Тип съдържание: приложение/json
{
  "tenant_id": "tenant_123",
  "end_user_id": "user_hash_456",
  "функция": "гласов_агент за поддръжка",
  "произход": "https://app.example.com",
  "device_nonce": "8f3b...",
  "requested_profile": "стандарт за поддръжка на глас"
}

Отговорът не трябва да разкрива вашия ключ за изпълнение нагоре:

<пре><код>{ "session_id": "rt_01j...", "доставчик": "доставчик_a", "транспорт": "webrtc", "client_secret": "ефимерна_тайна_тук", "expires_at": "2026-08-21T10:01:00Z", "одобрено": { "model_profile": "стандарт за поддръжка на глас", "max_duration_seconds": 900, "modalities": ["audio_input", "audio_output"], "инструменти": ["търсене_състояние_на_поръчка"] } }

Свържете издаването с произход, удостоверена потребителска сесия, клиент и nonce. Доставчикът може да не поддържа всички тези обвързвания първоначално, така че наложете каквото можете на шлюза: ограничаване на опитите за монетизиране на скоростта, отхвърляне на неочаквани източници, записване на метаданни на устройството и поддържане на кратък живот на токена.

Шаблони за сесии: тесни по подразбиране

Шаблонът за сесия в реално време трябва да бъде по-рестриктивен от обща заявка за завършване на чат. Гласовите сесии са интерактивни, по-трудни за проверка в реално време и могат да продължат по-дълго от очакваното.

Препоръчителните полета на шаблона включват:

• Фиксиран модел или внедряване: избран от профил на модел от страната на шлюза.
• Инструкции: контролиран от сървъра шаблон за подкана с одобрени от клиента променливи.
• Глас: избран от списък с разрешени.
• Модалности: деактивирайте режимите на текст, изображение или инструменти, освен ако продуктът не се нуждае от тях.
• Настройки за входно аудио: разпознаване на завъртане, поведение на транскрипция или обработка на тишина, където се поддържа.
• Ограничения на изхода: максимална дължина на отговора или поведение на отговора, където се поддържа.
• Списък с разрешени инструменти: само инструменти, необходими за функцията.
• Живот на сесията: кратко изтичане на идентификационните данни плюс максимална продължителност на разговора.

Строгите шаблони намаляват гъвкавостта, но улесняват разходите, съответствието и поддръжката. Ако продуктовите екипи се нуждаят от динамични гласове или инструкции, изложете контролирани варианти на профили, вместо да предавате произволна клиентска конфигурация на доставчика.

Бюджетни контроли за глас в реално време

Използването в реално време може да бъде по-трудно да се определи, преди да пристигне окончателното потребление от доставчика. Една сесия може да продължи пет секунди или двадесет минути. Може да включва аудио вход, аудио изход, транскрипция, извиквания на инструменти и текстови токени. Следователно шлюзът трябва да комбинира резервация, ограничения и съгласуване.

Преди сечене

• Оценете най-лошия случай или консервативната цена на сесията от максималната продължителност, модела, модалностите и плана на наемателя.
• Запазете бюджет, преди да издадете клиентската тайна.
• Отхвърляне на нови сесии, ако наемателят няма достатъчен баланс или е достигнал дневните гласови ограничения.

По време на сесията

• Проследявайте активните сесии и очакваната скорост на записване.
• Прилагане на ограничения за едновременност на клиенти и потребители.
• Използвайте поддържани от доставчика функции за прекратяване или актуализиране на сесия, ако има такива.
• Задейства предупреждения за необичайна продължителност на сесията, многократни повторни свързвания или необичайно използване на глас.

След сесията

• Поглъщане на събития за използване на доставчика или окончателни отчети за използване, когато има такива.
• Уредете резервирания бюджет спрямо действителните разходи.
• Ако точното използване е забавено или непълно, задръжте консервативна резервация до съгласуване.
• Приписване на използването на наемател, потребител, функция, профил на модел и идентификатор на сесия.

Това е по-малко точно от синхронното текстово таксуване в момента на отговора, но е оперативно по-безопасно от издаването на директни идентификационни данни без резервация.

Извиквания на инструменти в сесии в реално време

Гласовите агенти в реално време често стават по-полезни, когато могат да извикват инструменти: да търсят акаунт, да резервират среща, да актуализират билет или да активират работен процес. Третирайте изпълнението на инструмента отделно от аудио транспорта.

Медийната връзка на браузъра не трябва да предполага разрешение за извършване на странични ефекти. Шлюзът или задната част трябва да наложи:

• Регистър на инструментите: всеки инструмент има собственик, схема, обхват и ниво на риск.
• Списъци с разрешени: шаблоните за сесии изброяват точно кои инструменти са налични.
• Пропуски за одобрение: страничните действия изискват потвърждение от потребителя, одобрение от човек или одобрение от правила.
• Отделни идентификационни данни: идентификационните данни на инструмента никога не се вграждат в сесията на браузъра.
• Обединена одитна пътека: всяко извикване на инструмент препраща към идентификатора на сесията в реално време.

Например, на гласов агент за поддръжка може да бъде разрешено автоматично да извиква lookup_order_status, но refund_payment може да изисква изрично потвърждение и събитие за одобрение в задната част. Доставчикът в реално време може да организира разговора, но вашият шлюз трябва да управлява границата на разрешенията.

Видимост без проксиране на всеки байт

Директният медиен поток WebRTC намалява латентността на шлюза и натоварването на честотната лента, но видимостта става по-зависима от събитията на доставчика и метаданните на вашата собствена сесия. Проектирайте анализи около множество източници на доказателства:

• Записи за създаване на сесии от шлюза.
• Събития от жизнения цикъл от страна на клиента, като свързване, прекъсване на връзката, опит за повторно свързване, отказан микрофон или прекратено повикване.
• Идентификационни номера на сесии на доставчика, събития за използване или окончателни записи за използване.
• Оценки въз основа на продължителността, когато използването на доставчика е забавено.
• Дневници на повиквания на инструменти, обединени чрез идентификатор на сесия.
• Бюджетни резервации и записи за сетълмент.

Не чакайте перфектна телеметрия на доставчика, преди да стартирате контролите. Започнете с консервативни резерви и ясно приписване, след което подобрете точността на сетълмента, докато отчитането на използването на доставчика узрее.

Списък за проверка на сигурността

• Никога не изпращайте ключове за API на стандартни доставчици към браузър или мобилни клиенти.
• Използвайте краткотрайни ефимерни клиентски тайни за стартиране на сесия в реално време.
• Удостоверете автентичността на крайния потребител преди изсичане на токени.
• Свържете решенията за копаене с метаданни за наемател, потребител, източник, nonce и устройство, където е възможно.
• Съхранявайте идентификационните данни на доставчика по време на изпълнение в хранилище на бекенд или тайно хранилище на шлюза.
• Запишете ред за одит на сесия преди изсичане на доставчик.
• Използвайте шаблони за сесии, одобрени от клиента, вместо произволна клиентска конфигурация.
• Прилагане на лимити за едновременност, дневно използване и максимална продължителност.
• Използвайте списъци с разрешени инструменти и пропуски за одобрение за странични ефекти.
• Минимизиране на необработените подкани и задържането на звука по подразбиране.
• Поддържане на матрица на възможностите на доставчика за живот на токена, региони, инструменти, събития на използване и контроли за прекратяване.

Матрица на възможностите на доставчика

Тъй като приложните програмни интерфейси (API) в реално време се различават, моделирайте своя адаптер за шлюз въз основа на възможностите, а не на предположенията. Една проста матрица може да ръководи решенията за маршрутизиране и политики:

<пре><код>{ "доставчик_a": { "transports": ["webrtc", "websocket"], "ephemeral_client_tokens": вярно, "token_ttl_seconds": 60, "server_side_disconnect": вярно, "session_update": вярно, "usage_events": "окончателни_и_допълнителни", "regions": ["us", "eu"], "tool_approval_supported": вярно }, "provider_b": { "transports": ["websocket"], "ephemeral_client_tokens": вярно, "token_ttl_seconds": 120, "server_side_disconnect": невярно, "session_update": невярно, "usage_events": "само окончателно", "региони": ["нас"], "tool_approval_supported": невярно } }

Ако наемателят изисква пребиваване в ЕС и прекратяване от страна на сървъра, шлюзът трябва да насочва само към доставчици и внедрявания, които удовлетворяват и двете. Ако никой доставчик не отговаря на правилата, неуспешно затваряне.

Път на миграция

Не е необходимо да създавате всяка контрола в първия ден. Практическо внедряване е:

1. Само създаване на прокси сесия: поддържайте медиите директни, но изисквайте всички сесии в реално време да бъдат изсечени от бекенда или шлюза.
2. Добавете шаблони за правила: заменете предоставените от клиента полета за модел и инструкции с одобрени профили.
3. Добавяне на бюджетна резервация: запазване на умерени разходи за сесия преди издаване на токен.
4. Добавяне на анализ на жизнения цикъл: събиране на начало на сесия, свързване, прекъсване на връзката, продължителност, идентификатор на сесия на доставчик и състояние на сетълмент.
5. Добавете управление на инструмента: изисквайте списъци с разрешени и одобрения за извиквания на инструменти в реално време.
6. Добавете маршрутизиране на възможностите на доставчика: изберете доставчици по регион, модалност, поддръжка на събития и контроли за прекратяване.
7. Добавяне на незадължителен наблюдател или работни потоци за запис: само когато е съвместимо, дадено съгласие и одобрено от наемател.

Изпълнимо заключение

За гласов изкуствен интелект в реално време шлюзът на API за изкуствен интелект не трябва автоматично да се превръща в медийно предаване. По-безопасната архитектура с по-ниска латентност е да поддържа шлюза да отговаря за контролната равнина: удостоверяване на потребители, прилагане на политика за наематели, резервиране на бюджет, създаване на одитен запис, изсичане на ефимерни идентификационни данни с тесен обхват и съгласуване на използването след сесията.

Основното правило за внедряване е просто: браузърите може да получават краткотрайни тайни за сесии, никога дълготрайни ключове на доставчик. Всичко останало следва от тази граница: стриктни шаблони, сечене с отчитане на произхода, ограничения за едновременни сесии, одобрения на инструменти, уреждане на използване и матрици за възможности на доставчика. Това дава на екипите на продуктите гласови изживявания в реално време, без да се отказват от управлението на API ключове, AI API контрол на разходите, управление на екипни API или анализи на използването на AI. хранилище за идентификационни данни за ключове за изпълнение

резервация на бюджет и книга за сетълмент