Browser-sikker realtids-AI gennem en API-gateway: flygtige tokens, lejerpolitik og stemmesessionskontrol
En praktisk arkitektur til browser og mobil stemme-AI: Hold realtidsmedier lav-latency med kortvarige klientoplysninger, mens gatewayen håndhæver lejerpolitik, budgettjek, værktøjskontroller og revisionsspor.
Browser- og mobilapps bør ikke modtage langlivede udbyders API-nøgler. For stemme-AI i realtid kan afsendelse af hver lydpakke gennem en gateway 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 snæver 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 server-side proxy er attraktiv, fordi den centraliserer nøgler og observerbarhed. For standardtekstanmodninger er det ofte den rigtige model. Realtime lyd 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øjsrestriktioner 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 latens, såsom WebRTC, WebSocket og SIP. Offentlig dokumentation for OpenAI's 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 afgøre, om der må eksistere en realtidssession, 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:
- Kundeapp: Browser eller mobilapp, der anmoder om en talesession.
- Applikations-backend: Godkender slutbrugeren og kalder gatewayen eller indlejrer gateway-token-minting-logik, hvis gatewayen er en del af backend-stakken.
- AI API-gateway: Håndhæver lejerpolitik, løser modelprofil, reserverer budget, registrerer sessionen og fremkalder en flygtig udbyder-klienthemmelighed.
- Realtidsudbyder: Afslutter WebRTC eller en anden realtidstransport.
- Rekontro og analyser: Afgør 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
- Brugeren åbner en stemmefunktion i klientappen.
- Klienten ringer til din backend:
POST /stemme/sessioner. - Backenden verificerer brugersessionen og videresender en mint-anmodning til gatewayen med lejer-id, bruger-id, tilsigtet funktion, enhedsmetadata og oprindelse.
- Gatewayen evaluerer politik og budget.
- Gatewayen opretter en lokal
realtime_session-post, før den kontakter udbyderen. - Gatewayen ringer til udbyderen med dens beskyttede runtime-legitimationsoplysninger og opretter en kortvarig realtidssession med snævert omfang.
- Gatewayen returnerer kun de flygtige klienthemmelige og godkendte sessionsmetadata til browseren.
- Browseren etablerer WebRTC-forbindelsen direkte med udbyderen.
- Gatewayen optager udbyderbrugsbegivenheder, tilbagekald, pollingsresultater eller konservative varighedsbaserede estimater.
- 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.
- Region 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ængeligt budget: forudbetalt saldo, reserveret månedligt tillæg eller forbrugsloft pr. funktion.
- Samtidighed: aktive stemmesessioner på lejerniveau og brugerniveau.
- Misbrugskontrol: Brugerrisikoflag, 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å gateway-siden, før du bruger udbyderens legitimationsoplysninger. Dette giver dig et revisionsanker, selvom oprettelsen af udbyderen lykkes, men browseren aldrig forbinder.
Opbevar 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/sessioner
Autorisation: Bærer
Indholdstype: 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": "stemme-support-standard"
} Svaret bør ikke afsløre din upstream runtime nøgle:
Bind udstedelse til oprindelse, autentificeret brugersession, lejer og en nonce. Udbyderen understøtter muligvis ikke alle disse bindinger indbygget, så håndhæv, hvad 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:
- Fast model eller implementering: valgt af en modelprofil på gateway-siden.
- Instruktioner: en serverstyret promptskabelon med lejergodkendte variabler.
- Stemme: valgt fra en tilladelsesliste.
- Modaliteter: deaktiver tekst-, billed- eller værktøjstilstande, medmindre produktet har brug for dem.
- Indstillinger for inputlyd: Drejeregistrering, transskriptionsadfærd eller tavshedshåndtering, hvor det er 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 daglige stemmegrænser.
Under sessionen
- Spor aktive sessioner og forventet forbrændingshastighed.
- Anvend samtidighedsloft for lejer og bruger.
- Brug udbyder-understøttede afslutnings- eller sessionsopdateringsfunktioner, hvis de er tilgængelige.
- Udløs advarsler for unormal sessionsvarighed, gentagne genforbindelser eller usædvanlig stemmebrug.
Efter sessionen
- Indtag udbyderbrugsbegivenheder eller endelige brugsrapporter, hvor de er tilgængelige.
- Afregn 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 adskilt 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.
- Særskilte legitimationsoplysninger: Værktøjslegitimationsoplysninger er aldrig indlejret i browsersessionen.
- Tilsluttet revisionsspor: hvert værktøjskald refererer til realtidssessions-id'et.
For eksempel kan en supporttaleagent have tilladelse til at ringe til lookup_order_status automatisk, 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. forbundet, afbrudt, forsøg på at oprette forbindelse igen, mikrofon afvist eller opkald afsluttet.
- Udbyders sessions-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 klar tilskrivning, og forbedr derefter afregningsnøjagtigheden, efterhånden som udbyderbrugsrapportering modnes.
Sikkerhedstjekliste
- Send aldrig standard udbyder API-nøgler til browser eller mobilklienter.
- Brug kortvarige kortvarige klienthemmeligheder til opstart af sessioner i realtid.
- Godkend slutbrugeren før token-præ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 ud.
- 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, områder, værktøjer, brugshændelser 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:
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:
- Kun oprettelse af proxy-session: Hold medierne direkte, men kræve, at alle realtidssessioner præges af backend eller gateway.
- Tilføj politikskabeloner: Erstat klientleverede model- og instruktionsfelter med godkendte profiler.
- Tilføj budgetreservation: reserver konservative sessionsomkostninger før tokenudstedelse.
- Tilføj livscyklusanalyse: indsaml sessionsstart, opret forbindelse, afbrydelse, varighed, udbydersessions-id og afregningsstatus.
- Tilføj værktøjsstyring: Kræv tilladelseslister og godkendelser til værktøjsopkald i realtid.
- Tilføj ruteføring af udbyderkapacitet: vælg udbydere efter region, modalitet, eventsupport og opsigelseskontroller.
- Tilføj valgfri observatør- eller optagelsesarbejdsgange: kun hvor de er kompatible, har givet samtykke og er godkendt af lejeren.
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 sessionscaps, værktøjsgodkendelser, brugsafregning og udbyderkapacitetsmatricer. Dette giver produktteams stemmeoplevelser i realtid uden at give afkald på API-nøglestyring, AI API-omkostningskontrol, team-API-styring eller AI-brugsanalyse.