Browserveilige realtime AI via een API-gateway: kortstondige tokens, huurdersbeleid en spraaksessiecontroles

Browser- en mobiele apps mogen geen langlevende provider API-sleutels ontvangen. Voor realtime spraak-AI kan het verzenden van elk audiopakket via een gateway echter latentie, operationele kosten en foutmodi toevoegen. Het betere patroon is om de gateway in het controlevlak te houden: authenticeer de gebruiker, dwing het tenantbeleid af, reserveer een budget, zorg voor een beperkte realtime-referentie met een korte levensduur en laat latentiegevoelige media waar nodig het realtime transport van de provider gebruiken.

Dit artikel beschrijft een implementatiepatroon voor teams die stemagenten, oproepassistenten, mobiele docenten, ondersteunende copiloten of in-app steminterfaces bouwen via een AI API gateway. Het doel is browserveiligheid zonder het beheer van de tenants te verliezen.

Het probleem: directe realtime verbindingen omzeilen uw bedieningselementen

Een eenvoudige server-side proxy is aantrekkelijk omdat deze de sleutels en zichtbaarheid centraliseert. Voor standaard tekstaanvragen is dat vaak het juiste model. Realtime audio is anders. Een spraaksessie kan gepaard gaan met continue microfooninvoer, bidirectionele audio-uitvoer, onderbrekingen, gereedschapsoproepen en strikte latentieverwachtingen. Door alle media via uw gateway te proxyen, kan de gateway veranderen in een bandbreedte-intensieve mediarelay in plaats van een beleids- en factureringsservice.

Directe browser-naar-provider-verbindingen lossen de latentie op, maar creëren een ander probleem:

• De browser kan een standaardprovidersleutel API niet veilig vasthouden.
• Huurderbudgetcontroles kunnen worden overgeslagen als de app rechtstreeks verbinding maakt.
• Model-, regio-, stem-, modaliteit- en toolbeperkingen worden beloften aan de clientzijde.
• Gebruikstoeschrijving wordt onvolledig of vertraagd.
• Beveiligingsteams verliezen een controleerbaar beslissingspunt voordat een sessie begint.

Het praktische ontwerp is niet 'elke byte proxy'. Het is 'elke sessie makelaar'.

Feiten, aanbevelingen en voorspellingen

Feiten: Realtime AI-providers ondersteunen steeds vaker transporten met lage latentie, zoals WebRTC, WebSocket en SIP. Openbare documentatie voor OpenAI’s Realtime API beschrijft realtime interfaces met lage latentie, inclusief WebRTC. Azure OpenAI realtime WebRTC-richtlijnen beschrijven een browsertoepassing die een backend-tokenservice gebruikt om een ​​kortstondig token op te halen voordat de WebRTC-verbinding wordt gestart, en waarschuwt voor het gebruik van een standaard API-sleutel in een clienttoepassing. OpenAI Agenten SDK realtime begeleiding beveelt ook een stroom aan waarbij een backend een kortstondig kortstondig clienttoken maakt en de browser dit gebruikt om een WebRTC-verbinding tot stand te brengen.

Aanbevelingen: behandel de gateway als sessie-autoriteit. Het moet beslissen of er een realtime sessie mag bestaan, met welk model, in welke regio, voor welke huurder, onder welk budget en met welke tools. De cliënt zou alleen de minimale kortstondige inloggegevens moeten ontvangen die nodig zijn om die goedgekeurde sessie te starten.

Voorspellingen: Realtime provider-API's zullen een tijdje ongelijk blijven. De levensduur van tokens, sessieconfiguratievelden, controles voor het verbreken van verbindingen aan de serverzijde, gebruiksgebeurtenissen en regio-ondersteuning zullen verschillen. Gateways moeten de mogelijkheden van de provider expliciet modelleren in plaats van te doen alsof alle realtime API's perfect draagbaar zijn.

Referentiearchitectuur: gateway als realtime besturingsvlak

Een browserveilige realtime stroom bestaat uit vijf delen:

1. Client-app: Browser of mobiele app vraagt om een spraaksessie.
2. Applicatie-backend: Authenticeert de eindgebruiker en roept de gateway aan, of sluit logica voor het aanmaken van gatewaytokens in als de gateway deel uitmaakt van de backend-stack.
3. AI API gateway: Dwingt het huurdersbeleid af, lost het modelprofiel op, reserveert budget, registreert de sessie en bewaart een tijdelijk clientgeheim van de provider.
4. Realtime provider: Beëindigt WebRTC of een ander realtime transport.
5. Grootboek en analyse: Verrekent het gebruik zodra providergebeurtenissen, duurgegevens of eindgebruiksrapporten beschikbaar zijn.

De gateway hoeft niet elk audioframe door te geven om gezaghebbend te blijven. Het moet eigenaar zijn van het besluit tot het maken van een sessie en het afstemmingspad.

Aanbevolen verzoekstroom

1. De gebruiker opent een spraakfunctie in de client-app.
2. De client roept uw backend aan: POST /voice/sessions.
3. De backend verifieert de gebruikerssessie en stuurt een nieuw verzoek door naar de gateway met tenant-ID, gebruikers-ID, beoogde functie, metagegevens van het apparaat en oorsprong.
4. De gateway evalueert beleid en budget.
5. De gateway maakt een lokale realtime_session record voordat er contact wordt opgenomen met de provider.
6. De gateway roept de provider aan met zijn beschermde runtime-referentie en creëert een kortstondige realtime sessie met een beperkt bereik.
7. De gateway retourneert alleen het kortstondige clientgeheim en de goedgekeurde sessiemetagegevens naar de browser.
8. De browser brengt de WebRTC-verbinding rechtstreeks met de provider tot stand.
9. De gateway registreert gebruiksgebeurtenissen van de provider, terugbelverzoeken, pollingresultaten of conservatieve, op duur gebaseerde schattingen.
10. Het grootboek verrekent het gereserveerde budget en schrijft auditgebeurtenissen.

Beleidscontroles vooraf

Het belangrijkste handhavingspunt is voordat het kortstondige token wordt geslagen. Zodra de browser een kortstondige inloggegevens heeft, kan het afdwingen van de sessie halverwege de sessie beperkt zijn, tenzij de provider opties voor sessie-updates, verbroken verbindingen, waarnemers of terugbellen ondersteunt.

De gateway moet minimaal het volgende controleren:

• Huurderstatus: actief, opgeschort, proefperiode, vooraf betaald, gefactureerd of in quarantaine geplaatst.
• Gebruikersrechten: of deze gebruiker realtime spraak mag gebruiken, niet alleen tekstchat.
• Toegestaan modelprofiel: goedgekeurd realtime model of implementatie, geen willekeurige, door de klant verstrekte model-ID's.
• Regio en bewaarbeleid: of de geselecteerde providerregio en functieset overeenkomen met de gegevensregels van de tenant.
• Maximale sessieduur: bijvoorbeeld 5, 15 of 30 minuten per abonnement.
• Toegestane modaliteiten: audio-invoer, audio-uitvoer, tekst, afbeelding of toolaanroepen.
• Stem- en instructiesjabloon: vast of begrensd door beleid.
• Beschikbaar budget: prepaid-saldo, gereserveerd maandelijks bedrag of uitgavenplafond per functie.
• Gelijktijdigheid: actieve spraaksessies op tenant- en gebruikersniveau.
• Misbruikcontroles: vlaggen voor gebruikersrisico's, herkomstreputatie, ongebruikelijke gesprekssnelheid of 'kill switch' voor huurders.

Een veilige standaard is het weigeren van dubbelzinnige verzoeken. Als de client om een model, tool, stem of regio vraagt die niet in het realtime beleid van de tenant staat, moet de gateway een duidelijke beleidsfout retourneren in plaats van de toegang stilletjes te vergroten.

Ontwerp van sessierecord

Maak een sessierecord aan de gatewayzijde voordat u de providerreferenties aanmaakt. Dit geeft u een controleanker, zelfs als het maken van de provider slaagt maar de browser nooit verbinding maakt.

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

Sla standaard geen onbewerkte microfoonaudio of volledige aanwijzingen op. Bewaar configuratie-hashes, ID's, beleidsbeslissingen en minimale metagegevens die voldoende zijn voor audit, ondersteuning en facturering. Als opname vereist is, maak dit dan expliciet, bewust van de toestemming en gebaseerd op het tenantbeleid.

Efemere eindpunt voor het aanmaken van tokens

Een op een gateway gericht eindpunt kan er als volgt uitzien:

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

Het antwoord mag uw upstream-runtimesleutel niet openbaar maken:

{
  "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 uitgifte aan oorsprong, geverifieerde gebruikerssessie, tenant en een nonce. Het is mogelijk dat de provider niet al deze bindingen native ondersteunt, dus dwing af wat je kunt bij de gateway: beperk het aantal mint-pogingen, weiger onverwachte oorsprong, registreer metagegevens van het apparaat en houd de levensduur van het token kort.

Sessiesjablonen: standaard smal

Een realtime sessiesjabloon zou restrictiever moeten zijn dan een algemeen verzoek om een chat te voltooien. Spraaksessies zijn interactief, moeilijker in realtime te inspecteren en kunnen langer duren dan verwacht.

Aanbevolen sjabloonvelden zijn onder meer:

• Vast model of implementatie: gekozen door een modelprofiel aan de gatewayzijde.
• Instructies: een servergestuurde promptsjabloon met door de tenant goedgekeurde variabelen.
• Stem: geselecteerd van een toelatingslijst.
• Modaliteiten: schakel tekst-, afbeeldings- of toolmodi uit, tenzij het product deze nodig heeft.
• Invoeraudio-instellingen: afslagdetectie, transcriptiegedrag of afhandeling van stilte indien ondersteund.
• Uitvoerbeperkingen: maximale reactielengte of reactiegedrag indien ondersteund.
• Toelatingslijst voor tools: alleen tools vereist voor de functie.
• Sessieduur: korte vervaldatum van inloggegevens plus maximale gespreksduur.

Strikte sjablonen verminderen de flexibiliteit, maar maken de kosten, naleving en ondersteuning eenvoudiger. Als productteams dynamische stemmen of instructies nodig hebben, stel dan gecontroleerde profielvarianten bloot in plaats van willekeurige klantconfiguraties door te geven aan de provider.

Budgetbediening voor realtime spraak

Het kan moeilijker zijn om voor realtime gebruik een prijs te bepalen voordat het uiteindelijke providergebruik arriveert. Een sessie kan vijf seconden of twintig minuten duren. Het kan audio-invoer, audio-uitvoer, transcriptie, tooloproepen en teksttokens omvatten. De gateway moet daarom reservering, limieten en afstemming combineren.

Vóór het slaan

• Schat de sessiekosten in het slechtste geval of op een conservatieve manier op basis van de maximale duur, het model, de modaliteiten en het huurdersplan.
• Reserveer budget voordat u het klantgeheim uitgeeft.
• Weiger nieuwe sessies als de huurder onvoldoende saldo heeft of de dagelijkse stemlimieten heeft bereikt.

Tijdens de sessie

• Houd actieve sessies en verwachte brandsnelheid bij.
• Pas gelijktijdigheidslimieten voor tenants en gebruikers toe.
• Gebruik door de provider ondersteunde beëindigings- of sessie-updatefuncties, indien beschikbaar.
• Genereer waarschuwingen bij abnormale sessieduur, herhaaldelijk opnieuw verbinding maken of ongebruikelijk stemgebruik.

Na de sessie

• Gebruiksgebeurtenissen van de provider of eindgebruiksrapporten opnemen, indien beschikbaar.
• Verreken het gereserveerde budget met de werkelijke kosten.
• Als het exacte gebruik vertraagd of onvolledig is, maak dan een conservatieve reservering tot er overeenstemming is bereikt.
• Wijs gebruik toe aan tenant, gebruiker, functie, modelprofiel en sessie-ID.

Dit is minder exact dan synchrone sms-facturering op het moment van reactie, maar het is operationeel veiliger dan het uitgeven van directe inloggegevens zonder reservering.

Toolaanroepen binnen realtime sessies

Realtime stemagenten worden vaak nuttiger wanneer ze tools kunnen bellen: een account zoeken, een afspraak boeken, een ticket bijwerken of een workflow activeren. Behandel de uitvoering van het gereedschap afzonderlijk van het audiotransport.

De mediaverbinding van de browser mag geen toestemming impliceren om bijwerkingen uit te voeren. De gateway of backend moet het volgende afdwingen:

• Toolregister: elke tool heeft een eigenaar, schema, bereik en risiconiveau.
• Toelatingslijsten: sessiesjablonen vermelden precies welke tools beschikbaar zijn.
• Goedkeuringspoorten: acties met neveneffecten vereisen bevestiging van de gebruiker, menselijke goedkeuring of beleidsgoedkeuring.
• Afzonderlijke inloggegevens: inloggegevens voor de tool worden nooit ingesloten in de browsersessie.
• Aangesloten bij audit trail: elke toolaanroep verwijst naar de realtime sessie-ID.

Een stemagent voor ondersteuning mag bijvoorbeeld automatisch lookup_order_status bellen, maar refund_payment vereist mogelijk een expliciete bevestiging en een backend-goedkeuringsgebeurtenis. De realtime provider kan het gesprek orkestreren, maar uw gateway moet de toestemmingsgrens bepalen.

Zichtbaarheid zonder elke byte te proxyen

Directe WebRTC-mediastroom vermindert de latentie van de gateway en de bandbreedtebelasting, maar de zichtbaarheid wordt meer afhankelijk van providergebeurtenissen en uw eigen sessiemetadata. Ontwerp analyses rond meerdere bewijsbronnen:

• Records voor het maken van sessies vanaf de gateway.
• Levenscyclusgebeurtenissen aan de clientzijde, zoals verbonden, verbroken, poging tot opnieuw verbinden, microfoon geweigerd of gesprek beëindigd.
• Providersessie-ID's, gebruiksgebeurtenissen of eindgebruiksrecords.
• Op duur gebaseerde schattingen wanneer het gebruik van de provider wordt uitgesteld.
• Tool-oproeplogboeken samengevoegd door sessie-ID.
• Bestanden voor budgetreserveringen en -afrekeningen.

Wacht niet op perfecte providertelemetrie voordat u de bedieningselementen start. Begin met conservatieve reserveringen en duidelijke attributie, en verbeter vervolgens de nauwkeurigheid van de afwikkeling naarmate de rapportage over het gebruik van de provider volwassener wordt.

Beveiligingschecklist

• Stuur nooit standaardprovider API-sleutels naar browser- of mobiele clients.
• Gebruik kortstondige, tijdelijke clientgeheimen voor het realtime opstarten van sessies.
• Authenticeer de eindgebruiker voordat tokens worden aangemaakt.
• Bind beslissingen over minting waar mogelijk aan tenant-, gebruiker-, herkomst-, nonce- en apparaatmetadata.
• Bewaar de runtimegegevens van de provider in een backendkluis of een geheime gatewayopslag.
• Neem een sessiecontrolerij op voordat de provider aan de slag gaat.
• Gebruik door de huurder goedgekeurde sessiesjablonen in plaats van willekeurige clientconfiguratie.
• Pas gelijktijdigheid, dagelijks gebruik en maximale duurlimieten toe.
• Gebruik toelatingslijsten voor tools en goedkeuringspoorten voor bijwerkingen.
• Minimaliseer standaard onbewerkte prompts en audioretentie.
• Houd een matrix met providermogelijkheden bij voor tokenlevensduur, regio's, tools, gebruiksgebeurtenissen en beëindigingscontroles.

Matrix van mogelijkheden van providers

Omdat realtime API's verschillen, moet u uw gatewayadapter modelleren op basis van mogelijkheden in plaats van op basis van aannames. Een eenvoudige matrix kan routerings- en beleidsbeslissingen sturen:

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

Als een tenant een EU-residentie en beëindiging aan de serverzijde vereist, mag de gateway alleen routeren naar providers en implementaties die aan beide voldoen. Als geen enkele provider aan het beleid voldoet, wordt de fail-closed uitgevoerd.

Migratiepad

Je hoeft niet elk besturingselement op dag één te bouwen. Een praktische uitrol is:

1. Alleen proxysessies maken: houd media direct, maar vereist dat alle realtime sessies worden aangemaakt door de backend of gateway.
2. Beleidssjablonen toevoegen: vervang door de klant aangeleverde model- en instructievelden door goedgekeurde profielen.
3. Budgetreservering toevoegen: reserveer conservatieve sessiekosten vóór tokenuitgifte.
4. Levenscyclusanalyses toevoegen: verzamel sessiestart, verbinding, verbinding, duur, providersessie-ID en afwikkelingsstatus.
5. Toolbeheer toevoegen: toelatingslijsten en goedkeuringen vereisen voor realtime toolaanroepen.
6. Voeg routering van providermogelijkheden toe: selecteer providers op regio, modaliteit, gebeurtenisondersteuning en beëindigingsopties.
7. Voeg optionele waarnemers- of opnameworkflows toe: alleen indien conform, goedgekeurd en door de huurder goedgekeurd.

Bruikbare conclusie

Voor realtime stem-AI moet een AI API-gateway niet automatisch een mediarelais worden. De veiligere architectuur met een lagere latentie is bedoeld om de gateway de leiding te geven over het controlevlak: gebruikers authenticeren, tenantbeleid afdwingen, budget reserveren, een auditrecord maken, kortstondige referenties met een beperkt bereik aanmaken en het gebruik na de sessie afstemmen.

De kernimplementatieregel is eenvoudig: browsers kunnen kortstondige sessiegeheimen ontvangen, nooit langlevende providersleutels. Al het andere volgt uit die grens: strikte sjablonen, oorsprongsbewuste muntbewerkingen, gelijktijdige sessielimieten, goedkeuringen van tools, gebruiksafrekening en matrices van de mogelijkheden van de provider. Dit geeft productteams realtime spraakervaringen zonder API sleutelbeheer, AI API kostenbeheersing, team API bestuur of AI-gebruiksanalyses op te geven.

Gerelateerd lezen

• providerreferentiekluis voor runtimesleutels
• budgetreservering en -afrekening grootboek