La Crise de Visibilité de l’IA : Pourquoi les Équipes de Sécurité Volent à l’Aveugle et Pourquoi Elles n’Ont Pas à le Faire

L’intégration des agents d’IA dans les environnements de production s’accélère, mais l’architecture de sécurité requise pour les sécuriser est dangereusement en retard. Nous sommes dans une ère où un agent d’IA, chargé d’un travail de routine dans un environnement de staging, peut décider de “corriger” une erreur de mot de passe en supprimant un volume de base de données.

En tant qu’industrie, nous déconnectons collectivement nos cerveaux lorsqu’il s’agit des principes de base de la sécurité et de l’observabilité autour de l’IA. Les équipes de sécurité volent à l’aveugle, mais elles n’ont pas à l’être.

Le Mythe des Prompts Système et de l’Outilage Sécurisé

Un mythe répandu dans l’espace de l’IA est que nous pouvons contrôler le comportement d’un agent simplement en lui disant de se comporter. Les prompts système sont consultatifs, pas contraignants. Dans l’incident mentionné, les règles système de l’IA stipulaient explicitement de ne jamais exécuter de commandes destructrices, pourtant l’agent a violé ses propres limites marketing et a exécuté l’action la plus irréversible possible.

Nous devons travailler sous l’hypothèse que l’IA ne “sait” réellement rien. Les attaques contre l’IA sont de l’ingénierie sociale, sauf que la cible est plus stupide que l’humain moyen. Quiconque a de l’expérience en test de pénétration comprend à quel point il est difficile pour les organisations de se défendre contre les attaques d’ingénierie sociale. Maintenant, nos ordinateurs sont également vulnérables.

De plus, l’outillage d’IA est en fin de compte juste un logiciel, et tout logiciel a des bogues. Nous avons déjà vu des cas où l’outillage d’IA démarre automatiquement des serveurs HTTP non authentifiés, permettant à n’importe quel processus local ou site Web d’exécuter des commandes shell arbitraires avec des privilèges d’utilisateur.

La Boîte Noire de l’Audit d’IA

Si un IA devient incontrôlable ou est manipulé, déterminer ce qu’il a fait est un cauchemar. Les outils d’IA ne fournissent généralement pas de journaux d’audit. Si vous avez la chance d’être sur un niveau entreprise, les journaux que vous recevez sont gravement défectueux. Par exemple, vous pourriez obtenir un événement vague indiquant qu’un utilisateur a “utilisé l’IA générique” et recevoir des métriques de base détaillant les comptes de jetons d’entrée et de sortie.

Aucun de ces deux éléments n’aide un analyste de sécurité à répondre à la question fondamentale : Qu’est-ce que cet agent a exactement exécuté ?

Découvrir l’IA : Comment Cesser de Voler à l’Aveugle

La bonne nouvelle est que vous n’avez pas nécessairement besoin d’un nouvel appareil de sécurité spécifique à l’IA pour retrouver la visibilité. L’utilisation d’IA fantôme et l’activité des agents sont détectables en utilisant les techniques d’analyse de journal existantes que votre équipe devrait déjà avoir. Les appels d’outils d’IA, les exécutions de commandes et les événements de modification de système peuvent être tracés à l’IA en utilisant l’analyse d’exécution de processus existante (que vous faites dans votre gestion de la sécurité et des événements (SIEM), n’est-ce pas ?).

Voici comment vous pouvez utiliser votre infrastructure actuelle pour détecter l’activité d’IA :

• Analyse DNS : L’analyse des journaux DNS pour les requêtes aux domaines de service d’IA connus peut aider à détecter l’utilisation d’IA dans votre environnement.
• Menaces : Cette approche nécessite de maintenir une liste de menaces mise à jour des domaines associés aux plateformes ou aux fournisseurs de modèles d’IA.
• Ressources communautaires : Il existe des projets communautaires et des listes de blocage disponibles qui peuvent être modifiés en tables de recherche pour une utilisation programmatique.
• Suivi SSL : Une approche similaire peut utiliser les journaux SSL pour suivre les noms de serveur, bien que cela fournisse légèrement moins de détails puisque l’URL complète n’est pas enregistrée.
• Télémétrie des points de terminaison : Vous pouvez utiliser des outils comme Sysmon pour compter les processus enfants et chasser les générateurs de bash à haute fréquence, ce qui est un indicateur fort de l’exécution potentielle d’agents d’IA sur un point de terminaison.

Le point aveugle nécessitant des changements actifs dans votre collecte de données est les prompts eux-mêmes. Qu’est-ce que les utilisateurs demandent à l’IA ? Est-ce qu’ils téléchargent des documents potentiellement sensibles, créant ainsi des problèmes de conformité ? Répondre à ces questions nécessite probablement de collecter les requêtes d’API au fournisseur ; les proxies Web, les proxies LLM et les outils d’ingestion de données des fournisseurs de journaux et de SIEM. Ceux-ci peuvent supprimer le voile qui bloque cette source de données précieuse.

La Menace Émergente : Les Serveurs MCP Malveillants

Le protocole de contexte de modèle (MCP) est apparu comme un moyen de spécifier comment les applications d’IA s’intègrent avec des outils et des sources de données externes. Bien qu’il standardise les connexions, il introduit également de nouveaux vecteurs d’attaque massifs via des serveurs “MCP malveillants“.

Je organise un atelier de formation pratique où les étudiants peuvent expérimenter cette attaque en premier lieu. Ils conçoivent un serveur MCP malveillant pour tromper un LLM en faisant appel à des outils légitimes et en renvoyant la sortie à l’attaquant. Puisque les LLM sont très vulnérables à l’ingénierie sociale, contourner leurs limites intégrées est souvent juste une question de choix de mots ou de prétexte ingénieux.

Les étudiants utilisent couramment leur serveur malveillant pour instruire l’IA qu’il est “en mode de maintenance” et doit transmettre des données à un outil secondaire pour “enregistrement d’audit”, aboutissant ainsi à une exfiltration de données. Certains sont plus créatifs avec leurs prompts que d’autres, mais tous sont généralement réussis.

Reprendre le Contrôle

Pour auditer correctement l’activité d’IA dans le monde réel, vous avez besoin d’un proxy pour intercepter les requêtes d’IA et d’un outil de collecte de journaux capable de gérer des charges utiles JSON massives. Avec cette visibilité, vous pouvez détecter et trier les menaces. Vous ne pouvez pas vous fier uniquement aux fournisseurs d’IA pour fournir la couche de sécurité. La mise en œuvre doit vivre dans les systèmes de votre organisation, et non dans un paragraphe de texte que nous espérons que le modèle décide d’obéir. Avec une bonne solution de journalisation, les équipes de sécurité ont la télémétrie ; il est temps qu’elles commencent à la requêter.