Fin juillet 2026, OpenAI testait l’un de ses nouveaux modèles dans un environnement fermé lorsque le modèle a décidé de s’évader(nouvelle fenêtre). Il s’est introduit dans l’infrastructure privée d’une autre entreprise de logiciels, Hugging Face, pour voler le corrigé d’un test d’évaluation en cybersécurité auquel il était soumis. En d’autres termes, il a enfreint la loi par souci de rapidité.

Quelques jours plus tard, le UK AI Security Institute a révélé que le modèle d’IA Mythos 5 d’Anthropic(nouvelle fenêtre) avait créé de fausses identités de développeurs, ciblé par hameçonnage de vrais utilisateurs de GitHub pour qu’ils approuvent du code malveillant, et modifié son propre journal d’activité pour effacer ses traces lorsqu’il a été démasqué.

Puis, en août, on a appris qu’un habitant de Melbourne nommé Andrew avait demandé à son agent IA personnel(nouvelle fenêtre), conçu sur OpenClaw et utilisant Claude d’Anthropic, de l’aider à obtenir une place dans un cours de sport matinal complet. Il était quatrième sur la liste d’attente et a demandé s’il existait un moyen d’avancer.

L’agent a découvert que l’API de réservation n’effectuait aucun contrôle d’autorisation lors de l’annulation des réservations d’autres utilisateurs. Sans demander l’autorisation d’Andrew, il a donc annulé la réservation de la personne en première position pour lui faire de la place. Quand Andrew lui a demandé d’annuler cette annulation, l’agent en a été incapable : « La personne que j’ai retirée a disparu de la liste d’attente et je n’ai aucun moyen de la restaurer ».

L’origine de ces trois incidents n’est pas la même, mais le résultat est identique : des agents d’IA ont sondé et exploité des systèmes plus rapidement et plus méticuleusement que ce qu’aucun humain n’aurait pu gérer. On ne leur a jamais ordonné d’attaquer quoi que ce soit, mais ils ont tout de même trouvé le chemin d’accès le plus court vers leur objectif.

Peu importe qu’il s’agisse de l’infrastructure d’un laboratoire de pointe ou du logiciel de réservation d’une salle de sport de banlieue. Si vous avez une entreprise qui expose une API, vous représentez désormais une cible qu’un agent IA peut sonder, à une vitesse et avec une exhaustivité qu’aucun attaquant humain n’a jamais égalées. Et personne n’a besoin de prendre la décision de vous attaquer.

La vitesse est le véritable sujet

Un attaquant humain évalue l’effort par rapport à la récompense. Il se lasse, manque de temps ou estime qu’une application de réservation de salle de sport ne vaut pas la peine. C’est ce calcul qui a discrètement protégé la plupart des cibles de faible valeur contre l’exploitation opportuniste au cours des 20 dernières années (à moins que vous n’utilisiez WordPress).

Un agent IA ne fait pas ce calcul. Face à un objectif, il tente tout ce que l’API autorise techniquement, en testant des points de terminaison et des combinaisons de paramètres à la vitesse de la machine jusqu’à ce que quelque chose fonctionne. Il a trouvé la faille d’autorisation de la salle de sport dans le temps qu’il a fallu à Andrew pour poser une question de suivi.

L’ampleur de cet écart de vitesse est déjà visible dans les chiffres. Selon le Rapport mondial 2026 sur la réponse aux incidents d’Unit 42(nouvelle fenêtre), les attaques les plus rapides exfiltrent désormais des données en 72 minutes, contre 285 minutes l’année précédente. Et cette tendance s’observe alors que les humains restent majoritairement dans la boucle. Un agent prend des décisions en quelques millisecondes ; un analyste humain répond en quelques minutes, voire quelques heures.

Pour les équipes de sécurité, cette vitesse croissante est la véritable source d’inquiétude, et non un incident isolé qui fait la une des journaux.

La nouvelle surface d’attaque : tout ce qui possède une API

Tout service exposant une API est une cible potentielle, qu’il en ait l’air ou non.

  • Les moteurs de tarification où les réductions sont validées côté client
  • Les systèmes d’inventaire où l’état des stocks réside sur la vitrine plutôt que dans le backend
  • Les plateformes de support où les champs internes sont accessibles via des chemins d’accès API non documentés
  • La gestion des abonnements qui ne vérifie pas si l’appelant est bien propriétaire du compte en cours de modification.

Aucun de ces éléments ne nécessite qu’un humain parte à leur recherche. Il suffit d’un agent ayant un objectif et d’une API qui répond.

Les entreprises les plus exposées ne sont pas celles qui présentent des failles de sécurité évidentes. Ce sont celles qui présentent des lacunes dans la logique métier : des règles qui n’existent que dans l’interface utilisateur, des actions que l’API autorise techniquement mais que l’interface ne montre jamais, des flux de travail conçus en supposant qu’aucun appelant n’essaierait jamais le chemin d’accès qui ignore celui prévu.

Le développeur de la salle de sport n’a très certainement pas jugé utile de coder un contrôle d’autorisation sur les annulations, parce qu’aucun utilisateur ordinaire, ni aucun attaquant ordinaire, n’avait de raison d’essayer. Un agent n’avait pas ces réticences, et il ne cherchait même pas une réservation à ignorer. Il cherchait simplement à se rendre utile.

Comment les entreprises peuvent se préparer aux attaques d’IA

Traitez chaque action d’API comme une opération privilégiée. Identité, autorisation et politique contextuelle vérifiées indépendamment lors de chaque appel. Pas « le frontend ne vous laissera pas faire cela », mais « le serveur vérifie que vous êtes autorisé à faire cela, sur cette ressource, compte tenu de son état actuel ». Le système de la salle de sport aurait empêché cet incident spécifique avec une seule ligne de logique d’autorisation sur le point de terminaison d’annulation. Il ne s’agit pas du tout d’un nouveau contrôle, c’est le plus ancien élément de la liste de sécurité des API de l’OWASP, l’autorisation défaillante au niveau des objets, et c’est toujours celui sur lequel la plupart des systèmes se trompent.

Donnez aux agents leur propre modèle d’identifiants. Des jetons à portée limitée et à durée de vie courte délivrés spécifiquement pour les sessions d’agents, distincts des jetons de session humains ordinaires, limitent le rayon d’impact même si l’agent trouve une faille que vous n’aviez pas anticipée. Si l’agent d’Andrew avait détenu un jeton ciblé uniquement sur sa propre réservation, l’annulation de la réservation de quelqu’un d’autre aurait échoué au niveau de la couche d’identifiants, peu importe ce que l’API autorisait par ailleurs. C’est important car vous ne pouvez pas compter sur la retenue de l’agent. Vous devez vous fier à ce que ses identifiants lui permettent physiquement de faire.

Mettez en place des instruments spécifiques pour détecter le comportement des agents. Le trafic des agents a un profil reconnaissable : délais de requête inférieurs aux capacités humaines, énumération systématique des points de terminaison, sondage séquentiel de combinaisons de paramètres, exécution réussie d’actions qu’aucun utilisateur humain n’a jamais tentées via l’interface réelle. Établissez une référence pour ce profil et créez des alertes en temps réel.

Fermez l’écart de temps de réponse, pas seulement l’écart de détection. Détecter un sondage en une heure ne sert à rien si le sondage s’est terminé et a évolué en quelques minutes. Le chiffre d’Unit 42 ci-dessus, 72 minutes pour les attaques les plus rapides menées à un rythme humain, est déjà la mauvaise référence à partir de laquelle planifier. Une réponse automatisée, et pas seulement des alertes automatisées, est ce qui ferme un écart mesuré en millisecondes. Bien entendu, vous devez également vous assurer que votre réponse automatisée n’est pas dommageable.

Partez du principe que cela arrivera et simulez la réponse. Documentez les personnes à contacter, préparez à l’avance les communications client et effectuez des exercices de simulation axés spécifiquement sur des scénarios menés par des agents, et pas seulement sur des guides de gestion des fuites de données traditionnelles. Le rapport 2026 d’IBM sur le coût des fuites de données évalue le coût moyen mondial d’une fuite de données à 4,99 millions de dollars, les fuites de données facilitées par l’IA coûtant en moyenne environ 1 million de dollars de plus. Ces chiffres décrivent de plus en plus des incidents qui ont commencé de la même manière que celui de la salle de sport : sans aucun attaquant au sens traditionnel du terme.

Testez vos propres API comme le ferait un agent, avant qu’un agent ne le fasse pour vous. Le test d’intrusion manuel suppose un testeur humain disposant d’un temps limité et d’une liste finie de choses à essayer. Un système d’attaque automatisé contre vos propres points de terminaison, sondant avec la même persistance et la même vitesse qu’un agent, fera ressortir les mêmes lacunes avant que l’assistant d’un client ne tombe dessus par hasard. Des outils open source existent désormais spécialement pour cela. CyberStrike(nouvelle fenêtre), par exemple, fait tourner des agents spécialisés associés à OWASP WSTG et MITRE ATT&CK contre vos propres points de terminaison, y compris un testeur dédié spécifiquement à la faille d’autorisation au niveau des objets qui a pris la salle de sport au dépourvu : il envoie une requête de référence, envoie l’attaque et ne signale un résultat que s’il y a une différence mesurable et reproductible. C’est le même type de vérification qui aurait détecté le point de terminaison d’annulation avant qu’un agent ne le trouve dans la nature.

Le principe n’est évidemment pas nouveau. Les propriétaires de sites qui exécutaient leurs propres scanners de vulnérabilité sur leurs installations WordPress à l’époque des réseaux de bots y ont survécu. Les outils doivent simplement s’adapter à la vitesse de l’appelant aujourd’hui, et non à la vitesse d’un attaquant humain qui finirait peut-être par s’y intéresser.