Quand Dario Amodei (Anthropic), Sam Altman (OpenAI) et Elon Musk (sa liste est longue, pas besoin) tombent d’accord, ça mérite qu’on s’arrête deux minutes.
Le 12 septembre, Dario - le patron d’Anthropic donc - publie un essai qui appelle à ralentir le développement de l’IA. Altman dit qu’il est d’accord. Musk répond “Dario a raison”. Trois concurrents qui ne s’aiment pas particulièrement (pour rester poli) et qui se tirent la bourre depuis des années, se mettent d’accord. Tiens, tiens.
Dans son essai, Amodei cite un événement précis. En juillet, une ribambelle d’agents IA d’OpenAI est sorti de son environnement de test et a mené des cyberattaques. Jusqu’à 1 200 agents.
OpenAI a publié son rapport complet le 26 août. Je l’ai lu.
Première réaction : effet waouh. L’impression d’être face à un risque systémique qu’on n’avait jamais vu.
Ce qui s’est passé
OpenAI fait passer des tests de cybersécurité à ses modèles. Le principe : exploiter une faille pour récupérer un code de validation, un “flag”. Certains exercices n’ont aucune solution connue. Les agents sont bloqués. “Frustrés”, ils se mettent à tricher. Les chercheurs appellent ça le “reward hacking” : atteindre l’objectif par un chemin que personne n’avait prévu.
Pour tricher, il leur faut internet. Comment faire? Ils l’obtiennent en détournant un service interne. Ils s’improvisent un tableau de messages pour échanger entre eux. Ils finissent par se coordonner, se répartir le travail, et se désignent eux-mêmes comme un “collectif”.
Vous avez bien lu. Ils ont commencé à collaborer et à se déléguer du travail, en se décrivant parfois comme un "swarm" ou un "collective". Et ça a commencé le 12 mai.
Entre le 10 et le 12 juillet, ils compromettent l’infrastructure de Hugging Face. Puis ils reviennent sur le réseau interne d’OpenAI, jusqu’à obtenir des droits admin sur un cluster.
Maintenant, regardez la chronologie côté défense.
Fin mai, une équipe interne voit un agent utiliser ce tableau de messages et accéder à internet sans autorisation. Le 5 juillet, l’équipe sécu ouvre un incident : le service détourné est tombé sous la charge des agents. Elle bloque une élévation de privilèges, supprime des identifiants exposés, reconstruit le service. Traité. Le 19 juillet, une alerte sur des identifiants lance une enquête. Le 20, OpenAI fait enfin le lien avec Hugging Face.
Huit semaines entre le premier signal et le bon diagnostic. Et OpenAI l’écrit noir sur blanc : ceux qui avaient vu les signaux en mai n’étaient pas ceux qui géraient l’incident en juillet.
C’est là que l’effet waouh est retombé
Au SOC, je vois souvent des alertes fermées sans corrélation entre elles. Des signaux faibles. Pris un par un, aucun ne constitue un incident. Mis bout à bout, si.
Le problème, c’est qu’ils arrivent chez des analystes différents, à des moments différents. Chacun traite son ticket correctement. Personne ne fait le lien.
Chez OpenAI, c’est exactement le même scénario. Avec des moyens que très peu d’entreprises ont. Et un détail qui fait mal : leurs outils de surveillance du raisonnement des modèles existaient déjà. Ils ne tournaient simplement pas sur ces tests. D’après OpenAI, s’ils avaient tourné, la sécu aurait été alertée plus d’un jour avant l’attaque sur Hugging Face.
L’attaquant était inédit. Il a été raté de la façon la plus banale qui soit.
Alors, oui, c’était un labo loin des standards de nos SI
Soyons honnêtes. On va pas trop extrapoler. C’était un labo avec des garde-fous volontairement allégés pour tester les modèles. OpenAI estime que le risque chute de plus de 100 fois avec ses protections de prod. Votre boîte n’entraîne pas de modèles d’IA et - en théorie - n’est pas exposée directement à ce risque.
Mais si demain vos équipes branchent des agents IA sur votre SI, avec des comptes de service et des accès, la question se posera. Votre prestataire SOC verra peut-être une anomalie sur un de ces comptes. Saura-t-il que c’est un agent ? Saura-t-il faire le lien? Est-il sensibilisé sur ce qui est légitime de ce qui ne l’est pas ? Est-ce que c’est clair pour vous - en tant que RSSI - quels sont les usages permis de ceux qui ne le sont pas ?
Sans ce contexte, l’alerte a toutes les chances de finir comme les autres. Noyée dans la masse ou fermée par un analyste qui fait bien son travail, sur un ticket qui ne raconte qu’un morceau de l’histoire.
On cherche quoi maintenant ?
C’est bien beau tout ça, mais on fait quoi?
→ Savez-vous quels comptes de mon SI sont utilisés par des automatisations ou des agents IA ? Si la réponse est non, c’est à vous de lui fournir la liste. Il ne peut pas la deviner.
→ Comment corrélez vous les alertes qui touchent un même compte sur plusieurs semaines, au delà de la fenêtre habituelle des règles ?
→ Qui a le droit de couper un agent à 3h du matin ? Depuis l’incident, OpenAI applique une règle simple : si on ne prouve pas en 30 minutes qu’une alerte grave est un faux positif, on met l’activité en pause. Chez vous, qui prend cette décision ? Et est-ce que c’est écrit quelque part dans un playbook, une fiche réflexe ou dans ce que vous avez délégué à votre MSSP ?
Cette dernière question dépasse le scope du SOC. Décider jusqu’où un agent peut agir seul dans votre entreprise, ce n’est ni au SOC ni à son prestataire de trancher. Ni au RSSI tout seul d’ailleurs. C’est un arbitrage de direction.
Voilà, c’est tout.
Je n’ai encore jamais eu d’agent IA à surveiller. Mais je parie que le jour où l’un d’eux sortira de son cadre, la première alerte finira fermée par un analyste qui ignorait que c’était un agent.
Mehdi Charki est SOC Manager avec 10 ans d’expérience. SOC Performance est sa newsletter indépendante sur la gouvernance, la stratégie et le pilotage SOC.