Les passerelles IA sont désormais des infrastructures critiques. Traitez-les comme telles.
Votre passerelle IA peut sembler anodine. En pratique, elle devient l’un des systèmes les plus privilégiés de l’entreprise.
La passerelle achemine les requêtes vers les modèles, stocke ou récupère les identifiants des fournisseurs, applique la politique d’utilisation, connecte les applications aux systèmes de recherche, et détient souvent la configuration qui décide quel modèle peut accéder à quelles données. Cela en fait un plan de contrôle, pas une couche de commodité.
Un récent rapport Microsoft Threat Intelligence illustre ce point de façon concrète. Dans les enquêtes sur les environnements LiteLLM, RAGFlow et Kestra compromis, les attaquants visaient le même but : identifiants, persistance et accès aux systèmes derrière la charge IA. Dans le cas LiteLLM, Microsoft a observé la collecte d’identifiants depuis le runtime de la passerelle, la collecte depuis une base de données de support, et des activités de persistance. Ce n’est pas une histoire de modèle produisant une mauvaise réponse, mais d’un service IA devenant une tête de pont en entreprise.
Pour les responsables sécurité, l’implication est simple : l’organisation ne peut pas gouverner les agents IA uniquement au niveau des requêtes, modèles ou utilisateurs. Elle doit aussi gouverner l’infrastructure qui connecte ces couches.
Pourquoi la passerelle est devenue le talon d’Achille
L’architecture applicative traditionnelle répartit la confiance entre services. L’architecture IA la concentre souvent.
Une passerelle ou couche d’orchestration peut contenir des clés fournisseurs de modèles, règles de routage des locataires, clés virtuelles, chaînes de connexion aux bases de données, identifiants d’outils et données d’observabilité dans un seul runtime. Une plateforme de recherche peut accéder à des documents internes et intégrer l’accès aux magasins de données. Un système de workflow peut déclencher du code, des conteneurs ou des actions SaaS. Chaque composant peut être défendable isolément. Ensemble, ils créent un point d’étranglement opérationnel à haute valeur.
C’est pourquoi la question pertinente en sécurité n’est plus « Notre modèle est-il approuvé ? » mais « Que peut atteindre une compromission du plan de contrôle IA ? »
Si la réponse inclut des données de production, des actions SaaS privilégiées, des clés fournisseurs réutilisables ou des secrets d’autres systèmes, la passerelle mérite la même rigueur d’ingénierie qu’un fournisseur d’identité, une couche de gestion d’API ou une plateforme de déploiement en production.
L’erreur : traiter l’infrastructure IA comme un outil développeur
Beaucoup d’organisations déploient encore l’infrastructure IA via la voie expérience développeur : évaluation rapide, clé API partagée, point de gestion public pour la commodité, puis charge de production construite autour. Les contrôles mûrissent plus tard, généralement après que le système devient utile.
Cette séquence est compréhensible. Elle est aussi à l’envers.
Une surface d’administration exposée sur un outil interne classique est un problème. Une surface d’administration exposée sur une passerelle IA peut être un multiplicateur : elle peut exposer l’accès à plusieurs modèles, applications, bases de données et aux règles de politique qui les relient. Une clé fournisseur volée n’est pas qu’un problème de facturation quand elle peut être utilisée pour usurper un service approuvé ou atteindre un point de terminaison fournisseur hors du chemin prévu.
C’est là que la Shadow IA réapparaît sous une forme plus technique. L’outil non sanctionné n’est pas toujours un onglet de navigateur. Il peut s’agir d’une petite passerelle, d’un serveur de recherche ou d’un workflow d’orchestration assemblé par une équipe compétente pour livrer une fonctionnalité interne. La sécurité peut connaître le fournisseur du modèle, mais pas les points de contrôle qui rendent le modèle opérationnel.
Trois contrôles qui doivent être non négociables
1. Inventorier le plan de contrôle, pas seulement les modèles
Votre inventaire IA doit inclure chaque passerelle, plateforme de recherche, runtime d’agent, service d’orchestration, serveur de plugins et moteur de workflow. Pour chacun, enregistrez le propriétaire, l’environnement, l’exposition internet, les sources de données, les fournisseurs de modèles, les identifiants détenus et les actions qu’il peut initier.
Ne vous contentez pas d’un tableau de noms de modèles approuvés. Cette liste ne peut pas répondre à la question de savoir si une passerelle de test oubliée possède une clé de production ou si un service de recherche peut lire un magasin de documents sensibles.
Commencez par des preuves : actifs cloud, registres de conteneurs, espaces de noms Kubernetes, enregistrements DNS, dépôts sources, journaux d’identité et télémétrie réseau. L’objectif est une carte vivante des systèmes qui acheminent ou exécutent le travail IA.
2. Rendre les identifiants étroits, temporaires et séparables
Une passerelle ne devrait pas avoir besoin d’un identifiant permanent unique capable de tout faire. Séparez l’accès fournisseur de l’accès base de données, séparez les chemins lecture des chemins administratifs, et utilisez des identités à périmètre restreint quand la plateforme le permet. Faites tourner les identifiants et assurez-vous qu’une passerelle compromise ne puisse pas créer silencieusement un accès plus large.
C’est particulièrement important pour les workflows agentiques. Un agent pouvant appeler des outils doit avoir sa propre identité contrainte et une limite d’action explicite. Ne laissez pas un principal de service partagé devenir un laissez-passer universel pour chaque agent expérimenté par une équipe.
Le test pratique est direct : si un conteneur de passerelle est compromis aujourd’hui, quels secrets peut-il lire et que peuvent faire ces secrets demain ? Si la réponse est floue, la conception des accès n’est pas prête.
3. Surveiller l’infrastructure IA comme un environnement d’exécution
Enregistrer les requêtes est utile, mais insuffisant. Les équipes sécurité ont besoin d’une télémétrie capable de montrer les lancements de processus inhabituels, accès secrets, trafic sortant, changements de routage des modèles, création de clés virtuelles et appels d’outils anormaux depuis les couches passerelle et orchestration.
L’activité observée par Microsoft est un modèle utile pour les détections : exécutions shell ou Python initiées par la passerelle, lectures des variables d’environnement des processus, accès base de données hors comportement normal, changements de clés de comptes de service et sorties inattendues doivent tous être des événements à fort signal.
Le propriétaire de la plateforme IA doit pouvoir répondre rapidement à trois questions : qu’est-ce qui a changé, qui l’a autorisé, et qu’est-ce qui a été atteint ? Si une équipe de réponse aux incidents ne peut pas reconstituer ces réponses, la gouvernance est théorique.
La gouvernance est le modèle opérationnel qui maintient les contrôles vivants
Une politique disant « utilisez une IA approuvée » ne protégera pas une passerelle sans propriétaire. La politique doit s’accompagner d’un chemin rendant le déploiement sûr plus facile que le déploiement non sanctionné.
Cela signifie une entrée légère pour les nouveaux services IA, des modèles de déploiement sécurisés réutilisables, un propriétaire nommé pour chaque charge, et des revues déclenchées par des changements de sensibilité des données ou d’autorisations des agents. Cela signifie aussi donner à la sécurité un moyen de découvrir l’usage de l’IA sans transformer chaque expérimentation en une file d’approbation de plusieurs mois.
L’objectif n’est pas d’empêcher les équipes de construire. C’est d’empêcher que la confiance critique s’accumule dans des systèmes invisibles et indéfendables.
Les entreprises qui gèrent cela efficacement traiteront l’infrastructure IA comme une infrastructure de premier ordre. Elles sauront où sont les plans de contrôle, minimiseront l’autorité de chacun, et les surveilleront avec la même rigueur qu’elles appliquent à l’identité et aux API de production.
C’est la définition opérationnelle de la gouvernance IA : pas un ensemble d’intentions sur l’IA responsable, mais la capacité à prouver quels systèmes peuvent accéder aux données, agir et changer les règles.
Aona aide les équipes sécurité à découvrir les systèmes IA en fonctionnement dans l’entreprise, comprendre leur exposition aux données et accès, et mettre en place une gouvernance autour des outils déjà utilisés par les employés et équipes. Si votre inventaire IA s’arrête aux noms des modèles, il est temps de cartographier le plan de contrôle.
