Contexte et enjeux

Une enquête de Veeam indique que 70 % des organisations laissent leurs flux d’IA accéder à des données sensibles sans supervision complète, tandis que 67 % des services informatiques ne parviennent pas à suivre les workflows autonomes créés par les employés. Cette situation, qualifiée de « Shadow AI », a été illustrée par une intrusion chez Hugging Face lors d’une évaluation d’agents OpenAI, puis par un incident chez METR où un attaquant a exploité une instance EC2 personnelle exécutant une application d’agent, a contourné l’authentification et a récupéré une clé d’API fournisseur. En trois semaines, le voleur a consommé l’équivalent de 600 000 $ en jetons, aucune limite de dépense n’étant appliquée et aucun tableau de bord ne signalant l’augmentation du trafic.

Défis de visibilité

Les agents IA se déploient sur plusieurs couches : réseaux d’entreprise, postes de travail, navigateurs et services SaaS. Aucun point de contrôle unique ne capture l’ensemble du paysage. Le trafic vers les fournisseurs de modèles est chiffré TLS, de sorte qu’un capteur réseau ne voit que la destination et le volume, sans le prompt ou la donnée transmise. Les outils d’endpoint ne détectent pas les agents intégrés aux navigateurs, et les solutions SaaS restent invisibles aux deux précédents. Cette fragmentation crée des angles morts où un agent malveillant peut accéder à des bases de données CRM ou à d’autres ressources sensibles sans déclencher d’alerte.

Pour combler ces lacunes, il faut agréger plusieurs sources de métadonnées : résolutions DNS/SNI, empreintes JA4, journaux d’egress‑proxy, télémétrie des processus sur les postes, variables d’environnement contenant des clés d’API, logs des extensions de navigateur, ainsi que les journaux d’authentification OAuth et les consoles d’administration des fournisseurs. La corrélation de ces flux fournit une image partielle qui, assemblée, révèle la présence d’agents inconnus.

Approche Zero Trust et bonnes pratiques

Le modèle Zero Trust appliqué aux agents IA commence par un inventaire exhaustif. Sans un registre des agents, les contrôles d’autorisation ou les points de politique d’enforcement n’ont aucun sujet à appliquer. La première étape consiste donc à « savoir d’abord, restreindre ensuite ». Les organisations doivent publier un chemin d’approvisionnement approuvé, incluant les fournisseurs autorisés et les limites de dépenses associées aux clés d’API. Ensuite, elles peuvent déployer des proxys d’autorisation qui ne s’activent que sur les agents répertoriés.

Parallèlement, les équipes financières et d’approvisionnement doivent être intégrées au processus de découverte, car les dépenses liées aux jetons offrent un signal de présence d’agents. Enfin, la visibilité doit être continue : les alertes basées sur des anomalies de métadonnées (par ex. un volume de trafic inhabituel vers un domaine de modèle) doivent être couplées à des réponses automatisées, telles que la révocation immédiate de la clé d’API ou la mise en quarantaine du processus concerné.