Votre agent IA sait déjà supprimer la base de données. L'en empêcher ne vous protège pas.
Les éditeurs vendent l'interdiction action par action pour les agents IA. Mais le verbe destructeur est souvent le geste légitime : ce qui protège réellement, c'est la réversibilité et la maîtrise du rayon d'impact, pas un veto sur chaque commande.
Confiez un identifiant à un agent autonome et vous ne lui avez pas simplement donné un accès. Vous lui avez remis un menu d'actions. L'essentiel de l'arsenal de sécurité en entreprise a été conçu pour répondre à une seule question : cette entité a-t-elle le droit d'atteindre cette application ? Pare-feu, fournisseurs d'identité, revues d'accès : tout s'arrête à la porte. Rien ne régit ce que l'agent fait une fois entré, et c'est précisément là qu'un système autonome cause des dégâts.
La réponse des éditeurs consiste à interdire finement, action par action : évaluer en temps réel chaque geste de l'agent et bloquer les dangereux avant qu'ils ne s'exécutent. Arrêter cette suppression précise, dans cette session, avant exécution, sans tuer les quatre-vingt-dix-neuf actions bénignes alentour. C'est un vrai progrès par rapport au tout-ou-rien, et cela ne résout encore que la moitié du problème.
Voici ce que l'argumentaire commercial passe sous silence : le verbe n'est pas le danger. Il n'y a rien d'intrinsèquement hostile dans un delete. Un agent que vous avez recruté pour purger des doublons doit supprimer. Celui qui réconcilie un grand livre doit écraser des valeurs. Celui qui gère le départ d'un collaborateur doit révoquer des accès. Bloquez le verbe destructeur et vous cassez la mission confiée à l'agent ; autorisez-le et la même habilitation qui purge dix doublons peut effacer dix mille lignes. Un filtre action par action est contraint de trancher un jugement qu'il n'a pas les moyens de rendre : est-ce la suppression voulue, ou celle qui vous met à genoux ? Répétez cette décision des milliers de fois par minute et certains verdicts seront faux, sans qu'une politique fondée sur le verbe permette de rendre ces erreurs sans conséquence. Qu'une même habilitation regroupe si souvent lecture, écriture et suppression n'a rien d'une bizarrerie de configuration : le guide de l'OWASP sur l'excès d'autonomie (excessive agency) pointe exactement ce travers, décrivant une intégration accordée pour la lecture qui autorise en réalité, discrètement, aussi la modification et la suppression.
La bonne question n'est donc pas de savoir si un agent a le droit de supprimer. C'est ce qui se passe quand il supprime ce qu'il n'aurait pas dû. Deux propriétés en décident, et ni l'une ni l'autre n'est le verbe : le degré de réversibilité de l'action, et l'étendue de son rayon d'impact. Concevez votre dispositif autour de ces deux axes, et une suppression malheureuse devient un désagrément que l'on annule, plutôt qu'un incident que l'on doit déclarer.
Comment classer ce qu'un agent IA a le droit de faire ?
Classez les actions selon leurs conséquences, pas selon leur nom. Quatre paliers, du moins coûteux au catastrophique, chacun avec son propre contrôle et sa propre facture.
Palier 1, les actions non mutantes : lectures, requêtes, synthèses. Elles ne modifient aucun état, donc autant les autoriser largement plutôt que de les filtrer une par une. Le risque résiduel n'est pas la casse mais l'exfiltration : un agent qui lit tout, vite, constitue une fuite de données même s'il n'a rien cassé. Le contrôle adapté est un quota de volume par session et une journalisation complète, pas un veto sur chaque lecture. Coût : un volume d'audit conséquent à stocker.
Palier 2, les écritures réversibles : créations et mises à jour dont l'état antérieur est conservé. Conservez l'image précédente de chaque enregistrement touché par l'agent, et toute écriture devient annulable. La contrepartie est le stockage et l'amplification d'écriture, ainsi qu'un schéma de données qui porte désormais des versions qu'il ne portait pas avant. Pour la plupart des données métier, c'est une broutille comparée au coût d'un écrasement irrécupérable.
Palier 3, les destructions récupérables : suppressions et archivages qui transitent par une corbeille technique (tombstone). Plutôt que de retirer la ligne, on la marque supprimée et on la garde récupérable pendant une fenêtre de rétention définie. L'agent voit l'enregistrement disparaître et poursuit sa tâche, pendant que vous conservez une fenêtre pour repérer et annuler une erreur. La tension ici est réelle et mérite d'être nommée : des données que vous êtes légalement tenu d'effacer, au titre du RGPD, ne peuvent pas dormir indéfiniment dans une corbeille technique. La durée de rétention relève donc d'un arbitrage de politique interne, pas d'un réglage par défaut.
Palier 4, les actions irréversibles : supprimer une table, purger au-delà de la fenêtre de rétention, réécrire un jeu d'habilitations, exporter en masse vers un environnement que vous ne maîtrisez pas. Ce sont les seules actions qui justifient réellement une interdiction avant exécution, et l'intérêt des trois paliers précédents est justement de maintenir cette liste courte. Une liste courte, on peut se permettre de la garder sérieusement : une validation renforcée, un second identifiant ou une signature humaine sur le palier 4 ne coûtent presque rien, précisément parce que le palier 4 est rare. Exiger la même cérémonie pour chaque action est ce qui fait s'effondrer l'interdiction généralisée action par action, sous son propre poids en latence.
La réversibilité plafonne la gravité d'une erreur isolée. Le budget de rayon d'impact plafonne le nombre d'erreurs qui peuvent s'accumuler avant que quoi que ce soit ne s'arrête. Attribuez à chaque session d'agent un budget d'écriture : un plafond d'opérations destructrices avant que l'exécution ne se mette en pause pour revue, des validations par lots qui s'appliquent progressivement plutôt que d'un coup, des limites de débit qui coupent le courant sur une boucle devenue folle bien avant qu'elle n'ait terminé. Rien de tout cela ne suppose que l'agent soit parfait. Un budget de rayon d'impact garantit seulement qu'aucune exécution isolée ne peut causer des dégâts illimités dans l'intervalle entre le moment où cela dérape et le moment où on s'en aperçoit.
L'opacité sur laquelle vous comptiez, et que vous n'avez jamais payée
Il existe un effet de second ordre qu'on ne trouve sur aucune cartographie des risques. Les données de l'entreprise sont dispersées entre des dizaines d'outils SaaS, et cette fragmentation accomplissait un travail de sécurité que personne ne facturait. Les données sensibles n'étaient pas tant verrouillées que dispersées, et les localiser coûtait cher à un attaquant contraint de progresser application par application, schéma par schéma, à rythme humain. Le coût de la découverte faisait office de contrôle, sans jamais apparaître comme tel dans un budget.
Un agent érode ce coût. Il peut traverser les systèmes méthodiquement, recouper ce qui était auparavant trop fastidieux à recouper, et il le fait à vitesse machine. Des données privées en pratique parce qu'elles étaient difficiles à trouver deviennent systématiquement repérables. Le même mécanisme tend à faire remonter la dette d'identité que porte la plupart des parcs applicatifs : le compte administrateur sans authentification à deux facteurs, la connexion locale qui contourne l'identité centralisée, le compte de service que personne n'a audité depuis sa création. Un attaquant humain, lent, n'avait rarement le temps de tout sonder ; un agent automatisé et infatigable le fait en routine. C'est un raisonnement sur le comportement de ces systèmes, pas une statistique mesurée, mais la tendance est difficile à contester.
Le marché a déjà mis un prix sur une version de ce risque. Lorsque F5 a déboursé environ un milliard de dollars pour racheter Shape Security, opération finalisée début 2020 selon le dossier réglementaire déposé par F5 lui-même, l'entreprise achetait la capacité de distinguer un comportement légitime d'un abus automatisé, pas seulement de vérifier qui se présentait à la porte. La même thèse pointe désormais vers l'intérieur, vers des agents détenteurs d'identifiants valides mais au comportement anormal. Là où le périmètre comptait le plus autrefois, c'est désormais le comportement au sein même des applications qui capte l'attention, et les budgets.
Pourquoi la supervision humaine ne suffit pas à elle seule
Une fois le risque identifié, le réflexe est de placer un humain devant les actions dangereuses. Cela fonctionne pour le palier 4, où la liste est assez courte pour qu'une file de validation ne grippe pas l'agent. Cela échoue partout ailleurs. Les centres opérationnels de sécurité matures fonctionnent avec un analyste au milieu du dispositif : une alerte se déclenche, quelqu'un enquête, une décision suit, minutes ou heures plus tard. Face à un intrus humain, quelques minutes suffisent généralement. Face à un agent qui lit, recoupe et supprime au sein d'une seule exécution autonome, quelques minutes, c'est déjà un post-mortem, car une table supprimée n'attend pas poliment sa restauration pendant qu'un ticket suit son circuit de traitement.
C'est pourquoi la réversibilité, plutôt que le jugement humain en temps réel, doit être le contrôle par défaut. On ne peut pas poster un humain derrière chaque action qu'un agent exécute, et il ne faut pas chercher à le faire. Rendez sans conséquence les erreurs sur les actions courantes, et gardez les actions irréversibles peu nombreuses et étroitement surveillées, afin que l'attention humaine se porte là où elle rapporte réellement. Les organisations qui intègrent cela dans leur architecture, plutôt que de le greffer après le premier incident, sont celles qui traitent les systèmes agentiques sécurisés comme une discipline d'ingénierie, et non comme une case de conformité à cocher.
L'arsenal que la plupart des entreprises possèdent déjà a été conçu pour trancher si un agent devait être laissé entrer. L'interdiction action par action, ce que les éditeurs vendent aujourd'hui, déplace la question vers ce que l'agent fait ensuite, ce qui constitue un progrès. Mais policer le verbe n'est pas la ligne d'arrivée. Rendez réversibles les actions courantes, budgétez le rayon d'impact de chaque session, puis réservez une garde stricte à la liste courte des actions véritablement irréversibles. Faites cela, et la pire exécution d'un agent devient quelque chose que l'on annule avant midi, plutôt que quelque chose que l'on doit expliquer à un régulateur.
Questions fréquentes
Faut-il simplement interdire à un agent IA de supprimer ou de purger des données ?
Rarement, car bloquer le verbe casse le travail légitime : un agent chargé de purger des doublons ou de gérer le départ d'un collaborateur doit pouvoir supprimer et révoquer des accès. Le schéma le plus robuste consiste à faire transiter les destructions par une suppression douce ou une corbeille technique avec fenêtre de rétention, pour qu'une suppression malheureuse reste récupérable, et à réserver les blocages stricts, avant exécution, à la liste courte des actions vraiment irréversibles comme supprimer une table ou exporter en masse.
Qu'est-ce que le budget de rayon d'impact pour un agent IA ?
C'est un plafond, par session, sur les dégâts qu'une seule exécution d'agent peut causer : une limite d'opérations destructrices avant mise en pause pour revue, des validations appliquées par lots plutôt que d'un seul coup, et des limites de débit qui coupent une boucle devenue incontrôlable. Cela ne cherche pas à rendre l'agent infaillible. Cela borne le nombre d'erreurs qui peuvent s'accumuler avant qu'un mécanisme n'arrête la session, ce qui transforme un incident potentiellement illimité en incident contenu.
Disperser ses données entre plusieurs outils SaaS protège-t-il des agents IA ?
Cela le faisait, par accident. La fragmentation rendait les données coûteuses à localiser pour un attaquant progressant application par application à rythme humain, si bien que le coût de la découverte agissait comme un contrôle jamais budgété. Un agent traverse et recoupe ces systèmes à vitesse machine, si bien que des données privées en pratique parce que difficiles à trouver deviennent systématiquement repérables : l'opacité par fragmentation cesse alors de faire office de protection.
À lire aussi
- La prime de souveraineté : pourquoi les entreprises paient plus cher une IA qu'aucun gouvernement étranger ne pourra couper
- Washington désigne son propre laboratoire d'IA comme risque stratégique : ce que cela change pour votre dépendance fournisseur
- Les pilotes d'IA en entreprise ne calent pas sur la technologie, mais sur la confiance
- Security & Trust
Rédigé par un persona éditorial IA du système éditorial propriétaire d'Abyshire et relu par notre équipe.