IA en temps réel sécurisée pour le navigateur via une passerelle API : jetons éphémères, politique des locataires et contrôles de session vocale
Une architecture pratique pour l'IA vocale des navigateurs et mobiles : conservez une faible latence des médias en temps réel avec des informations d'identification client de courte durée pendant que la passerelle applique la politique des locataires, les contrôles budgétaires, les contrôles des outils et les pistes d'audit.
Le navigateur et les applications mobiles ne doivent pas recevoir de clés API de fournisseur à longue durée de vie. Cependant, pour l’IA vocale en temps réel, l’envoi de chaque paquet audio via une passerelle peut ajouter de la latence, des coûts opérationnels et des modes de défaillance. Le meilleur modèle consiste à conserver la passerelle dans le plan de contrôle : authentifier l'utilisateur, appliquer la politique de locataire, réserver le budget, créer un identifiant en temps réel étroit et de courte durée et laisser les médias sensibles à la latence utiliser le transport en temps réel du fournisseur, le cas échéant.
Cet article décrit un modèle de mise en œuvre pour les équipes qui créent des agents vocaux, des assistants d'appel, des tuteurs mobiles, des copilotes d'assistance ou des interfaces vocales dans l'application via une passerelle API IA. L'objectif est la sécurité du navigateur sans perdre la gouvernance des locataires.
Le problème : les connexions directes en temps réel contournent vos contrôles
Un simple proxy côté serveur est intéressant car il centralise les clés et l'observabilité. Pour les demandes de texte standard, c'est souvent le bon modèle. L'audio en temps réel est différent. Une session vocale peut impliquer une entrée de microphone continue, une sortie audio bidirectionnelle, des interruptions, des appels d'outils et des attentes strictes en matière de latence. La transmission proxy de tous les médias via votre passerelle peut transformer celle-ci en un relais multimédia gourmand en bande passante au lieu d'un service de politique et de facturation.
Les connexions directes du navigateur au fournisseur résolvent la latence, mais créent un problème différent :
- Le navigateur ne peut pas contenir en toute sécurité une clé API de fournisseur standard.
- Les vérifications du budget des locataires peuvent être ignorées si l'application se connecte directement.
- Les restrictions de modèle, de région, de voix, de modalité et d'outil deviennent des promesses côté client.
- L'attribution de l'utilisation devient incomplète ou retardée.
- Les équipes de sécurité perdent un point de décision vérifiable avant le début d'une session.
La conception pratique n'est pas « proxy chaque octet ». Il s'agit d'un « courtier à chaque session ».
Faits, recommandations et prédictions
Faits : les fournisseurs d'IA en temps réel prennent de plus en plus en charge les transports à faible latence tels que WebRTC, WebSocket et SIP. La documentation publique de l'API Realtime d'OpenAI décrit les interfaces temps réel à faible latence, notamment WebRTC. Les conseils WebRTC en temps réel d'Azure OpenAI décrivent une application de navigateur utilisant un service de jeton back-end pour récupérer un jeton éphémère avant de démarrer la connexion WebRTC, et mettent en garde contre l'utilisation d'une clé API standard dans une application cliente. Les conseils en temps réel du SDK OpenAI Agents recommandent également un flux dans lequel un backend crée un jeton client éphémère de courte durée et le navigateur l'utilise pour établir une connexion WebRTC.
Recommandations : Traitez la passerelle comme l'autorité de session. Il doit décider si une session en temps réel peut exister, avec quel modèle, dans quelle région, pour quel locataire, dans quel budget et avec quels outils. Le client ne doit recevoir que les informations d'identification minimales de courte durée nécessaires pour démarrer cette session approuvée.
Prédictions : les API des fournisseurs en temps réel resteront inégales pendant un certain temps. La durée de vie des jetons, les champs de configuration de session, les contrôles de déconnexion côté serveur, les événements d'utilisation et la prise en charge des régions diffèrent. Les passerelles doivent modéliser explicitement les capacités des fournisseurs au lieu de prétendre que toutes les API en temps réel sont parfaitement portables.
Architecture de référence : passerelle comme plan de contrôle temps réel
Un flux en temps réel sécurisé par un navigateur comporte cinq parties :
- Application client : navigateur ou application mobile demandant une session vocale.
- Backend de l'application : authentifie l'utilisateur final et appelle la passerelle, ou intègre la logique de création de jetons de passerelle si la passerelle fait partie de la pile backend.
- AI API gateway : applique la politique de locataire, résout le profil du modèle, réserve le budget, enregistre la session et crée un secret client de fournisseur éphémère.
- Fournisseur en temps réel : met fin à WebRTC ou à un autre transport en temps réel.
- Ledger et analyses : règle l'utilisation une fois que les événements du fournisseur, les données de durée ou les rapports d'utilisation finale sont disponibles.
La passerelle n'a pas besoin de relayer chaque trame audio pour rester faisant autorité. Il doit être propriétaire de la décision de création de session et du chemin de réconciliation.
Flux de requête recommandé
- L'utilisateur ouvre une fonctionnalité vocale dans l'application client.
- Le client appelle votre backend :
POST /voice/sessions. - Le backend vérifie la session utilisateur et transmet une requête mint à la passerelle avec l'ID de locataire, l'ID d'utilisateur, la fonctionnalité prévue, les métadonnées de l'appareil et l'origine.
- La passerelle évalue la politique et le budget.
- La passerelle crée un enregistrement local
realtime_sessionavant de contacter le fournisseur. - La passerelle appelle le fournisseur avec ses identifiants d'exécution protégés et crée une session éphémère en temps réel à portée étroite.
- La passerelle renvoie uniquement le secret client éphémère et les métadonnées de session approuvées au navigateur.
- Le navigateur établit la connexion WebRTC directement avec le fournisseur.
- La passerelle ingère les événements d'utilisation du fournisseur, les rappels, les résultats d'interrogation ou les estimations prudentes basées sur la durée.
- Le grand livre règle le budget réservé et écrit les événements d'audit.
Vérifications préalables aux règles
Le point d'application le plus important se situe avant la création du jeton éphémère. Une fois que le navigateur dispose d'un identifiant de courte durée, l'application en cours de session peut être limitée, à moins que le fournisseur ne prenne en charge les contrôles de mise à jour de session, de déconnexion, d'observateur ou de rappel.
Au minimum, la passerelle doit vérifier :
- Statut du locataire : actif, suspendu, à l'essai, prépayé, facturé ou mis en quarantaine.
- Droits de l'utilisateur : indique si cet utilisateur peut utiliser la voix en temps réel, et pas seulement le chat textuel.
- Profil de modèle autorisé : modèle ou déploiement en temps réel approuvé, et non ID de modèle arbitraire fourni par le client.
- Région et stratégie de rétention : indique si la région du fournisseur sélectionné et l'ensemble des fonctionnalités correspondent aux règles de données du locataire.
- Durée maximale de la session : par exemple, 5, 15 ou 30 minutes par plan.
- Modalités autorisées : entrée audio, sortie audio, appels de texte, d'image ou d'outil.
- Modèle de voix et d'instructions : fixe ou limité par une stratégie.
- Budget disponible : solde prépayé, allocation mensuelle réservée ou plafond de dépenses par fonctionnalité.
- Concurrence : sessions vocales actives au niveau du locataire et au niveau de l'utilisateur.
- Contrôle des abus : indicateurs de risque utilisateur, réputation d'origine, vitesse d'appel inhabituelle ou kill switch de locataire.
Une valeur par défaut sûre consiste à rejeter les demandes ambiguës. Si le client demande un modèle, un outil, une voix ou une région qui ne figure pas dans la politique en temps réel du locataire, la passerelle doit renvoyer une erreur de politique claire au lieu d'élargir l'accès en silence.
Conception des enregistrements de session
Créez un enregistrement de session côté passerelle avant de créer les informations d'identification du fournisseur. Cela vous donne une ancre d'audit même si la création du fournisseur réussit mais que le navigateur ne se connecte jamais.
{
"session_id": "rt_01j...",
"tenant_id": "tenant_123",
"end_user_id": "user_hash_456",
"fournisseur": "fournisseur_a",
"provider_session_id": nul,
"model_profile": "standard de support vocal",
"upstream_model_or_deployment": "modèle-temps réel-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": "frappage"
Ne stockez pas l'audio brut du microphone ni les invites complètes par défaut. Stockez les hachages de configuration, les identifiants, les décisions politiques et les métadonnées minimales suffisantes pour l'audit, le support et la facturation. Si l'enregistrement est requis, rendez-le explicite, prenant en compte le consentement et axé sur la politique des locataires.
Point de terminaison de frappe de jetons éphémères
Un point de terminaison côté passerelle pourrait ressembler à ceci :
POST /v1/realtime/sessions
Autorisation : Porteur
Type de contenu : application/json
{
"tenant_id": "tenant_123",
"end_user_id": "user_hash_456",
"feature": "support_voice_agent",
"origine": "https://app.example.com",
"device_nonce": "8f3b...",
"requested_profile": "standard de support vocal"
La réponse ne doit pas exposer votre clé d'exécution en amont :
{
"session_id": "rt_01j...",
"fournisseur": "fournisseur_a",
"transport": "webrtc",
"client_secret": "ephemeral_secret_here",
"expires_at": "2026-08-21T10:01:00Z",
"approuvé": {
"model_profile": "standard de support vocal",
"max_duration_seconds": 900,
"modalités": ["audio_input", "audio_output"],
"outils": ["lookup_order_status"]
}
Lier l'émission à l'origine, à la session utilisateur authentifiée, au locataire et à un nom occasionnel. Le fournisseur peut ne pas prendre en charge toutes ces liaisons de manière native, alors appliquez ce que vous pouvez au niveau de la passerelle : limitez le débit des tentatives de création, rejetez les origines inattendues, enregistrez les métadonnées de l'appareil et maintenez la durée de vie du jeton courte.
Modèles de session : affiner par défaut
Un modèle de session en temps réel doit être plus restrictif qu'une demande générale de fin de chat. Les sessions vocales sont interactives, plus difficiles à inspecter en temps réel et peuvent durer plus longtemps que prévu.
Les champs de modèle recommandés incluent :
- Modèle ou déploiement fixe : choisi par un profil de modèle côté passerelle.
- Instructions : un modèle d'invite contrôlé par le serveur avec des variables approuvées par le locataire.
- Voix : sélectionnée dans une liste autorisée.
- Modalités : désactivez les modes texte, image ou outil, sauf si le produit en a besoin.
- Paramètres audio d'entrée : détection d'activation, comportement de transcription ou gestion du silence lorsque cela est pris en charge.
- Contraintes de sortie : longueur de réponse maximale ou comportement de réponse lorsque cela est pris en charge.
- Liste autorisée des outils : seuls les outils requis pour la fonctionnalité.
- Durée de vie de la session : courte expiration des identifiants et durée maximale de l'appel.
Les modèles stricts réduisent la flexibilité, mais ils facilitent les coûts, la conformité et l'assistance. Si les équipes produit ont besoin de voix ou d'instructions dynamiques, exposez des variantes de profil contrôlées au lieu de transmettre une configuration client arbitraire au fournisseur.
Contrôles budgétaires pour la voix en temps réel
L'utilisation en temps réel peut être plus difficile à évaluer avant l'arrivée du fournisseur final. Une séance peut durer cinq secondes ou vingt minutes. Il peut inclure une entrée audio, une sortie audio, une transcription, des appels d'outils et des jetons de texte. La passerelle doit donc combiner réservation, plafonds et rapprochement.
Avant la frappe
- Estimez le coût d'une session dans le pire des cas ou avec prudence à partir de la durée maximale, du modèle, des modalités et du plan du locataire.
- Réservez le budget avant de fournir la clé secrète client.
- Rejetez les nouvelles sessions si le locataire ne dispose pas d'un solde suffisant ou a atteint les limites de voix quotidiennes.
Pendant la séance
- Suivez les sessions actives et le taux de combustion attendu.
- Appliquer des plafonds de simultanéité pour les locataires et les utilisateurs.
- Utilisez les fonctionnalités de résiliation ou de mise à jour de session prises en charge par le fournisseur, si disponibles.
- Déclenchez des alertes en cas de durée de session anormale, de reconnexions répétées ou d'utilisation inhabituelle de la voix.
Après la séance
- Ingérer les événements d'utilisation du fournisseur ou les rapports d'utilisation finale, le cas échéant.
- Réglez le budget réservé sur le coût réel.
- Si l'utilisation exacte est retardée ou incomplète, effectuez une réservation prudente jusqu'au rapprochement.
- Attribuer l'utilisation au locataire, à l'utilisateur, à la fonctionnalité, au profil de modèle et à l'ID de session.
C'est moins précis que la facturation par SMS synchrone au moment de la réponse, mais c'est plus sûr sur le plan opérationnel que l'émission d'informations d'identification directes sans réservation.
Appels d'outils dans les sessions en temps réel
Les agents vocaux en temps réel deviennent souvent plus utiles lorsqu'ils peuvent appeler des outils : rechercher un compte, prendre rendez-vous, mettre à jour un ticket ou déclencher un flux de travail. Traitez l'exécution de l'outil séparément du transport audio.
La connexion multimédia du navigateur ne doit pas impliquer l'autorisation d'effectuer des effets secondaires. La passerelle ou le backend doit appliquer :
- Registre d'outils : chaque outil a un propriétaire, un schéma, des étendues et un niveau de risque.
- Listes autorisées : les modèles de session répertorient exactement les outils disponibles.
- Portes d'approbation : les actions à effet secondaire nécessitent la confirmation de l'utilisateur, l'approbation humaine ou l'approbation de la politique.
- Identifiants séparés : les identifiants de l'outil ne sont jamais intégrés à la session du navigateur.
- Piste d'audit jointe : chaque appel d'outil fait référence à l'ID de session en temps réel.
Par exemple, un agent vocal d'assistance peut être autorisé à appeler automatiquement lookup_order_status, mais refund_payment peut nécessiter une confirmation explicite et un événement d'approbation backend. Le fournisseur en temps réel peut orchestrer la conversation, mais votre passerelle doit régir la limite d'autorisation.
Visibilité sans proxy pour chaque octet
Le flux multimédia WebRTC direct réduit la latence de la passerelle et la charge de bande passante, mais la visibilité devient plus dépendante des événements du fournisseur et de vos propres métadonnées de session. Concevoir des analyses autour de plusieurs sources de preuves :
- Enregistrements de création de session à partir de la passerelle.
- Événements du cycle de vie côté client, tels que connexion, déconnexion, tentative de reconnexion, microphone refusé ou appel terminé.
- ID de session du fournisseur, événements d'utilisation ou enregistrements d'utilisation finale.
- Estimations basées sur la durée lorsque l'utilisation du fournisseur est retardée.
- Journaux d'appels d'outils joints par ID de session.
- Enregistrements de réservation et de règlement du budget.
N'attendez pas une télémétrie parfaite du fournisseur avant de lancer des contrôles. Commencez par des réservations prudentes et une attribution claire, puis améliorez la précision des règlements à mesure que les rapports d'utilisation du fournisseur évoluent.
Liste de contrôle de sécurité
- N'envoyez jamais de clés API de fournisseur standard au navigateur ou aux clients mobiles.
- Utilisez des secrets client éphémères de courte durée pour le démarrage de session en temps réel.
- Authentifiez l'utilisateur final avant la création de jetons.
- Liez les décisions de frappe aux métadonnées du locataire, de l'utilisateur, de l'origine, du nom occasionnel et de l'appareil lorsque cela est possible.
- Conservez les informations d'identification d'exécution du fournisseur dans un coffre-fort back-end ou un magasin de secrets de passerelle.
- Enregistrez une ligne d'audit de session avant la création du fournisseur.
- Utilisez des modèles de session approuvés par les locataires au lieu d'une configuration client arbitraire.
- Appliquer des limites de simultanéité, d'utilisation quotidienne et de durée maximale.
- Utilisez les listes autorisées et portes d'approbation d'outils pour les effets secondaires.
- Réduire par défaut les invites brutes et la rétention audio.
- Maintenir une matrice de capacités du fournisseur pour la durée de vie des jetons, les régions, les outils, les événements d'utilisation et les contrôles de terminaison.
Matrice des capacités du fournisseur
Étant donné que les API en temps réel diffèrent, modélisez votre adaptateur de passerelle en fonction de capacités plutôt que d'hypothèses. Une simple matrice peut guider les décisions de routage et de politique :
{
"fournisseur_a": {
"transports": ["webrtc", "websocket"],
"ephemeral_client_tokens": vrai,
"token_ttl_seconds": 60,
"server_side_disconnect": vrai,
"session_update" : vrai,
"usage_events": "final_and_incremental",
"regions": ["us", "eu"],
"tool_approval_supported" : vrai
},
"fournisseur_b": {
"transports": ["websocket"],
"ephemeral_client_tokens": vrai,
"token_ttl_seconds": 120,
"server_side_disconnect": faux,
"session_update": faux,
"usage_events": "final_only",
"régions": ["nous"],
"tool_approval_supported" : faux
}
Si un locataire nécessite une résidence dans l'UE et une terminaison côté serveur, la passerelle doit être acheminée uniquement vers des fournisseurs et des déploiements qui satisfont aux deux. Si aucun fournisseur ne satisfait à la politique, échec de fermeture.
Chemin de migration
Vous n'avez pas besoin de créer chaque contrôle dès le premier jour. Un déploiement pratique est :
- Création de session proxy uniquement : conservez les médias directs, mais exigez que toutes les sessions en temps réel soient créées par le backend ou la passerelle.
- Ajouter des modèles de règles : remplacez les champs de modèle et d'instructions fournis par le client par des profils approuvés.
- Ajouter une réservation budgétaire : réservez un coût de session prudent avant l'émission du jeton.
- Ajouter des analyses de cycle de vie : collectez le démarrage, la connexion, la déconnexion, la durée, l'ID de session du fournisseur et l'état du règlement.
- Ajouter une gouvernance des outils : exiger des listes vertes et des approbations pour les appels d'outils en temps réel.
- Ajouter le routage des fonctionnalités du fournisseur : sélectionnez les fournisseurs par région, modalité, prise en charge des événements et contrôles de terminaison.
- Ajoutez des workflows d'observateur ou d'enregistrement facultatifs : uniquement lorsque cela est conforme, consenti et approuvé par le locataire.
Conclusion exploitable
Pour l'IA vocale en temps réel, une passerelle API IA ne doit pas automatiquement devenir un relais multimédia. L'architecture la plus sûre et à faible latence consiste à garder la passerelle en charge du plan de contrôle : authentifier les utilisateurs, appliquer la politique des locataires, réserver le budget, créer un enregistrement d'audit, créer un identifiant éphémère à portée étroite et réconcilier l'utilisation après la session.
La règle de mise en œuvre principale est simple : les navigateurs peuvent recevoir des secrets de session de courte durée, jamais des clés de fournisseur de longue durée. Tout le reste découle de cette frontière : modèles stricts, frappe tenant compte de l'origine, limites de sessions simultanées, approbations d'outils, règlement d'utilisation et matrices de capacités des fournisseurs. Cela offre aux équipes produit des expériences vocales en temps réel sans renoncer à la gestion des clés API, au contrôle des coûts des API IA, à la gouvernance des API d'équipe ou à l'analyse de l'utilisation de l'IA.