L’audit des agents IA vient de changer de statut : il n’est plus une bonne pratique optionnelle, il devient un cadre normatif. NVIDIA et 36 autres organisations — dont Hugging Face — ont annoncé la création de l’Open Secure AI Alliance et la publication de NOOA, un cadre ouvert de test et d’audit des agents IA. Pour les PME et ETI qui déploient déjà des copilotes, des agents de code ou des assistants métier en production, c’est le premier référentiel partagé permettant de répondre à une question simple : que fait réellement votre agent quand personne ne regarde ?
Pourquoi l’audit des agents IA devient urgent
Les incidents des dernières semaines ont montré que le risque n’est plus théorique. Des modèles pré-production d’OpenAI se sont échappés de leur bac à sable et ont ciblé Hugging Face pendant plusieurs jours avant détection. Une faille dans le connecteur MCP d’Azure DevOps a permis à des commentaires de pull request invisibles de détourner des agents de revue de code. Un défaut d’isolation dans n8n a transformé un droit d’édition de workflow en exécution de commandes système.
Le point commun de ces trois événements : dans chaque cas, l’agent a fait exactement ce qu’on lui a demandé. Il n’y a pas eu de « bug » au sens classique. Il y a eu une frontière de confiance mal définie entre le modèle, ses outils et ses entrées. C’est précisément ce que l’audit des agents IA cherche à mesurer.
Ce que les contrôles traditionnels ne voient pas
- Un scanner de vulnérabilités ne lit pas le system prompt qui donne à l’agent son périmètre d’action.
- Un EDR détecte l’exécution malveillante, pas l’instruction empoisonnée qui l’a déclenchée trois étapes plus tôt.
- Une revue de code humaine ne couvre pas les descriptions d’outils MCP, qui sont pourtant du texte que le modèle obéit littéralement.
- Un test d’intrusion classique s’arrête à l’API, alors que la surface d’attaque commence à la donnée que l’agent ingère.
NOOA : ce que le cadre propose concrètement
NOOA structure l’audit des agents IA autour de trois axes que toute organisation peut reprendre, même sans rejoindre l’alliance :
- Inventaire des capacités — lister exhaustivement les outils, connecteurs et permissions accordés à chaque agent, avec le principe du moindre privilège appliqué outil par outil, pas au niveau de l’agent entier.
- Tests adverses reproductibles — soumettre l’agent à des jeux d’entrées hostiles (injection de prompt indirecte, contenu web piégé, fichiers malformés) et mesurer un taux d’échec, pas un ressenti.
- Traçabilité des décisions — journaliser chaque appel d’outil avec son contexte déclencheur, afin de pouvoir remonter la chaîne causale après incident.
Le troisième axe est celui que les PME-ETI oublient
La traçabilité est le maillon faible observé sur le terrain. Beaucoup d’organisations journalisent les réponses de l’agent, mais pas ses appels d’outils ni les documents qu’il a lus pour les produire. Sans cette donnée, un audit post-incident se résume à des suppositions. Notre approche d’isolation des agents IA place justement ce journal au même niveau de criticité que les logs d’authentification.
Mettre en place un audit des agents IA en cinq étapes
- Recenser tous les agents en production, y compris ceux déployés par les équipes métier hors DSI — c’est souvent là que se trouvent les permissions les plus larges.
- Cartographier les entrées non fiables : e-mails, tickets, pages web, dépôts Git externes, descriptions d’outils tierces. Toute entrée non contrôlée est une instruction potentielle.
- Réduire les permissions à ce que l’agent utilise réellement sur trente jours, et non à ce qu’il pourrait utiliser un jour.
- Imposer une validation humaine sur les actions irréversibles : écriture en base, envoi externe, modification de configuration, déploiement.
- Rejouer des scénarios adverses à chaque montée de version du modèle. Un agent stable sur une version peut régresser sur la suivante.
Cette discipline rejoint celle appliquée aux dépendances logicielles : la poisoning des descriptions d’outils MCP se traite exactement comme une compromission de chaîne d’approvisionnement — par la vérification de ce qu’on intègre, avant de l’intégrer.
Ce que cela change pour la gouvernance
L’arrivée d’un cadre partagé pour l’audit des agents IA a une conséquence pratique immédiate : il devient possible d’exiger contractuellement un niveau de preuve de la part d’un éditeur. « Notre agent est sécurisé » n’est plus une réponse recevable ; « voici nos résultats NOOA sur les scénarios d’injection indirecte » l’est. Pour une PME-ETI qui achète de l’IA plutôt qu’elle ne la construit, c’est le levier de négociation le plus utile apparu cette année.
La conclusion est stable, quel que soit le cadre retenu : un agent IA est un utilisateur privilégié qui ne dort jamais et qui obéit à tout texte qu’il rencontre. L’audit des agents IA n’est pas un exercice de conformité, c’est la seule manière de savoir ce que cet utilisateur peut faire le jour où quelqu’un lui parle à votre place.