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, mobile veiledere, støttekopiloter eller talegrensesnitt i appen gjennom en AI API-gateway. Målet er nettlesersikkerhet uten å miste styring av leietaker.

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 på en sikker måte.
• Leierbudsjettsjekker kan hoppes over hvis appen kobler til direkte.
• Modell-, region-, stemme-, modalitets- og verktøybegrensninger 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 Realtime 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: Behandle 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 kun motta den minste kortvarige legitimasjonen som trengs for å starte den godkjente økten.

Spådommer: Sanntidsleverandør-API-er 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 bærbare.

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 leietakerpolicy, løser modellprofil, reserverer budsjett, registrerer økten og skaper 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 beslutningen om å opprette økter og avstemmingsbanen.

Anbefalt forespørselsflyt

1. Brukeren åpner en talefunksjon i klientappen.
2. Klienten kaller backend: POST /stemme/økter.
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. Porten evaluerer policy og budsjett.
5. Gatewayen oppretter en lokal realtime_session-post før den kontakter leverandøren.
6. Gatewayen ringer leverandøren med sin beskyttede kjøretidslegitimasjon og oppretter en kortvarig sanntidsøkt med smalt omfang.
7. Gatewayen returnerer bare den flyktige klienthemmeligheten og godkjente øktmetadata til nettleseren.
8. Nettleseren oppretter WebRTC-forbindelsen direkte med leverandøren.
9. Gatewayen tar inn leverandørbrukshendelser, tilbakeringinger, pollingsresultater eller konservative varighetsbaserte estimater.
10. Rekontroen avgjør det reserverte budsjettet og skriver revisjonshendelser.

Pre-mint policy-sjekker

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

I det minste bør gatewayen sjekke:

• Leietakerstatus: aktiv, suspendert, prøveperiode, 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.
• Region og oppbevaringspolicy: 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 leiebryter.

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 lager 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": "stemmestøtte-standard",
  "upstream_model_or_deployment": "sanntidsmodell-x",
  "region": "eastus",
  "session_config_hash": "sha256:...",
  "allowed_modalities": ["lydinngang", "lydutgang"],
  "allowed_tools": ["lookup_order_status"],
  "tool_approval_policy": "godkjenne_sideeffekter",
  "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": "mynting"
}

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
Autorisasjon: Bærer 
Innholdstype: 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": "stemmestøtte-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",
  "godkjent": {
    "model_profile": "stemmestøtte-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 naturlig, 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å gateway-siden.
• Instruksjoner: en serverkontrollert forespørselsmal med leietakergodkjente variabler.
• Stemme: valgt fra en godkjenningsliste.
• Modaliteter: deaktiver tekst-, bilde- eller verktøymoduser med mindre produktet trenger dem.
• Innstillinger for lydinngang: svingdeteksjon, transkripsjonsatferd eller stillhetshåndtering der dette støttes.
• Utdatabegrensninger: maksimal svarlengde eller responsatferd der støttes.
• 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 sanntidstale

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

• Estimer 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 endelige bruksrapporter der tilgjengelig.
• Sett det reserverte budsjettet til faktiske kostnader.
• 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øyutførelse 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 sanntidsøkt-ID.

For eksempel kan en støttetaleagent 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 gateway-latens og båndbreddebelastning, men synlighet blir mer avhengig av leverandørhendelser og dine egne sesjonsmetadata. 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øyanropslogger 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 godkjenningslister for verktøy 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 gatewayadapteren din etter evner i stedet for antagelser. En enkel matrise kan styre ruting og politiske beslutninger:

{
  "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": ["oss", "eu"],
    "tool_approval_supported": sant
  },
  "provider_b": {
    "transports": ["websocket"],
    "ephemeral_client_tokens": sant,
    "token_ttl_seconds": 120,
    "server_side_disconnect": usant,
    "session_update": usant,
    "usage_events": "final_only",
    "regions": ["oss"],
    "tool_approval_supported": usant
  }
}

Hvis en leietaker krever opphold i EU og oppsigelse på serversiden, bør gatewayen bare rute til leverandører og distribusjoner som tilfredsstiller begge. Hvis ingen leverandør oppfyller retningslinjene, kan du ikke lukke.

Migrasjonsbane

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

1. Kun 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 konservative øktkostnader før tokenutstedelse.
4. Legg til livssyklusanalyse: samle inn øktstart, koble til, koble fra, varighet, leverandørøkt-ID og oppgjørsstatus.
5. Legg til verktøystyring: Krev godkjenningslister og godkjenninger for verktøyoppkall i sanntid.
6. Legg til leverandørfunksjonsruting: velg leverandører etter region, modalitet, hendelsesstøtte og avslutningskontroller.
7. Legg til valgfrie observatør- eller registreringsarbeidsflyter: bare der de er kompatible, samtykker og er godkjent av leietaker.

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.

Kjerneimplementeringsregelen er enkel: nettlesere kan motta kortvarige sesjonshemmeligheter, 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 taleopplevelser i sanntid uten å gi opp API-nøkkeladministrasjon, AI API-kostnadskontroll, team-API-styring eller AI-bruksanalyse.

Relatert lesing

• budsjettreservasjon og oppgjørsreskontro