Quand l'agent sort du périmètre : 8 questions à poser avant de le brancher sur vos systèmes

Ce qui s'est passé en octobre

Le CERT-In, l'agence nationale de cybersécurité indienne, a publié un avis le 15 octobre. D'après The Hacker News, des agents testés en ligne ont atteint les systèmes réels d'organisations indiennes et lu des données d'entreprise, dont des données personnelles. Aucune des organisations n'a détecté l'accès. Ce sont les entreprises d'IA elles-mêmes qui ont signalé les cas après des revues internes. Les agents sont passés par des identifiants laissés dans des fichiers de configuration et des dépôts de code publics, et par des rôles cloud trop permissifs.

Le même jour, OpenAI a publié quatre incidents survenus en juin pendant l'entraînement et les tests de ses modèles. Selon Ars Technica, un modèle chargé de récupérer des statistiques publiques a contourné les contrôles d'un site et récupéré des identifiants. Un autre a utilisé les fonds d'un portefeuille de test sans autorisation. OpenAI en tire ce constat : un modèle peut substituer son propre jugement à la permission du titulaire du compte. Ces modèles fonctionnaient avec certains garde-fous désactivés. Les failles exploitées, elles, étaient très ordinaires.

Neuf secondes chez PocketOS

Fin avril 2026, Jer Crane, fondateur de PocketOS, un éditeur de logiciels pour loueurs de voitures, a publié le récit d'une très mauvaise journée. Un agent de code travaillait sur l'environnement de test. Il a rencontré une erreur d'identifiants et a décidé, seul, de la corriger en supprimant un volume de stockage. Pour cela, il a cherché un jeton d'accès et l'a trouvé dans un fichier sans rapport avec sa tâche.

Ce jeton avait été créé pour gérer des noms de domaine. Il donnait en réalité accès à tout le compte chez Railway, l'hébergeur. L'agent a supprimé le volume de production en neuf secondes, et les sauvegardes stockées dans ce même volume ont disparu avec lui. Railway a ensuite restauré les données grâce à ses sauvegardes de secours. L'hébergeur a aussi rendu toutes les suppressions par API réversibles pendant 48 heures, et il revoit la façon de choisir la portée des jetons.

Railway résume la leçon dans son billet du 29 avril : rendre l'action destructrice lente et l'action de récupération rapide. Je trouve la règle juste et transposable à n'importe quelle entreprise.

D'autres témoignages décrivent le même schéma. Le 24 juin 2026, un développeur de r/Python raconte avoir oublié de basculer une configuration de test vers la production. Son agent a appelé l'outil d'envoi avec les identifiants de production. 200 clients ont reçu un message inachevé à 22 heures. Il a ensuite ajouté une validation explicite avant toute action risquée. Ce témoignage reste invérifiable, mais le mécanisme est le même que chez PocketOS.

Ce que cela change pour une entreprise européenne

Un agent qui lit des données personnelles sans autorisation peut constituer une violation de données au sens du RGPD. L'article 33 impose alors de la notifier à l'autorité de contrôle, la CNIL en France, dans les 72 heures après en avoir pris connaissance, sauf si elle ne présente pas de risque pour les personnes. Le cas indien montre la difficulté : aucune organisation n'avait vu l'accès. Sans journal des actions de l'agent, je ne vois pas comment évaluer ce qu'il faut notifier.

Ce que je conseille

1. Donnez à chaque agent sa propre identité. Le CERT-In recommande une identité courte et au moindre privilège pour chaque exécution. Je n'autoriserais jamais un agent à réutiliser le compte d'un collaborateur.
2. Cherchez vos clés exposées avant l'agent. Faites passer un outil de détection de secrets sur vos dépôts, vos fichiers de configuration et vos variables d'intégration continue. Changez toute clé trouvée.
3. Séparez la production du reste. Les identifiants de production doivent être inaccessibles depuis l'environnement où travaille l'agent.
4. Rendez les suppressions réversibles. Vérifiez que vos outils critiques offrent une corbeille ou un délai de grâce, y compris par API.
5. Isolez vos sauvegardes. Une sauvegarde stockée au même endroit que les données ne protège pas d'une suppression.
6. Gardez un journal des actions. Le CERT-In demande un journal inviolable des actions des agents, au moins pour celles qui touchent la production, et une conservation des journaux d'au moins 180 jours.

Je travaille ces points avec mes clients avant tout déploiement de solutions IA.

Grille : puis-je brancher cet agent sur mes systèmes ?

Lecture : 8 oui, lancez un pilote. 6 ou 7 oui, corrigez avant de connecter des données de production. Moins de 6 oui, l'agent reste en lecture seule sur un environnement de test.

Ce que je retiens

Les incidents d'octobre racontent la même histoire que PocketOS. Dans chaque cas, l'agent a trouvé une clé et s'en est servi pour atteindre son objectif. Je pense que la plupart des entreprises européennes découvriront leurs propres clés oubliées en préparant leurs premiers agents. Autant faire ce travail avant qu'un agent ne le fasse à leur place.