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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Клиентско приложение: Браузър или мобилно приложение изисква гласова сесия.
2. Бекенд на приложението: Удостоверява крайния потребител и извиква шлюза или вгражда логика за изсичане на токени на шлюза, ако шлюзът е част от стека на бекенда.
3. AI API gateway: Налага политиката на клиента, разрешава профил на модела, резервира бюджет, записва сесията и изсича краткотрайна клиентска тайна на доставчик.
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",
  "provider": "provider_a",
  "provider_session_id": null,
  "model_profile": "voice-support-standard",
  "upstream_model_or_deployment": "realtime-model-x",
  "region": "eastus",
  "session_config_hash": "sha256:...",
  "allowed_modalities": ["audio_input", "audio_output"],
  "allowed_tools": ["lookup_order_status"],
  "tool_approval_policy": "approve_side_effects",
  "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:...",
  "status": "minting"
}

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

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

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

POST /v1/realtime/sessions
Authorization: Bearer <gateway_app_token>
Content-Type: application/json

{
  "tenant_id": "tenant_123",
  "end_user_id": "user_hash_456",
  "feature": "support_voice_agent",
  "origin": "https://app.example.com",
  "device_nonce": "8f3b...",
  "requested_profile": "voice-support-standard"
}

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

{
  "session_id": "rt_01j...",
  "provider": "provider_a",
  "transport": "webrtc",
  "client_secret": "ephemeral_secret_here",
  "expires_at": "2026-08-21T10:01:00Z",
  "approved": {
    "model_profile": "voice-support-standard",
    "max_duration_seconds": 900,
    "modalities": ["audio_input", "audio_output"],
    "tools": ["lookup_order_status"]
  }
}

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

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

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

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

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

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

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

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

Преди сечене

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

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

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

След сесията

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

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

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

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

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

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

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

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

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

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

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

Контролен списък за сигурност

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

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

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

{
  "provider_a": {
    "transports": ["webrtc", "websocket"],
    "ephemeral_client_tokens": true,
    "token_ttl_seconds": 60,
    "server_side_disconnect": true,
    "session_update": true,
    "usage_events": "final_and_incremental",
    "regions": ["us", "eu"],
    "tool_approval_supported": true
  },
  "provider_b": {
    "transports": ["websocket"],
    "ephemeral_client_tokens": true,
    "token_ttl_seconds": 120,
    "server_side_disconnect": false,
    "session_update": false,
    "usage_events": "final_only",
    "regions": ["us"],
    "tool_approval_supported": false
  }
}

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

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

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

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

Приложимо заключение

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

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

Свързано четене

• хранище за идентификационни данни на доставчика за време на изпълнение ключове
• резервация на бюджета и счетоводна книга