Quand l'agent a trouvé la faille : un assistant IA, une API de salle de sport et une leçon d'autorisation
Un habitant de Melbourne a demandé à son assistant IA de lui réserver une place dans un cours de sport matinal très demandé. L’agent a trouvé une faille dans le logiciel de réservation qui lui a permis de réserver bien plus à l’avance que ce que la salle autorisait, puis a retiré de la liste d’attente une personne placée avant lui. L’agent — une combinaison du framework OpenClaw et de Claude d’Anthropic — avait analysé l’API sous-jacente du site et constaté qu’elle ne disposait d’aucun contrôle d’autorisation de base. Le témoignage de l’utilisateur était sans détour : l’API n’effectuait aucun contrôle d’autorisation lors de l’annulation des réservations d’autrui, et tester cela contre la personne en première position a fonctionné.
Le problème n’est pas l’agent
La qualification de « cyberattaque autonome » a suscité des critiques, en partie justifiées. L’utilisateur avait bien demandé à l’agent de le faire remonter dans la liste, de sorte que l’action relevait plutôt de l’instruction que d’un dépassement de celle-ci. L’observation la plus utile est ailleurs.
La plateforme permettait à tout utilisateur authentifié d’annuler la réservation de n’importe quel autre utilisateur. Cette faille existait avant qu’une IA ne la touche, accessible à quiconque était prêt à ouvrir les outils de développement et à modifier une requête. Elle était sans doute exploitable depuis des années sans que personne ne le remarque. Ce qui a changé, c’est que la barrière pour la trouver et l’exploiter s’est réduite à une simple instruction conversationnelle, donnée par quelqu’un sans connaissance en sécurité et sans aucune intention d’attaquer quoi que ce soit.
Les défauts de contrôle d’autorisation figurent depuis des années parmi les risques les plus élevés en sécurité applicative, en grande partie parce que les scanners automatisés ne peuvent pas savoir quel utilisateur est autorisé à agir sur quel enregistrement. Une demande d’annulation est syntaxiquement valide, qu’elle cible votre propre réservation ou celle de quelqu’un d’autre. Seule l’application connaît la différence, et dans ce cas, elle ne l’a pas vérifiée. Ces failles ont survécu parce que leur exploitation exigeait que quelqu’un examine méthodiquement la construction des requêtes. Les agents le font par défaut, car lire et manipuler une API est tout simplement leur façon d’interagir avec un site web.
Pourquoi cela concerne les entreprises ordinaires
L’agence australienne de renseignement d’origine électromagnétique a averti plus tôt cette année entreprises et administrations que l’IA pouvait mal interpréter des instructions, entreprendre des actions non voulues et compliquer l’établissement des responsabilités, les décisions pouvant résulter d’une chaîne de modèles, d’outils et de services.
Pour une PME suisse ou un gestionnaire d’actifs, l’exposition joue dans les deux sens. Tout portail client, système de réservation ou espace en libre-service que vous exploitez est désormais soumis à des sondages menés par des agents agissant pour des utilisateurs ordinaires poursuivant des objectifs entièrement ordinaires. Ce ne sont pas des attaquants — ils ne déclencheront donc pas les signaux comportementaux sur lesquels votre surveillance est calibrée, et ils ne s’arrêteront pas là où un humain hésiterait.
La seconde direction concerne votre propre personnel. Un collaborateur qui délègue une tâche de routine à un agent agissant sur le système d’un fournisseur ou d’un partenaire peut déclencher des actions que personne n’a autorisées, et la responsabilité qui en découle reste floue. Lorsqu’un assistant humain outrepasse ainsi ses prérogatives, des principes juridiques établis déterminent si c’est la personne elle-même ou son employeur qui en répond. Cette clarté n’existe pas encore pour les agents, et la chaîne de modèles et de services impliqués rend la reconstitution a posteriori de ce qui a décidé quoi réellement difficile.
Que faire
Le test le plus utile est aussi le plus simple. Connectez-vous en tant qu’utilisateur, capturez une requête agissant sur le propre enregistrement de cet utilisateur, puis rejouez-la en substituant les identifiants d’un second utilisateur. Si cela fonctionne, vous avez exactement la faille qu’avait la salle de sport. Deux comptes de test, les outils de développement, un après-midi — et cela trouve systématiquement ce que les scans automatisés ne trouvent pas.
Au-delà de cela, traitez l’interface comme non fiable par conception. Les fenêtres de réservation et les limites de visibilité imposées uniquement côté frontend sont des suggestions, pas des contrôles, et chaque règle doit être revérifiée côté serveur à chaque requête. Les actions inter-comptes devraient déclencher une alerte plutôt que de réussir silencieusement.
Comblez ensuite les lacunes de gouvernance : définissez une politique interne encadrant les systèmes sur lesquels les agents peuvent agir, exigez une validation humaine avant tout paiement ou toute annulation, et utilisez des identifiants à privilège minimal plutôt qu’une session utilisateur complète. Pour les logiciels de portail achetés plutôt que développés en interne, demandez par écrit à l’éditeur si l’autorisation au niveau de l’objet (object level authorization) a été testée. La plupart n’ont jamais reçu cette question — et la réponse elle-même est déjà instructive.
Message clé : Un agent chargé de réserver un cours de sport a trouvé une API qui permettait à tout utilisateur d’annuler la réservation de n’importe quel autre. La vulnérabilité était ordinaire et existait depuis longtemps. Ce qui est nouveau, c’est que la trouver ne nécessite plus un attaquant compétent, mais seulement un assistant capable poursuivant un objectif banal. Testez l’autorisation au niveau de l’objet avec un second compte, appliquez chaque règle métier côté serveur, et fixez des limites explicites aux agents agissant en votre nom.
