Webbläsarsäker realtids-AI genom en API-gateway: tillfälliga tokens, hyresgästpolicy och röstsessionskontroller

Webbläsar- och mobilappar bör inte ta emot långlivade API-nycklar från leverantörer. För röst-AI i realtid kan dock att skicka varje ljudpaket genom en gateway lägga till latens, driftskostnader och fellägen. Det bättre mönstret är att hålla gatewayen i kontrollplanet: autentisera användaren, upprätthålla hyresgästpolicyn, reservera budget, skapa en smal kortlivad realtidsinformation och låta latenskänsliga media använda leverantörens realtidstransport där så är lämpligt.

Den här artikeln beskriver ett implementeringsmönster för team som bygger röstagenter, samtalsassistenter, mobillärare, supportcopiloter eller röstgränssnitt i appen genom en AI API-gateway. Målet är webbläsarsäkerhet utan att tappa hyresgäststyrning.

Problemet: direkta realtidsanslutningar kringgår dina kontroller

En vanlig proxyserver på serversidan är attraktiv eftersom den centraliserar nycklar och observerbarhet. För vanliga textförfrågningar är det ofta rätt modell. Realtidsljud är annorlunda. En röstsession kan involvera kontinuerlig mikrofoninmatning, dubbelriktad ljudutgång, avbrott, verktygsanrop och strikta latensförväntningar. Att proxyservera alla media genom din gateway kan förvandla gatewayen till ett bandbreddstungt mediarelä istället för en policy- och faktureringstjänst.

Direkta anslutningar från webbläsare till leverantör löser latens, men skapar ett annat problem:

• Webbläsaren kan inte säkert hålla en API-nyckel för standardleverantörer.
• Kontroller av hyresgästbudgeten kan hoppas över om appen ansluter direkt.
• Model-, region-, röst-, modalitets- och verktygsbegränsningar blir löften på klientsidan.
• Användningstillskrivning blir ofullständig eller försenad.
• Säkerhetsteam förlorar en revisionsbar beslutspunkt innan en session startar.

Den praktiska designen är inte "proxy varje byte." Det är "mäklare varje session."

Fakta, rekommendationer och förutsägelser

Fakta: Realtidsleverantörer av AI stöder i allt högre grad transporter med låg latens som WebRTC, WebSocket och SIP. Offentlig dokumentation för OpenAI:s Realtime API beskriver realtidsgränssnitt med låg latens, inklusive WebRTC. Azure OpenAI realtime WebRTC-vägledning beskriver en webbläsarapplikation som använder en backend-tokentjänst för att hämta en tillfällig token innan WebRTC-anslutningen startas, och varnar för att använda en standard API-nyckel i en klientapplikation. Realtidsvägledning för OpenAI Agents SDK rekommenderar också ett flöde där en backend skapar en kortlivad tillfällig klienttoken och webbläsaren använder den för att upprätta en WebRTC-anslutning.

Rekommendationer: Behandla gatewayen som sessionens auktoritet. Den bör avgöra om en realtidssession får finnas, med vilken modell, i vilken region, för vilken hyresgäst, under vilken budget och med vilka verktyg. Klienten bör endast få den minsta kortlivade autentiseringsinformation som behövs för att starta den godkända sessionen.

Förutsägelser: Realtidsleverantörers API:er kommer att förbli ojämna ett tag. Tokenlivslängder, sessionskonfigurationsfält, frånkopplingskontroller på serversidan, användningshändelser och regionstöd kommer att skilja sig åt. Gateways bör uttryckligen modellera leverantörskapacitet istället för att låtsas att alla realtids-API:er är perfekt portabla.

Referensarkitektur: gateway som kontrollplan i realtid

Ett webbläsarsäkert realtidsflöde har fem delar:

1. Klientapp: Webbläsare eller mobilapp som begär en röstsession.
2. Application backend: Autentiserar slutanvändaren och anropar gatewayen, eller bäddar in gateway-token-minting-logik om gatewayen är en del av backend-stacken.
3. AI API-gateway: Upprätthåller hyresgästpolicy, löser modellprofil, reserverar budget, registrerar sessionen och skapar en tillfällig leverantörsklienthemlighet.
4. Realtidsleverantör: Avslutar WebRTC eller annan realtidstransport.
5. Rekontra och analys: Avgör användning när leverantörshändelser, varaktighetsdata eller slutliga användningsrapporter är tillgängliga.

Gatewayen behöver inte vidarebefordra varje ljudbild för att förbli auktoritativ. Den måste äga beslutet om sessionsskapande och avstämningsvägen.

Rekommenderat förfrågningsflöde

1. Användaren öppnar en röstfunktion i klientappen.
2. Klienten anropar din backend: POST /röst/sessioner.
3. Backänden verifierar användarsessionen och vidarebefordrar en mint-begäran till gatewayen med klient-ID, användar-ID, avsedd funktion, enhetsmetadata och ursprung.
4. Gatewayen utvärderar policy och budget.
5. Gatewayen skapar en lokal realtime_session-post innan den kontaktar leverantören.
6. Gatewayen anropar leverantören med dess skyddade runtime-referens och skapar en kortvarig realtidssession med snäv omfattning.
7. Gatewayen returnerar endast den tillfälliga klientens hemliga och godkända sessionsmetadata till webbläsaren.
8. Webbläsaren upprättar WebRTC-anslutningen direkt med leverantören.
9. Gatewayen tar in leverantörshändelser, återuppringningar, pollingsresultat eller konservativa varaktighetsbaserade uppskattningar.
10. Rekontran reglerar den reserverade budgeten och skriver revisionshändelser.

Pre-mint policykontroller

Den viktigaste tillämpningspunkten är innan den tillfälliga token präglas. När webbläsaren har en kortlivad autentiseringsinformation kan tillämpningen av mitten av sessionen begränsas om inte leverantören stöder kontroller för sessionsuppdatering, frånkoppling, observation eller återuppringning.

Åtminstone bör gatewayen kontrollera:

• Hyresgäststatus: aktiv, avstängd, provperiod, förbetald, fakturerad eller satt i karantän.
• Användarrätt: om denna användare får använda röst i realtid, inte bara textchatt.
• Tillåten modellprofil: godkänd realtidsmodell eller implementering, inte godtyckliga modell-ID:n som tillhandahålls av klienter.
• Region och lagringspolicy: om den valda leverantörsregionen och funktionsuppsättningen matchar hyresgästens dataregler.
• Maximal sessionslängd: till exempel 5, 15 eller 30 minuter enligt plan.
• Tillåtna modaliteter: ljudingång, ljudutgång, text, bild eller verktygsanrop.
• Mall för röst och instruktioner: fast eller begränsat av policy.
• Tillgänglig budget: förbetalt saldo, reserverad månadspenning eller utgiftstak per funktion.
• Samtidighet: aktiva röstsessioner på hyresgäst- och användarnivå.
• Misbrukskontroller: användarriskflaggor, ursprungsrykte, ovanlig samtalshastighet eller brytare för klientdöd.

En säker standard är att avvisa tvetydiga förfrågningar. Om klienten frågar efter en modell, ett verktyg, en röst eller en region som inte ingår i hyresgästens realtidspolicy, bör gatewayen returnera ett tydligt policyfel istället för att i tysthet utöka åtkomsten.

Sessionspostdesign

Skapa en sessionspost på gatewaysidan innan du skapar leverantörsuppgifterna. Detta ger dig ett revisionsankare även om skapandet av leverantören lyckas men webbläsaren aldrig ansluter.

{
  "session_id": "rt_01j...",
  "tenant_id": "tenant_123",
  "end_user_id": "user_hash_456",
  "provider": "provider_a",
  "provider_session_id": null,
  "model_profile": "röststöd-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": "myntning"
}

Lagra inte råmikrofonljud eller fullständiga uppmaningar som standard. Lagra konfigurationshaschar, ID:n, policybeslut och minimal metadata som är tillräcklig för granskning, support och fakturering. Om inspelning krävs, gör den explicit, samtyckesmedveten och policystyrd.

Efemär token minting endpoint

En slutpunkt som vetter mot gatewayen kan se ut så här:

POST /v1/realtime/sessioner
Auktorisering: Bärare 
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"
}

Svaret bör inte avslöja din uppströmskörningsnyckel:

{
  "session_id": "rt_01j...",
  "provider": "provider_a",
  "transport": "webrtc",
  "client_secret": "ephemeral_secret_here",
  "expires_at": "2026-08-21T10:01:00Z",
  "godkänd": {
    "model_profile": "röststöd-standard",
    "max_duration_seconds": 900,
    "modalities": ["audio_ingång", "audio_output"],
    "tools": ["lookup_order_status"]
  }
}

Bind utfärdande till ursprung, autentiserad användarsession, hyresgäst och en nonce. Leverantören kanske inte stöder alla dessa bindningar inbyggt, så framtvinga vad du kan vid gatewayen: hastighetsbegränsa mintförsök, avvisa oväntade ursprung, registrera enhetens metadata och håll tokens livslängd kort.

Sessionsmallar: smala som standard

En sessionsmall i realtid bör vara mer restriktiv än en allmän begäran om chattslutförande. Röstsessioner är interaktiva, svårare att inspektera i realtid och kan pågå längre än förväntat.

Rekommenderade mallfält inkluderar:

• Fast modell eller distribution: vald av en modellprofil på gatewaysidan.
• Instruktioner: en serverkontrollerad promptmall med variabler som godkänts av hyresgästen.
• Röst: valt från en godkännandelista.
• Modaliteter: inaktivera text-, bild- eller verktygslägen om inte produkten behöver dem.
• Inställningar för ljudinmatning: svängdetektering, transkriptionsbeteende eller tystnadshantering där det stöds.
• Utdatabegränsningar: maximal svarslängd eller svarsbeteende där stöds.
• Tillståndslista för verktyg: endast verktyg som krävs för funktionen.
• Sessionens livslängd: kort giltighetstid plus maximal samtalslängd.

Strikta mallar minskar flexibiliteten, men de gör kostnader, efterlevnad och support enklare. Om produktteam behöver dynamiska röster eller instruktioner, exponera kontrollerade profilvarianter istället för att skicka godtycklig klientkonfiguration till leverantören.

Budgetkontroller för röst i realtid

Realtidsanvändning kan vara svårare att prissätta innan den slutliga leverantörsanvändningen anländer. En session kan ta fem sekunder eller tjugo minuter. Det kan inkludera ljudingång, ljudutgång, transkription, verktygsanrop och texttokens. Gatewayen bör därför kombinera reservation, tak och avstämning.

Innan prägling

• Uppskatta en värsta fall eller konservativ sessionskostnad utifrån maximal varaktighet, modell, modaliteter och hyresgästplan.
• Reservera budget innan du utfärdar klienthemligheten.
• Avvisa nya sessioner om hyresgästen saknar tillräcklig balans eller har nått dagliga röstgränser.

Under sessionen

• Spåra aktiva sessioner och förväntad brännhastighet.
• Tillämpa samtidighetstak för hyresgäster och användare.
• Använd funktioner för uppsägning eller sessionsuppdatering som stöds av leverantörer om det är tillgängligt.
• Utlös varningar för onormal sessionslängd, upprepade återanslutningar eller ovanlig röstanvändning.

Efter sessionen

• Slå in leverantörshändelser eller slutliga användningsrapporter där det är tillgängligt.
• Byt den reserverade budgeten till faktisk kostnad.
• Om exakt användning är försenad eller ofullständig, håll en konservativ reservation tills avstämning.
• Attribuera användning till klient, användare, funktion, modellprofil och sessions-ID.

Detta är mindre exakt än synkron textfakturering vid svarsögonblicket, men det är operativt säkrare än att utfärda direkta autentiseringsuppgifter utan reservation.

Verktygsanrop i realtidssessioner

Röstagenter i realtid blir ofta mer användbara när de kan ringa verktyg: söka ett konto, boka en tid, uppdatera en biljett eller utlösa ett arbetsflöde. Behandla verktygsutförande separat från ljudtransport.

Webbläsarens medieanslutning bör inte innebära tillåtelse att utföra biverkningar. Gatewayen eller backend bör tillämpa:

• Verktygsregister: varje verktyg har en ägare, ett schema, en omfattning och en risknivå.
• Tillståndslistor: sessionsmallar visar exakt vilka verktyg som är tillgängliga.
• Godkännande grindar: sidoeffekter kräver användarbekräftelse, mänskligt godkännande eller policygodkännande.
• Separata autentiseringsuppgifter: Verktygsuppgifter är aldrig inbäddade i webbläsarsessionen.
• Ansluten revisionsspår: varje verktygsanrop refererar till realtidssessions-ID.

Till exempel kan en supportröstagent tillåtas att ringa lookup_order_status automatiskt, men refund_payment kan kräva explicit bekräftelse och en godkännandehändelse för backend. Realtidsleverantören kan orkestrera konversationen, men din gateway bör styra behörighetsgränsen.

Synlighet utan proxy för varje byte

Direkt WebRTC-medieflöde minskar gateway-latens och bandbreddsbelastning, men synlighet blir mer beroende av leverantörshändelser och din egen sessionsmetadata. Designa analyser kring flera beviskällor:

• Sessionsskapande poster från gatewayen.
• Livscykelhändelser på klientsidan som ansluten, frånkopplad, återanslutningsförsök, mikrofon nekad eller samtal avslutat.
• Providersessions-ID:n, användningshändelser eller slutliga användningsposter.
• Laktighetsbaserade uppskattningar när leverantörsanvändningen är försenad.
• Verktygssamtalsloggar sammanfogade av sessions-ID.
• Budgetreservation och avräkningsposter.

Vänta inte på perfekt telemetri från leverantören innan du startar kontroller. Börja med konservativa reservationer och tydlig attribution, förbättra sedan avräkningsnoggrannheten när rapportering av leverantörsanvändning mognar.

Säkerhetschecklista

• Skicka aldrig standardleverantörs API-nycklar till webbläsare eller mobila klienter.
• Använd kortlivade tillfälliga klienthemligheter för uppstart av sessioner i realtid.
• Autentisera slutanvändaren innan token präglas.
• Bind mynningsbeslut till klient-, användare-, ursprungs-, nonce- och enhetsmetadata där så är möjligt.
• Behåll leverantörens runtime-referenser i ett backendvalv eller en hemlig gatewaybutik.
• Spela in en sessionsrevisionsrad innan leverantören slår in.
• Använd klientens godkända sessionsmallar istället för godtycklig klientkonfiguration.
• Tillämpa gränser för samtidighet, daglig användning och maximala varaktighet.
• Använd tillståndslistor för verktyg och godkännandegrindar för biverkningar.
• Minimera råuppmaningar och ljudretention som standard.
• Upprätthåll en leverantörskapacitetsmatris för tokens livstider, regioner, verktyg, användningshändelser och uppsägningskontroller.

Matris för leverantörskapacitet

Eftersom realtids-API:er skiljer sig, modellera din gateway-adapter utifrån kapacitet snarare än antaganden. En enkel matris kan styra routing- och policybeslut:

{
  "provider_a": {
    "transports": ["webrtc", "websocket"],
    "ephemeral_client_tokens": sant,
    "token_ttl_seconds": 60,
    "server_side_disconnect": sant,
    "session_update": sant,
    "usage_events": "final_and_incremental",
    "regions": ["us", "eu"],
    "tool_aproval_supported": sant
  },
  "provider_b": {
    "transports": ["websocket"],
    "ephemeral_client_tokens": sant,
    "token_ttl_seconds": 120,
    "server_side_disconnect": false,
    "session_update": false,
    "usage_events": "endast_bara",
    "regions": ["oss"],
    "tool_aproval_supported": false
  }
}

Om en hyresgäst kräver EU-vistelse och uppsägning på serversidan, bör gatewayen endast dirigera till leverantörer och distributioner som uppfyller båda. Om ingen leverantör uppfyller policyn, fail closed.

Migreringsväg

Du behöver inte bygga alla kontroller på dag ett. En praktisk utrullning är:

1. Endast skapande av proxysessioner: håll media direkt, men kräver att alla realtidssessioner skapas av backend eller gateway.
2. Lägg till policymallar: ersätt modell- och instruktionsfält som tillhandahålls av klienten med godkända profiler.
3. Lägg till budgetreservation: reservera konservativ sessionskostnad innan token utfärdas.
4. Lägg till livscykelanalys: samla in sessionsstart, anslut, koppla från, varaktighet, leverantörssessions-ID och avvecklingsstatus.
5. Lägg till verktygsstyrning: Kräv godkännandelistor och godkännanden för verktygsanrop i realtid.
6. Lägg till routing för leverantörskapacitet: välj leverantörer efter region, modalitet, evenemangsstöd och uppsägningskontroller.
7. Lägg till valfria observatörs- eller inspelningsarbetsflöden: endast när det är kompatibelt, samtyckt och hyresgästen har godkänts.

Aktiv slutsats

För röst-AI i realtid bör en AI API-gateway inte automatiskt bli ett mediarelä. Den säkrare arkitekturen med lägre latens är att hålla gatewayen ansvarig för kontrollplanet: autentisera användare, upprätthålla hyresgästpolicy, reservera budget, skapa en revisionspost, skapa en kortfattad tillfällig referens och stämma av användning efter sessionen.

Kärnimplementeringsregeln är enkel: webbläsare kan ta emot kortlivade sessionshemligheter, aldrig långlivade leverantörsnycklar. Allt annat följer av den gränsen: strikta mallar, ursprungsmedveten minting, samtidiga sessioner, verktygsgodkännanden, användningsavräkning och leverantörskapacitetsmatriser. Detta ger produktteam röstupplevelser i realtid utan att ge upp API-nyckelhantering, AI API-kostnadskontroll, team-API-styrning eller AI-användningsanalys.

Relaterad läsning

• budgetreservation och avräkningsreskontra