La plupart des organisations ont eu, ou auront bientôt, la discussion sur les assistants de codage IA : qui y a droit, où s’en vont les données, comment on journalise. C’est un dossier inconfortable mais borné. Un produit, un fournisseur, une population identifiable.
Le dossier suivant n’a pas cette forme. Les mêmes fournisseurs livrent maintenant des plateformes qui permettent à des employés sans formation technique de construire leurs propres agents — des assistants qui lisent des documents, interrogent des systèmes, envoient des courriels et exécutent des actions.
À ce moment-là, la question de sécurité cesse de porter sur un produit et porte sur des centaines de petits produits, construits par des personnes qui ne se considèrent pas comme des développeurs et qui ne viendront pas vous demander une revue. Elles ne vous contournent pas : elles ne savent tout simplement pas qu’elles construisent quelque chose qui devrait être revu.
Le problème : ce n’est pas du développement, jusqu’à ce que ça en soit
Une plateforme d’agents est vendue comme un outil de productivité, pas comme un environnement de développement. C’est un choix de positionnement délibéré du fournisseur, et il est efficace : l’adoption est rapide précisément parce que rien dans l’expérience ne suggère qu’une revue soit nécessaire.
Mais l’objet produit est un logiciel. Il a des entrées non fiables, des identifiants, des accès à des données, une logique de décision et des effets de bord. Il n’a simplement ni dépôt de code, ni revue, ni propriétaire déclaré, ni cycle de vie.
Et il en existera beaucoup. C’est le point structurant : votre processus de gouvernance actuel, quel qu’il soit, a été conçu pour un débit de quelques applications par année. Il ne tiendra pas devant deux cents agents construits en six mois.
Les risques, concrètement
L’agent hérite des accès de son créateur. C’est le risque dominant, et il est facile à sous-estimer parce qu’il ne ressemble pas à une élévation de privilèges. Une personne des finances construit un agent qui résume les dossiers auxquels elle a accès ; l’agent voit donc tout ce qu’elle voit. Elle le partage ensuite avec son équipe, et l’agent continue de s’authentifier avec ses droits à elle. L’outil n’a rien fait d’anormal. Les accès ont simplement cessé de correspondre à qui les utilise.
L’OWASP a nommé ce mécanisme dans son Top 10 pour les applications agentiques (ASI03 — abus d’identité et de privilèges), et c’est celui qui se matérialise en premier dans les déploiements réels.
L’injection dans le contenu que l’agent lit. Un agent qui traite des courriels, des documents fournisseurs ou des billets de service consomme du texte rédigé par des tiers. Ce texte peut contenir des instructions. L’agent ne distingue pas structurellement « donnée à traiter » de « consigne à suivre » — c’est le détournement d’objectif (ASI01). Le vecteur n’est pas exotique : il suffit qu’un document entrant contienne une phrase adressée à l’agent.
La sortie des données hors du locataire. Chaque connecteur activé est un chemin de sortie potentiel. La question n’est pas de savoir si le fournisseur est digne de confiance, mais de savoir quels connecteurs vos employés peuvent activer sans demander la permission — et la réponse par défaut est généralement « tous ».
L’absence de propriétaire. L’agent construit par une personne qui change de poste dix mois plus tard continue de fonctionner. Personne ne sait à quoi il sert, personne n’ose l’éteindre, et il conserve les accès d’un compte dont plus rien ne justifie la portée.
L’absence de trace. Si vous ne pouvez pas répondre à quels agents existent, qui les a construits, à quoi ils accèdent et ce qu’ils ont fait, vous ne pouvez répondre à aucune question d’incident les concernant.
Ce qu’il faut régler avant la disponibilité générale
L’ordre compte. Les trois premiers points doivent être en place avant que le premier agent ne soit construit, parce que les rattraper ensuite signifie auditer un travail dont vous ignoriez l’existence.
1. Décider de la structure d’environnements avant d’ouvrir l’accès
Séparez au minimum ce qui est expérimental de ce qui est utilisé par d’autres personnes que son auteur. Un agent partagé n’est plus une expérience, et la frontière du partage est le seul endroit naturel où placer un contrôle.
C’est la décision la plus difficile à revenir corriger, parce qu’elle détermine où tout le reste s’applique.
2. Restreindre les connecteurs par liste d’autorisation, pas par liste d’interdiction
Une liste d’interdiction suppose que vous connaissez l’ensemble des destinations possibles. Vous ne le connaissez pas, et le fournisseur en ajoute chaque trimestre.
Autorisez explicitement les connecteurs dont l’organisation a besoin, et exigez une demande pour les autres. Le volume de demandes sera bas — la plupart des agents utilisent trois ou quatre connecteurs — et chaque demande vous donne la visibilité que vous n’auriez pas eue autrement.
3. Journaliser dès le premier agent
Pas après le premier incident. La journalisation est ce qui transforme toutes les autres mesures d’affirmations en éléments de preuve, et c’est la seule qu’il est impossible de reconstituer rétroactivement.
4. Exiger un propriétaire nommé et une date de revue
Une ligne par agent. Ce n’est pas de la bureaucratie : c’est ce qui rend possible l’extinction d’un agent orphelin sans réunion.
Faites de la revue une échéance qui expire. Un agent dont la date de revue est dépassée devrait cesser de fonctionner, pas générer un courriel de rappel que personne ne lit.
5. Traiter le contenu entrant comme non fiable
Pour tout agent qui lit du contenu venant de l’extérieur, la règle utile est simple : le contenu lu ne détermine jamais une action irréversible. Résumer, classer, proposer — oui. Envoyer, payer, supprimer, accorder un accès — jamais sans confirmation humaine.
C’est une règle qu’un employé non technique peut comprendre et appliquer, ce qui compte plus que sa sophistication.
6. Limiter les accès de l’agent, pas seulement ceux de son créateur
Là où la plateforme le permet, faites fonctionner l’agent avec une identité propre et des droits minimaux plutôt qu’avec les droits délégués de son constructeur. Quand ce n’est pas possible — et ce ne l’est souvent pas encore — alors les accès du constructeur deviennent le vrai périmètre de l’agent, et le choix de qui peut construire des agents devient une décision de sécurité.
7. Prévoir une revue légère, réservée à ce qui compte
N’essayez pas de réviser deux cents agents. Définissez un déclencheur — accès à des données personnelles ou financières, action irréversible, partage au-delà d’une équipe — et révisez seulement ce qui le franchit.
Un processus qui prétend tout couvrir sera contourné. Un processus qui couvre 5 % des agents et qui est réellement appliqué vaut infiniment plus.
La fenêtre est courte
Ce travail coûte peu tant que la plateforme n’est pas ouverte. Il devient un projet dès que quelques centaines d’agents existent, parce qu’il faut alors inventorier avant de gouverner, et l’inventaire est la partie coûteuse.
Si votre organisation évalue actuellement ce type de plateforme — et pour beaucoup, elle est déjà incluse dans une licence existante, ce qui signifie que la décision d’achat a été prise sans que la question de sécurité soit posée — la bonne intervention est maintenant, pendant que c’est encore un projet.
La question à poser en comité n’est pas « est-ce qu’on autorise les agents ». C’est : quand quelqu’un aura construit un agent qui envoie des courriels au nom d’un collègue, saurons-nous lequel, qui l’a construit, et ce qu’il a envoyé ?
Si la réponse est non, ce n’est pas la plateforme qu’il faut bloquer. C’est cette réponse-là qu’il faut changer, et il est beaucoup moins cher de la changer avant.
Besoin d’aide pour mettre cela en œuvre ?
Nous travaillons avec votre équipe pour concevoir, construire et exploiter les contrôles décrits ci-dessus.