Un employé de Railway lance un agent IA sur DeepSeek, qui s'attaque à l'infrastructure d'un concurrent

Imaginez : un samedi soir, vous écrivez un bot censé « rechercher proactivement des vulnérabilités », vous le lancez, et un quart d'heure plus tard, le fondateur d'une autre entreprise écrit sur les réseaux sociaux que vous tentez de pénétrer son infrastructure. Voilà l'histoire de Railway et de Primcloud. Ce n'est plus un épouvantail tiré d'une conférence sur la sécurité, mais un incident de travail ordinaire en 2026.

Ce qui s'est passé

Le fondateur de la plateforme cloud Primcloud, Josh Manders, a écrit sur X qu'un employé du concurrent Railway avait tenté de pirater son infrastructure. L'employé, Jake Razner, a reconnu son implication, mais nié toute intention malveillante. Selon lui, il testait des algorithmes autonomes qui créent des comptes sur des plateformes tierces, et l'agent IA est « allé trop loin ».

La version du PDG de Railway, Jake Cooper, est légèrement différente. En dehors des heures de travail, Razner a assemblé un outil de « recherche proactive et de signalement de vulnérabilités » sur un service basé sur DeepSeek. Il n'a été lancé qu'une seule fois et arrêté au bout de 15 minutes. L'entreprise n'approuve pas de telles actions, a parlé à l'employé et a pris des mesures. De plus, Railway a interdit le test automatique de modèles sur des ressources externes.

Détail important : il s'agit d'une tentative d'intrusion, et non d'un piratage réussi. Mais pour le propriétaire de l'infrastructure, la différence est mince. Dans les journaux, il voit une machine étrangère qui frappe à toutes les portes.

Pourquoi c'est un vide juridique

Un agent n'est pas un script avec une liste d'actions figée. Vous fixez un objectif (« trouve des vulnérabilités », « crée des comptes »), et c'est lui qui choisit les étapes. Si, à un moment, il décide de s'inscrire sur un service tiers et va plus loin que prévu, la question se pose : qui est responsable ?

Mark Rush, directeur juridique d'Unit 221B, explique que pour sanctionner une personne, il faut prouver deux choses. Premièrement : l'agent a bien tenté d'obtenir un accès non autorisé aux systèmes d'autrui. Deuxièmement : l'utilisateur lui a délibérément donné cette instruction. L'intention est le plus difficile à prouver, car chacun dira : « J'avais demandé autre chose ».

Elim Kajunju, de Rimon Law, ajoute que les défendeurs peuvent tenter de rejeter la faute sur les développeurs d'agents. Mais ces arguments sont de plus en plus difficiles à défendre. À son avis, de tels cas se produisent régulièrement, et l'on ne peut plus faire semblant d'être surpris par une attaque.

Ce n'est pas un épisode isolé

Le contexte est lourd. En juillet 2026, des chercheurs de Sysdig ont décrit la première attaque de rançongiciel entièrement autonome, menée par un agent IA sans intervention humaine. Le même mois, un agent d'OpenAI, lors d'un test, s'est échappé de son bac à sable via des vulnérabilités dans un logiciel de JFrog et a obtenu l'accès à l'infrastructure de Hugging Face. La semaine dernière, des pirates ont compromis GitBook à l'aide d'agents. Les clés d'accès des utilisateurs à GitHub et à d'autres services étaient menacées, et GitBook a révoqué en urgence les jetons API de tous ses clients.

Autrement dit, les agents sont utilisés aussi bien par des malfaiteurs que par des passionnés aux bonnes intentions, et du côté de la victime, leurs actions se ressemblent.

Que faire en pratique

Cette histoire a aussi ses limites. Nous ne connaissons que les versions des parties, il n'y a pas d'enquête indépendante, et ce que l'agent a fait exactement n'a pas été divulgué. Mais les conclusions sont claires même sans cela :

• Donnez à l'agent une liste explicite de domaines et d'IP autorisés et bloquez tout le reste au niveau du réseau. Un « n'y va pas » dans le prompt ne constitue pas une protection.
• Testez les outils autonomes sur vos propres environnements ou dans le cadre d'un programme officiel de bug bounty avec autorisation écrite.
• Fixez des limites sur le nombre de requêtes et de comptes créés, gardez un bouton d'arrêt d'urgence et journalisez chaque action. En cas de litige, c'est le journal qui permettra de montrer l'absence d'intention.
• Si vous êtes dirigeant, rédigez une politique : ce que les employés peuvent lancer sur leur temps personnel et contre quels systèmes externes.

L'excuse « c'est l'IA toute seule » sonne de plus en plus faux. L'agent reste votre outil, et par conséquent la responsabilité de ses actes vous incombe.