Votre agent IA a besoin de son propre périmètre de sécurité
Les logiciels d'entreprise fonctionnent généralement selon des autorisations clairement définies. Un employé ouvre une application, demande une action et le logiciel suit une logique prédéterminée. Les administrateurs décident à quels systèmes l'employé peut accéder, quelles données il peut consulter et quelles opérations il peut effectuer. Les agents d'IA viennent compliquer ce modèle.
Un agent peut interpréter un objectif, choisir parmi différents outils, récupérer des informations, appeler une interface de programmation d'application et effectuer plusieurs actions avant de renvoyer une réponse à l'utilisateur. C'est cette flexibilité qui fait en grande partie la valeur des agents.
Cela soulève également un nouveau problème de sécurité. Les entreprises doivent contrôler les actions d'un agent lorsque celui-ci se comporte différemment de ce que ses concepteurs avaient prévu.
Un agent s'apparente davantage à une identité qu'à une caractéristique
Les entreprises déploient souvent l'IA générative comme s'il s'agissait simplement d'ajouter une fonctionnalité logicielle supplémentaire. Cette approche fonctionne lorsque le modèle ne produit que du texte. Un agent capable d'intervenir au sein des systèmes de l'entreprise mérite toutefois un traitement différent. Prenons l'exemple d'un agent chargé des achats.
Il peut consulter les fiches fournisseurs, comparer les contrats, rédiger une commande et transmettre des informations à un système de gestion intégrée (ERP). Un agent du service client peut accéder aux détails d’un compte, mettre à jour des dossiers et lancer des remboursements. Un agent développeur peut lire du code source, exécuter des commandes et déployer des modifications. Chaque agent dispose donc de privilèges. Les équipes de sécurité savent déjà comment gérer les identités privilégiées, qu’elles soient humaines ou machines. Elles restreignent les accès, surveillent l’activité et isolent les systèmes sensibles. Les agents IA ont besoin de contrôles similaires.
Le principe du « privilège minimal » devient essentiel
Un agent ne devrait avoir accès qu'aux systèmes et aux actions nécessaires à l'accomplissement de sa tâche. Ce principe semble évident. Mais la facilité d'utilisation peut rapidement le compromettre. Les équipes de développement connectent souvent un agent à un large éventail de ressources internes, car un accès plus étendu améliore les performances pendant les tests. Une fois que l'agent est mis en production, ces autorisations peuvent rester en place.
Le risque qui en découle est difficile à détecter, car l’agent lui-même n’a pas besoin d’avoir une intention malveillante. Une instruction mal formulée, un contenu externe manipulé ou un raisonnement inattendu peuvent amener le système à utiliser des autorisations légitimes de manière non sécurisée. Les entreprises doivent donc concevoir les identités des agents en fonction de rôles bien délimités. Un agent chargé du traitement des factures n’a pas besoin d’accéder aux données de paie. Un assistant de communication n’a pas besoin de pouvoir modifier l’infrastructure cloud. Un agent de recherche peut avoir besoin de lire des documents sans être autorisé à les supprimer ou à les publier. Le périmètre de sécurité doit être défini en fonction de la tâche à accomplir.
Les identifiants doivent rester temporaires
Les applications traditionnelles s'appuient souvent sur des identifiants à longue durée de vie. Les agents rendent cette pratique plus dangereuse. Un système autonome peut fonctionner sur plusieurs outils, ce qui multiplie les risques de fuite d'identifiants dans les journaux, les invites ou les sorties intermédiaires. Les identifiants temporaires réduisent ce risque. Au lieu d’accorder à un agent un accès permanent à un système, l’entreprise peut émettre des jetons à durée de vie limitée pour une action ou une session spécifique. L'autorisation expire automatiquement une fois la tâche terminée. Les opérations à haut risque peuvent nécessiter une deuxième validation avant que les identifiants ne soient mis à disposition. Cette conception améliore également la réponse aux incidents. Les équipes de sécurité peuvent révoquer l'accès d'un agent sans perturber l'ensemble du compte d'un employé ni reconfigurer des services non concernés.
L'accès aux outils doit être explicite
Les agents gagnent en efficacité lorsqu'ils peuvent choisir leurs outils de manière dynamique. Cette capacité nécessite des limites clairement définies. Une entreprise doit disposer d'un catalogue d'outils approuvés que chaque agent est autorisé à utiliser. Chaque outil ne doit proposer que les fonctions nécessaires au déroulement du flux de travail prévu.
Un agent du service client peut avoir besoin d'une fonction permettant d'effectuer un remboursement dans la limite d'un montant défini. Il n'a pas besoin d'un accès illimité à la base de données financière sous-jacente à cette fonction. Cela constitue une distinction architecturale importante. Dans la mesure du possible, l'agent doit interagir avec des actions métier contrôlées plutôt qu'avec l'infrastructure brute.
Les développeurs peuvent ensuite mettre en place des contrôles de validation autour de ces actions : limites de valeurs, champs obligatoires, statut du client, restrictions géographiques ou validation humaine. L'agent conserve ainsi une grande flexibilité au sein d'un environnement d'exploitation contrôlé.
Un contenu externe peut devenir une instruction
L’un des risques les plus inhabituels liés aux systèmes agentiques tient à la manière dont les modèles traitent l’information. Un être humain est généralement capable de faire la distinction entre les données et les instructions. Les logiciels opèrent traditionnellement cette distinction de manière encore plus rigide. Les grands modèles linguistiques fonctionnent différemment. Un agent qui explore un site web, lit un e-mail ou ouvre un document peut rencontrer du texte conçu pour influencer son comportement. Si le système ne parvient pas à distinguer efficacement les instructions fiables du contenu non fiable, les informations externes peuvent interférer avec la tâche de l’agent. L’injection de messages dans les réponses (prompt injection) ne se limite donc pas à un simple problème lié aux chatbots. Un agent ayant accès à des outils peut potentiellement agir sur la base d’instructions manipulées. La sécurité doit donc s’appliquer à la fois au modèle et à l’environnement dans lequel il opère. Le contenu provenant de sources externes devrait se voir attribuer un niveau de confiance inférieur. Les actions sensibles devraient nécessiter une validation supplémentaire. Les agents ne devraient pas être autorisés à considérer chaque élément de texte qu’ils lisent comme ayant la même autorité.
La segmentation du réseau fonctionne toujours
L'IA introduit une nouvelle terminologie, mais de nombreux principes de sécurité bien établis restent d'actualité. La segmentation du réseau en fait partie. Un agent qui n'a pas besoin d'un accès direct à une base de données de production ne devrait pas y avoir accès. Un agent opérant au sein d'une unité opérationnelle ne devrait pas pouvoir accéder automatiquement aux systèmes utilisés par une autre. Le sandboxing peut constituer une couche de protection supplémentaire.
Les entreprises peuvent autoriser les agents à exécuter du code, à manipuler des fichiers ou à tester des flux de travail au sein d'environnements isolés avant que quoi que ce soit n'atteigne les systèmes de production. Cela permet de limiter les conséquences d'un comportement imprévu. Un modèle sophistiqué ne nécessite pas pour autant une philosophie de sécurité sophistiquée. Il suffit de restreindre l'environnement, de limiter les autorisations et de partir du principe que des défaillances finiront par se produire.
Les journaux doivent consigner aussi bien les décisions que les actions
Les journaux de sécurité traditionnels enregistrent les événements : la connexion d'un utilisateur, la modification d'un fichier, la réalisation d'une transaction.
La surveillance des agents nécessite des informations contextuelles supplémentaires.
Les équipes chargées de la sécurité et de la conformité peuvent avoir besoin de savoir quelle instruction a déclenché la tâche, quels outils l'agent a sélectionnés et quelles informations il a reçues avant de passer à l'action.
Cela ne signifie pas pour autant qu'il faille consigner chaque processus lié aux modèles internes.
Cela implique la mise en place d'une chaîne traçable autour des opérations critiques.
Si un agent modifie la fiche d'un client, l'entreprise doit être en mesure de retracer la demande, l'autorisation, l'appel de l'outil et le résultat.
Sans cette trace, les organisations auront du mal à enquêter sur les incidents ou à démontrer leur maîtrise des processus auprès des autorités de régulation et des auditeurs.
L'autorisation humaine doit être subordonnée à l'évaluation des risques
Exiger une validation humaine pour chaque action d'un agent réduirait considérablement les gains de productivité.
Accorder une autonomie totale engendre le problème inverse.
Les entreprises ont donc besoin de seuils.
Les actions à faible risque peuvent être exécutées automatiquement. Un chargé de recherche interne peut résumer des documents sans autorisation préalable. Un chargé du service client peut mettre à jour les informations relatives aux tickets courants dans le respect de règles prédéfinies.
Les actions présentant un risque plus élevé devraient faire l'objet d'une escalade.
Les paiements, les clôtures de compte, les modifications de production, les démarches juridiques ou les communications externes peuvent nécessiter l'approbation d'une personne pour la dernière étape.
Ce seuil devrait tenir compte de l'impact potentiel plutôt que de la complexité technique.
Un appel d'API en apparence simple peut avoir de graves conséquences s'il implique un transfert d'argent ou la divulgation d'informations personnelles.
Tout agent a besoin d'un « kill switch »
Les entreprises doivent partir du principe qu'un agent finira par adopter un comportement auquel elles ne s'attendaient pas.
La réponse doit être immédiate.
Les administrateurs doivent pouvoir suspendre les droits d'accès d'un agent, mettre fin aux sessions actives et empêcher tout nouvel appel de l'outil sans avoir à arrêter les systèmes non concernés.
Les procédures de reprise sont également importantes.
Si l'agent a modifié des enregistrements avant l'arrêt du système, les équipes doivent identifier les transactions concernées et les annuler dans la mesure du possible.
La cybersécurité traditionnelle s'est attachée, pendant des décennies, à développer des capacités de confinement et de restauration. L'architecture des agents devrait les intégrer dès le départ.
La sécurité détermine le degré d'autonomie que peuvent atteindre les agents autonomes
Les entreprises continueront à confier davantage de responsabilités aux systèmes d’IA, car l’intérêt économique est évident. Un assistant qui se contente de rédiger des textes permet de gagner du temps. Un agent capable de mener à bien l’intégralité d’un flux de travail peut transformer le coût et la rapidité d’un processus métier. Le modèle de sécurité doit évoluer au même rythme. Les organisations doivent cesser de considérer l’accès des agents comme un simple problème de configuration secondaire. Les autorisations, les identifiants, les outils, les réseaux, la journalisation et les règles d’approbation constituent l’environnement opérationnel dans lequel l’agent prend ses décisions.
Plus une entreprise souhaite accorder d'autonomie, plus cet environnement doit être conçu avec précision. Un agent d'IA n'a pas besoin d'un accès illimité pour être utile. Il a besoin d'une liberté suffisante pour mener à bien sa tâche et de restrictions suffisantes pour éviter qu'une simple erreur ne se transforme en incident.
