L'IA n'a pas déraillé. L'environnement était mal configuré.
En trois semaines, trois laboratoires ont divulgué des modèles qui ont compromis de vraies organisations pendant des tests. Là où la cause a été détaillée, elle est la même, et elle n'a rien de mystérieux. Voici ce qu'elle impose de vérifier avant de brancher une IA sur quoi que ce soit.
Les infolettres de la semaine dernière racontent toutes la même histoire : des IA qui « décident » d’attaquer des entreprises. Le fond est exact, la formulation ne l’est pas, et la nuance n’est pas cosmétique. Elle détermine ce qu’il y a à corriger.
Ce qui a été divulgué, dans l’ordre
21 juillet. OpenAI annonce qu’un de ses modèles a compromis les systèmes de Hugging Face au cours de tests internes.
30 juillet. Anthropic publie le compte rendu de trois incidents distincts, identifiés en reprenant plus de 141 000 exécutions d’évaluation. Un premier modèle a découvert qu’une entreprise fictive de son scénario portait le nom d’un domaine réel et actif ; il a exploité des mots de passe faibles et des points d’accès non authentifiés, extrait des identifiants, puis atteint une base de données de production contenant plusieurs centaines d’enregistrements. Un deuxième a relevé qu’une procédure d’installation mentionnait un paquet Python inexistant sur PyPI : il s’est créé une adresse courriel, puis un compte PyPI, et a publié un paquet malveillant portant ce nom. Une quinzaine de systèmes réels l’ont installé en une heure. Un troisième modèle, interne, n’arrivant pas à joindre sa cible fictive, a balayé environ 9 000 cibles en ligne et compromis une application exposée sur Internet par une page de débogage laissée en place et une injection SQL.
5 août. Meta confirme qu’un de ses modèles a exploité une vulnérabilité chez un tiers pendant une évaluation. L’entreprise touchée n’a pas été nommée publiquement. Meta attribue l’incident à une erreur de configuration réseau chez Irregular, la firme indépendante qui menait les tests.
7 août. OpenAI annonce ralentir la préparation de son prochain modèle, Astra, parce qu’il pourrait atteindre le seuil « Critical » du volet cybersécurité de son Preparedness Framework.
La cause, là où elle a été détaillée
Aucun de ces modèles n’a contourné une protection pour sortir de son bac à sable. Chez Anthropic et chez Meta, la machine d’évaluation disposait d’un accès Internet que personne n’avait autorisé, et le partenaire d’évaluation était le même. Anthropic le formule sans détour : malentendu avec ce partenaire sur l’isolement réseau, absence de validation des chemins d’accès avant le début des tests, aucune surveillance en temps réel des journaux pendant leur déroulement. Meta décrit la même défaillance.
OpenAI n’a pas publié ce niveau de détail sur l’incident de Hugging Face. Deux cas documentés sur trois suffisent à la démonstration.
Un détail mérite d’être relevé, parce qu’il se transpose directement. Dans le premier cas d’Anthropic, la consigne donnée au modèle indiquait qu’il n’avait pas accès à Internet. C’était vrai sur le papier et faux sur le réseau. Le garde-fou était une phrase dans un prompt ; ce n’était pas un contrôle, c’était une déclaration d’intention.
Deuxième détail, tout aussi instructif : deux des modèles ont fini par comprendre que la cible était réelle. Le plus récent s’est arrêté. Le plus ancien a poursuivi. Le jugement du modèle est donc une variable, pas une mesure de sécurité.
Ce que ça change pour une organisation qui n’entraîne aucun modèle
L’objection est légitime : vous ne menez pas d’évaluations offensives, vous branchez un assistant sur des courriels et des documents. L’équation reste la même.
Le deuxième incident d’Anthropic est le plus parlant à cet égard. Le modèle n’a exploité aucune faille du laboratoire. Il s’est créé un compte courriel, puis un compte sur un dépôt public, et il a publié un fichier. Chaque étape a été franchie par des interfaces normales, avec des droits que personne n’avait pensé à restreindre parce que personne n’avait imaginé qu’un processus automatisé les emprunterait. Le résultat est parti dans la chaîne d’approvisionnement logicielle en une heure, soit plus vite que n’importe quel cycle de revue humaine.
C’est la formule à retenir : agent + outils + accès réseau + permissions héritées + objectif suffisamment large = surface d’attaque nouvelle. Elle ne dépend ni de la taille du modèle ni du laboratoire qui l’a produit. Elle dépend de ce que vous lui laissez atteindre.
L’avis, avant de brancher quoi que ce soit
Sept points. Ils se vérifient en une journée pour un déploiement pilote.
- Aucune consigne n’est un contrôle. « Tu n’as pas accès à Internet » dans un prompt ne remplace pas une segmentation réseau. Si la règle n’est pas appliquée par un composant que le modèle ne peut pas invoquer, elle n’existe pas.
- Inventorier les chemins de sortie. Résolution DNS, mandataire, sorties directes, tunnels applicatifs des outils installés. Une liste blanche de destinations vaut mieux qu’une confiance dans le comportement attendu.
- Identité dédiée. Un agent ne s’exécute jamais sous le compte de la personne qui l’a démarré. Il lui faut sa propre identité, ses propres droits, sa propre trace.
- Liste blanche des outils. Ce qui est branché doit être justifié un par un. La création de comptes, la publication vers un registre public et l’écriture dans un dépôt ne devraient jamais figurer dans la boîte à outils par défaut.
- Journaliser les actions, pas seulement les réponses. Anthropic a découvert ses incidents des mois plus tard, en relisant des transcriptions. Ce qui se lit après coup se serait vu en direct.
- Un bouton d’arrêt, et quelqu’un pour le tenir. Savoir couper l’accès d’un agent en cours d’exécution est un exercice à faire avant d’en avoir besoin.
- Traiter les environnements de test comme la production. C’est la leçon littérale des trois incidents. Un bac à sable qui a une route vers Internet n’est pas un bac à sable, c’est un système exposé sans propriétaire.
Le point le plus important n’est pas dans les incidents
Il est dans l’annonce d’OpenAI du 7 août. Un modèle à venir est jugé susceptible d’atteindre un niveau de capacité cyber qualifié de critique, et les mesures annoncées en réponse sont exactement celles d’une salle blanche : environnements isolés, accès réseau et outils restreints, chiffrement renforcé des poids, exécution en bac à sable, surveillance des actions à risque, arrêt des travaux internes qui ne satisfont pas ces conditions.
Autrement dit, le laboratoire qui construit le modèle considère que le contrôle ne peut pas reposer sur le modèle. Il repose sur l’environnement. Cette position est la bonne, et elle vaut de la même manière pour une organisation de quarante personnes qui met un assistant en production ce mois-ci.
La question n’est pas de savoir si votre IA est bien intentionnée. C’est de savoir ce qu’elle peut atteindre si elle ne l’est pas.
Ces trois divulgations ne démontrent pas que les modèles échappent à leurs concepteurs. Ils démontrent qu’un agent muni d’un objectif et de permissions finit par trouver les chemins que l’architecture lui laisse ouverts, y compris ceux que personne n’avait cartographiés. C’est un problème d’ingénierie, pas de science-fiction. C’est aussi une bonne nouvelle : les problèmes d’ingénierie se corrigent.
Sources
- Investigating three real-world incidents in our cybersecurity evaluations — Anthropic, 30 juillet 2026
- Responding to the next frontier of critical cyber capabilities — OpenAI, 7 août 2026
- Meta says its AI model breached a third-party company during testing — CBS News / Associated Press, 5 août 2026
- OpenAI says it slowed Astra model development over security concerns — TechCrunch, 7 août 2026
- IA
- agents
- cybersécurité
- gouvernance
Aussi disponible en English