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

Browser- en mobiele apps mogen geen API-sleutels van leveranciers met een lange levensduur 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 spraakagenten, oproepassistenten, mobiele docenten, ondersteunende copiloten of in-app spraakinterfaces bouwen via een AI API-gateway. Het doel is browserveiligheid zonder verlies van tenantbeheer.

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 standaard API-sleutel van een provider niet veilig bevatten.
• Huurderbudgetcontroles kunnen worden overgeslagen als de app rechtstreeks verbinding maakt.
• Model-, regio-, stem-, modaliteit- en toolbeperkingen worden beloften aan de klantzijde.
• Gebruikstoeschrijving wordt onvolledig of vertraagd.
• Beveiligingsteams verliezen een controleerbaar beslissingspunt voordat een sessie begint.

Het praktische ontwerp is niet ‘elke byte proxy’. Het is “makelaar elke sessie.”

Feiten, aanbevelingen en voorspellingen

Feiten: Realtime AI-providers ondersteunen steeds vaker transporten met lage latentie, zoals WebRTC, WebSocket en SIP. Openbare documentatie voor de Realtime API van OpenAI beschrijft realtime interfaces met lage latentie, waaronder WebRTC. Azure OpenAI realtime WebRTC-richtlijnen beschrijven een browsertoepassing die gebruikmaakt van een backend-tokenservice 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 Agents SDK realtime begeleiding beveelt ook een stroom aan waarbij een backend een kortstondig kortstondig clienttoken creëert 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 mag alleen de minimale kortstondige inloggegevens 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 flow bestaat uit vijf delen:

1. Client-app: browser of mobiele app die een spraaksessie aanvraagt.
2. Applicatie-backend: Authenticeert de eindgebruiker en roept de gateway aan, of sluit logica voor het aanmaken van gateway-tokens in als de gateway deel uitmaakt van de backend-stack.
3. AI API-gateway: Dwingt tenantbeleid af, lost modelprofiel op, reserveert budget, registreert de sessie en bewaart een kortstondig clientgeheim van de provider.
4. Realtime provider: Beëindigt WebRTC of een ander realtime transport.
5. Grootboek en analyses: regelt het gebruik zodra providergebeurtenissen, duurgegevens of definitieve gebruiksrapporten 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 mint-verzoek door naar de gateway met tenant-ID, gebruikers-ID, beoogde functie, metagegevens van het apparaat en herkomst.
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 belt de provider 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 regelt het gereserveerde budget en schrijft auditgebeurtenissen.

Beleidscontroles vooraf

Het belangrijkste handhavingspunt is voordat het kortstondige token wordt geslagen. Zodra de browser over een kortstondige inloggegevens beschikt, kan de handhaving halverwege de sessie beperkt zijn, tenzij de provider opties voor sessie-updates, ontkoppeling, 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 volgens plan.
• Toegestane modaliteiten: audio-invoer, audio-uitvoer, tekst, afbeelding of toolaanroepen.
• Stem- en instructiesjabloon: vast of begrensd door beleid.
• Beschikbaar budget: vooraf betaald saldo, gereserveerd maandelijks bedrag of uitgavenplafond per functie.
• Gelijktijdigheid: actieve stemsessies op huurder- en gebruikersniveau.
• Misbruikcontroles: vlaggen voor gebruikersrisico's, herkomstreputatie, ongebruikelijke gesprekssnelheid of 'kill switch' voor huurders.

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

Ontwerp van sessierecord

Maak een sessierecord aan de gatewayzijde voordat u de providerreferenties aanmaakt. Dit geeft u een controleanker, zelfs als het aanmaken 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": "stemondersteuning-standaard",
  "upstream_model_or_deployment": "realtime-model-x",
  "regio": "oost",
  "session_config_hash": "sha256:...",
  "allowed_modalities": ["audio_input", "audio_output"],
  "allowed_tools": ["lookup_order_status"],
  "tool_approval_policy": "goedkeuren_side_effecten",
  "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": "munten"

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 huurdersbeleid.

Efemere eindpunt voor het maken van tokens

Een gateway-gericht eindpunt kan er als volgt uitzien:

POST /v1/realtime/sessions
Autorisatie: Drager 
Inhoudstype: application/json
{
  "tenant_id": "tenant_123",
  "end_user_id": "user_hash_456",
  "feature": "support_voice_agent",
  "oorsprong": "https://app.example.com",
  "device_nonce": "8f3b...",
  "requested_profile": "stemondersteuning-standaard"

Het antwoord mag uw upstream-runtimesleutel niet openbaar maken:

{
  "session_id": "rt_01j...",
  "provider": "provider_a",
  "transport": "webrtc",
  "client_secret": "efemere_secret_hier",
  "expires_at": "2026-08-21T10:01:00Z",
  "goedgekeurd": {
    "model_profile": "stemondersteuning-standaard",
    "max_duration_seconds": 900,
    "modaliteiten": ["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 tot voltooiing van een chat. 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 op een toelatingslijst.
• Modaliteiten: schakel de tekst-, afbeeldings- of toolmodi uit, tenzij het product deze nodig heeft.
• Invoeraudio-instellingen: beurtdetectie, transcriptiegedrag of afhandeling van stilte waar ondersteund.
• Uitvoerbeperkingen: maximale reactieduur of reactiegedrag indien ondersteund.
• Toelatingslijst voor tools: alleen tools die nodig zijn voor de functie.
• Sessielevensduur: korte vervaldatum van inloggegevens plus maximale gespreksduur.

Strikte sjablonen verminderen de flexibiliteit, maar maken de kosten, compliance 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 stem

Het kan lastiger 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 een worst-case of conservatieve sessiekosten op basis van de maximale duur, het model, de modaliteiten en het huurdersplan.
• Reserveer budget voordat u het klantgeheim uitgeeft.
• Wijs nieuwe sessies af als de huurder onvoldoende saldo heeft of de dagelijkse stemlimieten heeft bereikt.

Tijdens de sessie

• Houd actieve sessies en het verwachte brandpercentage 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 het 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 voorbehoud.

Tooloproepen 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.
• Toelaatbare lijsten: 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 ingebed in de browsersessie.
• Aangesloten audittraject: elke toolaanroep verwijst naar de realtime sessie-ID.

Een stemagent voor ondersteuning kan bijvoorbeeld automatisch lookup_order_status bellen, maar voor refund_betaling is mogelijk een expliciete bevestiging en een backend-goedkeuringsgebeurtenis vereist. 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 sessiemetagegevens. Ontwerp analyses rond meerdere bewijsbronnen:

• Sessieaanmaakrecords 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 API-sleutels van standaardproviders naar browser- of mobiele clients.
• Gebruik kortstondige, kortstondige clientgeheimen voor het realtime opstarten van sessies.
• Authenticeer de eindgebruiker voordat de token wordt aangemaakt.
• Bind beslissingen over minting waar mogelijk aan tenant-, gebruiker-, herkomst-, nonce- en apparaatmetagegevens.
• Bewaar de runtimegegevens van de provider in een backendkluis of een geheime gatewayopslag.
• Neem een sessie-auditrij op voordat de provider mint.
• Gebruik door de huurder goedgekeurde sessiesjablonen in plaats van willekeurige clientconfiguratie.
• Pas gelijktijdigheid, dagelijks gebruik en maximale duurlimieten toe.
• Gebruik toelatingslijsten en goedkeuringspoorten voor tools voor bijwerkingen.
• Minimaliseer standaard onbewerkte prompts en audioretentie.
• Houd een matrix met providermogelijkheden bij voor de levensduur van tokens, regio's, tools, gebruiksgebeurtenissen en beëindigingscontroles.

Matrix van de mogelijkheden van de aanbieder

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": waar,
    "token_ttl_seconden": 60,
    "server_side_disconnect": waar,
    "session_update": waar,
    "usage_events": "final_and_incremental",
    "regio's": ["ons", "eu"],
    "tool_approval_supported": waar
  },
  "provider_b": {
    "transports": ["websocket"],
    "ephemeral_client_tokens": waar,
    "token_ttl_seconden": 120,
    "server_side_disconnect": vals,
    "session_update": vals,
    "usage_events": "final_only",
    "regio's": ["ons"],
    "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 close uitgevoerd.

Migratiepad

Je hoeft niet elke controle op dag één te bouwen. Een praktische uitrol is:

1. Alleen proxysessies maken: houd de media direct, maar zorg ervoor dat alle realtime sessies worden aangemaakt door de backend of gateway.
2. Beleidssjablonen toevoegen: door de klant aangeleverde model- en instructievelden vervangen door goedgekeurde profielen.
3. Voeg budgetreservering toe: reserveer conservatieve sessiekosten vóór tokenuitgifte.
4. Voeg levenscyclusanalyses toe: verzamel het begin van de sessie, de verbinding, de verbinding, de duur, de sessie-ID van de provider en de afwikkelingsstatus.
5. Toolbeheer toevoegen: toelatingslijsten en goedkeuringen vereisen voor realtime toolaanroepen.
6. Voeg routering van providermogelijkheden toe: selecteer providers op basis van regio, modaliteit, gebeurtenisondersteuning en beëindigingscontroles.
7. Voeg optionele waarnemers- of opnameworkflows toe: alleen als ze voldoen aan de regels, toestemming hebben gegeven en door de huurder zijn goedgekeurd.

Bruikbare conclusie

Voor realtime stem-AI mag een AI API-gateway niet automatisch een mediarelay worden. De veiligere architectuur met lagere latentie is bedoeld om de gateway de leiding te laten houden over het controlevlak: gebruikers authenticeren, tenantbeleid afdwingen, budget reserveren, een auditrecord maken, een kortstondige referentie met een beperkte scope creëren 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, oorsprongbewuste minting, gelijktijdige sessielimieten, toolgoedkeuringen, gebruiksafrekening en matrices van de mogelijkheden van de provider. Dit geeft productteams realtime spraakervaringen zonder dat ze API-sleutelbeheer, AI API-kostenbeheersing, team-API-beheer of AI-gebruiksanalyses moeten opgeven.

Gerelateerd lezen

• providerreferentiekluis voor runtimesleutels
• budgetreservering en grootboek voor afwikkeling