Browser-sikker realtids-AI gennem en API-gateway: flygtige tokens, lejerpolitik og stemmesessionskontrol

Browser- og mobilapps bør ikke modtage udbyder API nøgler med lang levetid. For stemme-AI i realtid kan afsendelse af hver lydpakke gennem en gateway dog ​​tilføje latency, driftsomkostninger og fejltilstande. Det bedre mønster er at holde gatewayen i kontrolplanet: autentificer brugeren, håndhæv lejerpolitik, reserver budget, lav en kortvarig realtidslegitimationsoplysninger, og lad latensfølsomme medier bruge udbyderens realtidstransport, hvor det er relevant.

Denne artikel beskriver et implementeringsmønster for teams, der bygger taleagenter, opkaldsassistenter, mobile undervisere, supportcopiloter eller stemmegrænseflader i appen gennem en AI API-gateway. Målet er browsersikkerhed uden at miste lejerstyring.

Problemet: direkte realtidsforbindelser omgår dine kontroller

En almindelig serverside-proxy er attraktiv, fordi den centraliserer nøgler og observerbarhed. For standardtekstanmodninger er det ofte den rigtige model. Realtidslyd er anderledes. En stemmesession kan involvere kontinuerlig mikrofoninput, tovejs lydoutput, afbrydelser, værktøjsopkald og strenge ventetider. Proxy alle medier gennem din gateway kan gøre gatewayen til et båndbredde-tungt medie-relæ i stedet for en politik- og faktureringstjeneste.

Direkte browser-til-udbyder-forbindelser løser ventetid, men skaber et andet problem:

• Browseren kan ikke sikkert holde en standard udbyder API-nøgle.
• Tjek af lejerbudget kan springes over, hvis appen opretter direkte forbindelse.
• Model-, region-, stemme-, modalitets- og værktøjsbegrænsninger bliver løfter på klientsiden.
• Brugstilskrivning bliver ufuldstændig eller forsinket.
• Sikkerhedsteams mister et revisionsbart beslutningspunkt, før en session starter.

Det praktiske design er ikke "proxy hver byte". Det er "mægler hver session."

Fakta, anbefalinger og forudsigelser

Fakta: Realtime AI-udbydere understøtter i stigende grad transporter med lav forsinkelse, såsom WebRTC, WebSocket og SIP. Offentlig dokumentation for OpenAIs Realtime API beskriver realtidsgrænseflader med lav latens, inklusive WebRTC. Azure OpenAI realtime WebRTC-vejledning beskriver en browserapplikation, der bruger en backend-tokentjeneste til at hente et flygtigt token, før WebRTC-forbindelsen startes, og advarer mod at bruge en standard API-nøgle i en klientapplikation. OpenAI Agents SDK realtidsvejledning anbefaler også et flow, hvor en backend opretter et kortvarigt kortvarigt kortvarigt klienttoken, og browseren bruger det til at etablere en WebRTC-forbindelse.

Anbefalinger: Behandl gatewayen som sessionsautoriteten. Det bør beslutte, om en realtidssession må eksistere, med hvilken model, i hvilken region, for hvilken lejer, under hvilket budget og med hvilke værktøjer. Klienten bør kun modtage den mindste kortvarige legitimation, der er nødvendig for at starte den godkendte session.

Forudsigelser: Realtidsudbyder-API'er vil forblive ujævne i et stykke tid. Tokens levetid, sessionskonfigurationsfelter, kontrolfunktioner for afbrydelse af forbindelse på serversiden, brugsbegivenheder og regionssupport vil variere. Gateways bør udtrykkeligt modellere udbyderens muligheder i stedet for at lade som om, at alle realtids-API'er er perfekt bærbare.

Referencearkitektur: gateway som kontrolplan i realtid

Et browsersikkert realtidsflow har fem dele:

1. Klientapp: Browser eller mobilapp, der anmoder om en talesession.
2. Applikations-backend: Autentificerer slutbrugeren og kalder gatewayen eller indlejrer gateway-token-minting-logik, hvis gatewayen er en del af backend-stakken.
3. AI API-gateway: Håndhæver lejerpolitik, løser modelprofil, reserverer budget, registrerer sessionen og fremkalder en kortvarig udbyder-klienthemmelighed.
4. Realtidsudbyder: Afslutter WebRTC eller en anden realtidstransport.
5. Rekontro og analyser: Afregner brug, når udbyderhændelser, varighedsdata eller endelige brugsrapporter er tilgængelige.

Gatewayen behøver ikke at videresende hver lydramme for at forblive autoritativ. Den skal eje beslutningen om oprettelse af session og afstemningsstien.

Anbefalet anmodningsflow

1. Brugeren åbner en stemmefunktion i klientappen.
2. Klienten ringer til din backend: POST /voice/sessions.
3. Backenden verificerer brugersessionen og videresender en mint-anmodning til gatewayen med lejer-id, bruger-id, tilsigtet funktion, enhedsmetadata og oprindelse.
4. Gatewayen evaluerer politik og budget.
5. Gatewayen opretter en lokal realtime_session-post, før den kontakter udbyderen.
6. Gatewayen ringer til udbyderen med dens beskyttede runtime-legitimationsoplysninger og opretter en kortvarig realtidssession med snævert omfang.
7. Gatewayen returnerer kun de flygtige klienthemmelige og godkendte sessionsmetadata til browseren.
8. Browseren etablerer WebRTC-forbindelsen direkte med udbyderen.
9. Gatewayen optager udbyderbrugsbegivenheder, tilbagekald, afstemningsresultater eller konservative varighedsbaserede estimater.
10. Rekontroen afregner det reserverede budget og skriver revisionsbegivenheder.

Pre-mint politiktjek

Det vigtigste håndhævelsespunkt er før det flygtige token præges. Når først browseren har en kortvarig legitimation, kan håndhævelse midt i sessionen være begrænset, medmindre udbyderen understøtter sessionsopdatering, afbrydelse, observation eller tilbagekaldskontrol.

Gatewayen bør som minimum kontrollere:

• Lejerstatus: aktiv, suspenderet, prøveperiode, forudbetalt, faktureret eller i karantæne.
• Brugerrettigheder: om denne bruger må bruge stemme i realtid, ikke kun tekstchat.
• Tilladt modelprofil: godkendt realtidsmodel eller implementering, ikke vilkårlige klientleverede model-id'er.
• Regions- og opbevaringspolitik: om den valgte udbyderregion og funktionssæt matcher lejerens dataregler.
• Maksimal sessionsvarighed: f.eks. 5, 15 eller 30 minutter efter plan.
• Tilladte modaliteter: lydinput, lydoutput, tekst, billede eller værktøjsopkald.
• Stemme- og instruktionsskabelon: fast eller begrænset af politik.
• Tilgængelig budget: forudbetalt saldo, reserveret månedligt tillæg eller forbrugsloft pr. funktion.
• Samtidig: aktive stemmesessioner på lejerniveau og brugerniveau.
• Misbrugskontrol: brugerrisikomarkeringer, oprindelsesomdømme, usædvanlig opkaldshastighed eller lejerafbryder.

En sikker standard er at afvise tvetydige anmodninger. Hvis klienten beder om en model, et værktøj, en stemme eller en region, der ikke er i lejerens realtidspolitik, bør gatewayen returnere en tydelig politikfejl i stedet for lydløst at udvide adgangen.

Session record design

Opret en sessionsregistrering på gatewaysiden, før du slår udbyderens legitimationsoplysninger. Dette giver dig et revisionsanker, selvom oprettelsen af udbyderen lykkes, men browseren aldrig forbinder.

{
  "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"
}

Gem ikke rå mikrofonlyd eller fulde prompter som standard. Gem konfigurations-hash, id'er, politiske beslutninger og minimale metadata, der er tilstrækkelige til revision, support og fakturering. Hvis optagelse er påkrævet, skal du gøre den eksplicit, samtykkebevidst og lejerpolitikstyret.

Efhemeral token minting endpoint

Et gateway-vendt slutpunkt kan se sådan ud:

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"
}

Svaret bør ikke afsløre din upstream-runtime-nøgle:

{
  "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"]
  }
}

Bind udstedelse til oprindelse, godkendt brugersession, lejer og en nonce. Udbyderen understøtter muligvis ikke alle disse bindinger indbygget, så håndhæv det, du kan ved gatewayen: rate-limit mint-forsøg, afvis uventede oprindelser, optag enhedens metadata og hold tokenets levetid kort.

Sessionsskabeloner: indsnævre som standard

En sessionsskabelon i realtid bør være mere restriktiv end en generel anmodning om chatafslutning. Stemmesessioner er interaktive, sværere at inspicere i realtid og kan løbe længere end forventet.

Anbefalede skabelonfelter omfatter:

• Fixet model eller implementering: valgt af en modelprofil på gatewaysiden.
• Instruktioner: en serverstyret promptskabelon med lejergodkendte variabler.
• Voice: valgt fra en tilladelsesliste.
• Modaliteter: deaktiver tekst-, billed- eller værktøjstilstande, medmindre produktet har brug for dem.
• Indstillinger for inputlyd: drejningsdetektion, transskriptionsadfærd eller tavshedshåndtering, hvor understøttet.
• Outputbegrænsninger: maksimal svarlængde eller svaradfærd, hvor understøttet.
• Værktøjstilladelsesliste: kun værktøjer, der kræves til funktionen.
• Sessionens levetid: kort udløb af legitimationsoplysninger plus maksimal opkaldsvarighed.

Strenge skabeloner reducerer fleksibiliteten, men de gør omkostninger, overholdelse og support nemmere. Hvis produktteams har brug for dynamiske stemmer eller instruktioner, skal du blotlægge kontrollerede profilvarianter i stedet for at videregive vilkårlig klientkonfiguration til udbyderen.

Budgetkontrol til stemme i realtid

Realtidsbrug kan være sværere at prissætte, før den endelige udbyderbrug ankommer. En session kan vare fem sekunder eller tyve minutter. Det kan omfatte lydinput, lydoutput, transskription, værktøjsopkald og teksttokens. Gatewayen bør derfor kombinere reservation, lofter og afstemning.

Før prægning

• Estimer en worst-case eller konservativ sessionsomkostning ud fra maksimal varighed, model, modaliteter og lejerplan.
• Reserver budget, før du udsteder klienthemmeligheden.
• Afvis nye sessioner, hvis lejeren mangler tilstrækkelig balance eller har nået de daglige stemmegrænser.

Under sessionen

• Spor aktive sessioner og forventet forbrændingshastighed.
• Anvend samtidighedsloft for lejer og bruger.
• Brug udbyder-understøttede funktioner til afslutning eller sessionsopdatering, hvis de er tilgængelige.
• Trigger advarsler for unormal sessionsvarighed, gentagne genforbindelser eller usædvanlig stemmebrug.

Efter sessionen

• Indtag udbyderbrugsbegivenheder eller endelige brugsrapporter, hvor de er tilgængelige.
• Afstem det reserverede budget til faktiske omkostninger.
• Hvis den nøjagtige brug er forsinket eller ufuldstændig, skal du holde et konservativt forbehold indtil afstemning.
• Tilskriv brug til lejer, bruger, funktion, modelprofil og sessions-id.

Dette er mindre nøjagtigt end synkron tekstfakturering på tidspunktet for svar, men det er driftsmæssigt sikrere end at udstede direkte legitimationsoplysninger uden forbehold.

Værktøjsopkald i realtidssessioner

Taleagenter i realtid bliver ofte mere nyttige, når de kan ringe til værktøjer: søge efter en konto, booke en aftale, opdatere en billet eller udløse en arbejdsgang. Behandl værktøjsudførelse separat fra lydtransport.

Browserens medieforbindelse bør ikke indebære tilladelse til at udføre bivirkninger. Gatewayen eller backend skal håndhæve:

• Værktøjsregistrering: hvert værktøj har en ejer, et skema, et omfang og et risikoniveau.
• Tilladelseslister: sessionsskabeloner viser præcis, hvilke værktøjer der er tilgængelige.
• Godkendelsesporte: bivirkninger kræver brugerbekræftelse, menneskelig godkendelse eller politikgodkendelse.
• Separate loginoplysninger: værktøjslegitimationsoplysninger er aldrig indlejret i browsersessionen.
• Tilsluttet revisionsspor: hvert værktøjskald refererer til realtidssessions-id'et.

For eksempel kan en supportstemmeagent have tilladelse til automatisk at ringe til lookup_order_status, men refund_payment kan kræve eksplicit bekræftelse og en backend-godkendelsesbegivenhed. Realtidsudbyderen kan orkestrere samtalen, men din gateway bør styre tilladelsesgrænsen.

Synlighed uden proxy for hver byte

Direkte WebRTC-medieflow reducerer gateway-latens og båndbreddebelastning, men synlighed bliver mere afhængig af udbyderhændelser og dine egne sessionsmetadata. Design analyser omkring flere beviskilder:

• Sessionsoprettelsesregistreringer fra gatewayen.
• Livscyklushændelser på klientsiden som f.eks. tilsluttet, afbrudt, forsøgt at oprette forbindelse igen, mikrofon nægtet eller opkald afsluttet.
• Providersessions-id'er, brugsbegivenheder eller endelige brugsregistreringer.
• Varighedsbaserede estimater, når udbyderbrug er forsinket.
• Værktøjsopkaldslogfiler forbundet af sessions-id.
• Budgetreservation og afregningsposter.

Vent ikke på perfekt telemetri fra udbyderen, før du starter kontroller. Start med konservative forbehold og tydelig tilskrivning, og forbedr derefter afregningsnøjagtigheden, efterhånden som udbyderbrugsrapportering modnes.

Sikkerhedstjekliste

• Send aldrig standardudbyder API-nøgler til browser- eller mobilklienter.
• Brug kortvarige kortvarige klienthemmeligheder til opstart af sessioner i realtid.
• Godkend slutbrugeren før tokenprægning.
• Bind prægningsbeslutninger til lejer, bruger, oprindelse, nonce og enhedsmetadata, hvor det er muligt.
• Behold udbyderens runtime-legitimationsoplysninger i en hemmelig backend-boks eller gateway-butik.
• Optag en sessionsrevisionsrække, før udbyderen slår igennem.
• Brug lejergodkendte sessionsskabeloner i stedet for vilkårlig klientkonfiguration.
• Anvend grænser for samtidighed, daglig brug og maksimal varighed.
• Brug værktøjstilladelseslister og godkendelsesporte til bivirkninger.
• Minimer rå prompt og lydopbevaring som standard.
• Oprethold en matrix for udbyderkapacitet for tokens levetid, regioner, værktøjer, brugsbegivenheder og opsigelseskontroller.

Matrix for udbyderkapacitet

Fordi realtids-API'er er forskellige, skal du modellere din gateway-adapter efter muligheder i stedet for antagelser. En simpel matrix kan drive routing og politiske beslutninger:

{
  "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
  }
}

Hvis en lejer kræver EU-ophold og opsigelse på serversiden, bør gatewayen kun rute til udbydere og implementeringer, der opfylder begge dele. Hvis ingen udbyder opfylder politikken, skal du ikke lukke.

Migreringssti

Du behøver ikke at bygge alle kontrolelementer på dag ét. En praktisk udrulning er:

1. Kun oprettelse af proxy-sessioner: hold medierne direkte, men kræve, at alle realtidssessioner bliver præget af backend eller gateway.
2. Tilføj politikskabeloner: udskift klientleverede model- og instruktionsfelter med godkendte profiler.
3. Tilføj budgetreservation: reserver konservative sessionsomkostninger før tokenudstedelse.
4. Tilføj livscyklusanalyse: indsaml sessionsstart, tilslut, afbryd, varighed, udbydersessions-id og afregningsstatus.
5. Tilføj værktøjsstyring: kræver tilladelseslister og godkendelser til værktøjsopkald i realtid.
6. Tilføj ruteføring af udbyderkapacitet: vælg udbydere efter område, modalitet, hændelsessupport og opsigelseskontroller.
7. Tilføj valgfri observatør- eller optagelsesarbejdsgange: kun, hvor de er i overensstemmelse, er godkendt og lejer-godkendt.

Aktiv konklusion

For stemme-AI i realtid bør en AI API-gateway ikke automatisk blive et medie-relæ. Den sikrere arkitektur med lavere latency er at holde gatewayen ansvarlig for kontrolplanet: godkend brugere, håndhæv lejerpolitik, reserver budget, opret en revisionspost, lav en kortvarig legitimationsoplysninger og afstem brug efter sessionen.

Kerneimplementeringsreglen er enkel: browsere kan modtage kortlivede sessionshemmeligheder, aldrig langlivede udbydernøgler. Alt andet følger af denne grænse: strenge skabeloner, oprindelsesbevidst prægning, samtidige sessions-caps, værktøjsgodkendelser, brugsafregning og udbyderkapacitetsmatricer. Dette giver produktteams stemmeoplevelser i realtid uden at give afkald på API nøgleadministration, AI API omkostningskontrol, team API styring eller AI-brugsanalyse.

Relateret læsning

• udbyder legitimationsboks til kørsel nøgler
• budgetreservation og afregningsbog