Nettlesersikker sanntids-AI gjennom en API-gateway: Ephemeral Tokens, Leietakerpolicy og Voice Session Controls

Nettleser- og mobilapper skal ikke motta langvarige leverandør API-nøkler. For stemme-AI i sanntid kan imidlertid sende hver lydpakke gjennom en gateway legge til ventetid, driftskostnader og feilmoduser. Det bedre mønsteret er å holde gatewayen i kontrollplanet: autentiser brukeren, håndhev leietakerpolicy, reserver budsjett, skap en smal kortvarig sanntidslegitimasjon og la latenssensitive medier bruke leverandørens sanntidstransport der det er hensiktsmessig.

Denne artikkelen beskriver et implementeringsmønster for team som bygger taleagenter, samtaleassistenter, mobilveiledere, støttekopiloter eller talegrensesnitt i appen gjennom en AI API-gateway. Målet er nettlesersikkerhet uten å miste styring av leietakere.

Problemet: direkte sanntidstilkoblinger omgår kontrollene dine

En vanlig proxy på serversiden er attraktiv fordi den sentraliserer nøkler og observerbarhet. For standard tekstforespørsler er det ofte den rette modellen. Sanntidslyd er annerledes. En taleøkt kan innebære kontinuerlig mikrofoninngang, toveis lydutgang, avbrudd, verktøyanrop og strenge ventetider. Proxying av alle medier gjennom gatewayen din kan gjøre gatewayen om til et medierelé med båndbredde i stedet for en policy- og faktureringstjeneste.

Direkte nettleser-til-leverandør-tilkoblinger løser ventetid, men skaper et annet problem:

• Nettleseren kan ikke holde en standard leverandør API-nøkkel.
• Leierbudsjettsjekker kan hoppes over hvis appen kobles til direkte.
• Begrensninger for modell, region, tale, modalitet og verktøy blir løfter på klientsiden.
• Bruksattribusjon blir ufullstendig eller forsinket.
• Sikkerhetsteam mister et reviderbart beslutningspunkt før en økt starter.

Den praktiske utformingen er ikke «proxy hver byte». Det er «megler hver økt».

Fakta, anbefalinger og spådommer

Fakta: Sanntids-AI-leverandører støtter i økende grad transporter med lav latens som WebRTC, WebSocket og SIP. Offentlig dokumentasjon for OpenAIs sanntid API beskriver sanntidsgrensesnitt med lav latens, inkludert WebRTC. Azure OpenAI sanntids WebRTC-veiledning beskriver en nettleserapplikasjon som bruker en backend-tokentjeneste for å hente et flyktig token før du starter WebRTC-tilkoblingen, og advarer mot å bruke en standard API-nøkkel i en klientapplikasjon. OpenAI Agents SDK sanntidsveiledning anbefaler også en flyt der en backend oppretter et kortvarig flyktig klienttoken og nettleseren bruker det til å etablere en WebRTC-tilkobling.

Anbefalinger: Betrakt gatewayen som øktautoriteten. Den bør avgjøre om en sanntidsøkt kan eksistere, med hvilken modell, i hvilken region, for hvilken leietaker, under hvilket budsjett og med hvilke verktøy. Klienten skal bare motta den minste kortvarige legitimasjonen som kreves for å starte den godkjente økten.

Spådommer: API-er for sanntidsleverandører vil forbli ujevne en stund. Tokens levetid, øktkonfigurasjonsfelt, frakoblingskontroller på serversiden, brukshendelser og regionstøtte vil variere. Gatewayer bør eksplisitt modellere leverandørens evner i stedet for å late som om alle sanntids-API-er er perfekt portable.

Referansearkitektur: gateway som sanntidskontrollplan

En nettlesersikker sanntidsflyt har fem deler:

1. Klientapp: Nettleser eller mobilapp som ber om en taleøkt.
2. Application backend: Autentiserer sluttbrukeren og kaller gatewayen, eller bygger inn gateway-token-minting-logikk hvis gatewayen er en del av backend-stakken.
3. AI API gateway: Håndhever retningslinjer for leietaker, løser modellprofil, reserverer budsjett, registrerer økten og lager en kortvarig leverandørklienthemmelighet.
4. Sanntidsleverandør: Avslutter WebRTC eller annen sanntidstransport.
5. Rekontro og analyser: Avgjør bruk når leverandørhendelser, varighetsdata eller endelige bruksrapporter er tilgjengelige.

Gatewayen trenger ikke å videresende hver lydramme for å forbli autoritativ. Den må eie avgjørelsen om øktoppretting og avstemmingsbanen.

Anbefalt forespørselsflyt

1. Brukeren åpner en talefunksjon i klientappen.
2. Klienten ringer backend: POST /voice/sessions.
3. Bakstøtten bekrefter brukerøkten og videresender en mint-forespørsel til gatewayen med leietaker-ID, bruker-ID, tiltenkt funksjon, enhetsmetadata og opprinnelse.
4. Gatewayen evaluerer retningslinjer og budsjett.
5. Gatewayen oppretter en lokal realtime_session-post før du kontakter leverandøren.
6. Gatewayen ringer leverandøren med dens beskyttede kjøretidslegitimasjon og oppretter en kortvarig sanntidsøkt med smalt omfang.
7. Gatewayen returnerer bare de flyktige klienthemmelige og godkjente øktmetadataene til nettleseren.
8. Nettleseren oppretter WebRTC-forbindelsen direkte med leverandøren.
9. Gatewayen tar inn leverandørbrukshendelser, tilbakeringinger, avstemningsresultater eller konservative varighetsbaserte estimater.
10. Rekontroen avgjør det reserverte budsjettet og skriver revisjonshendelser.

Pre-mint policy checks

Det viktigste håndhevelsespunktet er før det flyktige tokenet preges. Når nettleseren har en kortvarig påloggingsinformasjon, kan håndhevelsen av økten begrenses med mindre leverandøren støtter øktoppdatering, frakobling, observasjon eller tilbakeringingskontroller.

I det minste bør gatewayen sjekke:

• Leietakerstatus: aktiv, suspendert, prøveversjon, forhåndsbetalt, fakturert eller satt i karantene.
• Brukerrett: om denne brukeren kan bruke tale i sanntid, ikke bare tekstchat.
• Tillatt modellprofil: godkjent sanntidsmodell eller implementering, ikke vilkårlige klientleverte modell-ID-er.
• Retningslinjer for region og oppbevaring: om den valgte leverandørregionen og funksjonssettet samsvarer med leietakerens dataregler.
• Maksimal øktvarighet: for eksempel 5, 15 eller 30 minutter etter plan.
• Tillatte modaliteter: lydinngang, lydutgang, tekst-, bilde- eller verktøyanrop.
• Stemme- og instruksjonsmal: fast eller begrenset av policy.
• Tilgjengelig budsjett: forhåndsbetalt saldo, reservert månedlig godtgjørelse eller forbrukstak per funksjon.
• Samtidighet: aktive taleøkter på leietakernivå og brukernivå.
• Misbrukskontroller: brukerrisikoflagg, opprinnelsesrykte, uvanlig samtalehastighet eller bryter for leietaker.

En sikker standard er å avvise tvetydige forespørsler. Hvis klienten ber om en modell, et verktøy, en stemme eller en region som ikke er i leietakerens sanntidspolicy, bør gatewayen returnere en tydelig policyfeil i stedet for å utvide tilgangen stille.

Session record design

Opprett en sesjonspost på gatewaysiden før du legger inn leverandørlegitimasjonen. Dette gir deg et revisjonsanker selv om opprettelsen av leverandøren lykkes, men nettleseren kobler seg aldri til.

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

Ikke lagre rå mikrofonlyd eller fullstendige meldinger som standard. Lagre konfigurasjonshasher, IDer, policybeslutninger og minimale metadata som er tilstrekkelig for revisjon, støtte og fakturering. Hvis opptak er nødvendig, må du gjøre det eksplisitt, samtykkebevisst og styret av leietaker.

Endepunkt for kortvarig mynting av token

Et endepunkt som vender mot gatewayen kan se slik ut:

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

Responsen skal ikke avsløre oppstrøms kjøretidsnøkkel:

{
  "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 utstedelse til opprinnelse, autentisert brukerøkt, leietaker og en nonce. Leverandøren støtter kanskje ikke alle disse bindingene, så håndhev det du kan ved gatewayen: rate-limit mint-forsøk, avvis uventet opprinnelse, registrer enhetens metadata og hold tokenets levetid kort.

Øktmaler: begrenset som standard

En øktmal i sanntid bør være mer restriktiv enn en generell forespørsel om chat-fullføring. Stemmeøkter er interaktive, vanskeligere å inspisere i sanntid og kan vare lenger enn forventet.

Anbefalte malfelt inkluderer:

• Fast modell eller distribusjon: valgt av en modellprofil på gatewaysiden.
• Instruksjoner: en serverkontrollert forespørselsmal med leietakergodkjente variabler.
• Voice: valgt fra en godkjenningsliste.
• Modaliteter: deaktiver tekst-, bilde- eller verktøymodus med mindre produktet trenger dem.
• Innstillinger for lydinngang: svingdeteksjon, transkripsjonsatferd eller stillhetshåndtering der dette støttes.
• Utdatabegrensninger: maksimal svarlengde eller responsatferd der støttet.
• Tillatelsesliste for verktøy: bare verktøy som kreves for funksjonen.
• Levetid for økten: kort utløp av legitimasjon pluss maksimal samtalevarighet.

Strenge maler reduserer fleksibiliteten, men de gjør kostnader, samsvar og støtte enklere. Hvis produktteam trenger dynamiske stemmer eller instruksjoner, avslør kontrollerte profilvarianter i stedet for å sende vilkårlig klientkonfigurasjon til leverandøren.

Budsjettkontroller for sanntidsstemme

Sanntidsbruk kan være vanskeligere å prissette før den endelige leverandørbruken kommer. En økt kan vare i fem sekunder eller tjue minutter. Det kan inkludere lydinngang, lydutgang, transkripsjon, verktøyanrop og teksttokens. Gatewayen bør derfor kombinere reservasjon, tak og avstemming.

Før preging

• Beregn en worst-case eller konservativ øktkostnad fra maksimal varighet, modell, modaliteter og leietakerplan.
• Reserver budsjett før du utsteder klienthemmeligheten.
• Avvis nye økter hvis leieren mangler tilstrekkelig balanse eller har nådd daglige stemmegrenser.

Under økten

• Spor aktive økter og forventet brennhastighet.
• Bruk samtidighetstak for leietakere og brukere.
• Bruk leverandørstøttede funksjoner for avslutning eller øktoppdatering hvis tilgjengelig.
• Utløs varsler for unormal øktvarighet, gjentatte tilkoblinger eller uvanlig stemmebruk.

Etter økten

• Sett inn leverandørbrukshendelser eller sluttbruksrapporter der tilgjengelig.
• Sett det reserverte budsjettet til faktisk kostnad.
• Hvis eksakt bruk er forsinket eller ufullstendig, hold en konservativ reservasjon inntil avstemming.
• Tilskriv bruk til leietaker, bruker, funksjon, modellprofil og økt-ID.

Dette er mindre nøyaktig enn synkron tekstfakturering i svarøyeblikket, men det er operativt sikrere enn å utstede direkte legitimasjon uten reservasjon.

Verktøyanrop i sanntidsøkter

Sanntidstaleagenter blir ofte mer nyttige når de kan ringe verktøy: søke etter en konto, bestille en avtale, oppdatere en billett eller utløse en arbeidsflyt. Behandle verktøykjøring separat fra lydtransport.

Nettleserens medietilkobling skal ikke innebære tillatelse til å utføre bivirkninger. Gatewayen eller backend bør håndheve:

• Verktøyregister: hvert verktøy har en eier, skjema, omfang og risikonivå.
• Tillatelseslister: øktmaler viser nøyaktig hvilke verktøy som er tilgjengelige.
• Godkjenningsporter: bivirkningshandlinger krever brukerbekreftelse, menneskelig godkjenning eller godkjenning av retningslinjer.
• Separat legitimasjon: verktøylegitimasjon er aldri innebygd i nettleserøkten.
• Bli med i revisjonssporet: hvert verktøykall refererer til sanntidssesjons-ID.

For eksempel kan en støttestemmeagent ha lov til å ringe lookup_order_status automatisk, men refund_payment kan kreve eksplisitt bekreftelse og en godkjenningshendelse for backend. Sanntidsleverandøren kan orkestrere samtalen, men gatewayen din bør styre tillatelsesgrensen.

Synlighet uten proxy for hver byte

Direkte WebRTC-medieflyt reduserer gatewayforsinkelse og båndbreddebelastning, men synligheten blir mer avhengig av leverandørhendelser og dine egne øktmetadata. Design analyser rundt flere beviskilder:

• Søktopprettingsposter fra gatewayen.
• Livssyklushendelser på klientsiden, for eksempel tilkoblet, frakoblet, forsøkt å koble til på nytt, mikrofon avslått eller anrop avsluttet.
• Søkt-ID-er for leverandør, brukshendelser eller endelige bruksposter.
• Varighetsbaserte anslag når leverandørbruken er forsinket.
• Verktøy-anropslogger koblet sammen av økt-ID.
• Budsjettreservasjon og oppgjørsposter.

Ikke vent på perfekt telemetri fra leverandøren før du starter kontroller. Begynn med konservative forbehold og tydelig attribusjon, og forbedre deretter oppgjørsnøyaktigheten etter hvert som leverandørbruksrapportering modnes.

Sikkerhetssjekkliste

• Send aldri standard leverandør API-nøkler til nettleser- eller mobilklienter.
• Bruk kortvarige flyktige klienthemmeligheter for oppstart av økter i sanntid.
• Autentiser sluttbrukeren før token preging.
• Bind myntingbeslutninger til leietaker, bruker, opprinnelse, nonce og enhetsmetadata der det er mulig.
• Behold leverandørens kjøretidslegitimasjon i en hemmelig butikk for backend-hvelv eller gateway.
• Ta opp en sesjonsrevisjonsrad før leverandøren slår inn.
• Bruk leietakergodkjente øktmaler i stedet for vilkårlig klientkonfigurasjon.
• Bruk grenser for samtidighet, daglig bruk og maksimal varighet.
• Bruk verktøyets godkjenningslister og godkjenningsporter for bivirkninger.
• Minimer rå melding og lydoppbevaring som standard.
• Oppretthold en leverandørkapasitetsmatrise for tokens levetid, regioner, verktøy, brukshendelser og oppsigelseskontroller.

Matrise for leverandørkapasitet

Fordi sanntids-API-er er forskjellige, må du modellere gateway-adapteren din etter evner i stedet for antakelser. En enkel matrise kan styre rute- og policybeslutninger:

{
  "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 leietaker krever opphold i EU og oppsigelse på tjenersiden, bør gatewayen bare rute til leverandører og distribusjoner som tilfredsstiller begge. Hvis ingen leverandør oppfyller retningslinjene, kan du ikke lukke den.

Migrasjonsbane

Du trenger ikke bygge alle kontroller på dag én. En praktisk utrulling er:

1. Bare opprettelse av proxy-økter: hold media direkte, men krev at alle sanntidsøkter skal lages av backend eller gateway.
2. Legg til policymaler: erstatt klientleverte modell- og instruksjonsfelt med godkjente profiler.
3. Legg til budsjettreservasjon: reserver konservativ øktkostnad før tokenutstedelse.
4. Legg til livssyklusanalyse: samle øktstart, koble til, koble fra, varighet, leverandørøkt-ID og oppgjørsstatus.
5. Legg til verktøystyring: krever godkjenningslister og godkjenninger for verktøyoppkall i sanntid.
6. Legg til ruting for leverandørkapasitet: velg leverandører etter region, modalitet, hendelsesstøtte og avslutningskontroller.
7. Legg til valgfrie observatør- eller registreringsarbeidsflyter: bare der det er kompatibelt, samtykket og leietaker-godkjent.

Aktiv konklusjon

For stemme-AI i sanntid bør ikke en AI API-gateway automatisk bli et mediarelé. Den sikrere arkitekturen med lavere ventetid er å holde gatewayen ansvarlig for kontrollplanet: autentisere brukere, håndheve leietakerpolicy, reservere budsjett, opprette en revisjonspost, lage en kortvarig legitimasjon og avstemme bruk etter økten.

Kjernen i implementeringsregelen er enkel: nettlesere kan motta kortvarige økthemmeligheter, aldri langvarige leverandørnøkler. Alt annet følger av den grensen: strenge maler, opprinnelsesbevisst preging, samtidige økter, verktøygodkjenninger, bruksoppgjør og leverandørkapasitetsmatriser. Dette gir produktteam sanntids stemmeopplevelser uten å gi opp API nøkkeladministrasjon, AI API kostnadskontroll, team API styring eller AI-bruksanalyse.

Relatert lesing

• leverandørlegitimasjonshvelv for kjøretid keys
• budsjettreservasjon og oppgjørsreskontro