Un agent d'IA est un nouvel utilisateur à privilèges
Les architectures de sécurité classiques reposaient sur une frontière : à l'extérieur, la méfiance ; à l'intérieur, une confiance de fait. L'arrivée d'agents capables d'agir au nom des équipes bouscule cette logique, car un agent n'est pas un humain identifiable par son poste de travail. Il exécute des tâches en rafale, parfois déclenchées par un contenu qu'il a lui-même lu, et son comportement varie en fonction des instructions reçues. Lui accorder une confiance implicée, au motif qu'il tourne sur l'infrastructure interne, revient à ouvrir une porte qu'aucun autre service ne mériterait.
Cette situation impose de traiter chaque agent comme une identité à part entière, avec ses propres accès et ses propres limites. Un agent chargé de résumer des documents n'a pas de raison de pouvoir modifier une base de données ; un agent de support n'a pas besoin de lire les dossiers de paie. La difficulté tient au fait que ces outils sont souvent déployés vite, pour répondre à une demande pressée, avec des droits larges pris par commodité. Reprendre ces droits à la baisse après coup est bien plus coûteux, et plus risqué, que de définir dès le départ ce que l'agent doit strictement pouvoir faire.
Authentifier, limiter et journaliser chaque action
Le modèle zero trust se traduit par quelques gestes simples mais exigeants. Chaque appel d'un agent vers un service est authentifié pour lui-même, et non au moyen d'un jeton partagé valable pour tout le reste. Chaque action s'exerce dans le périmètre de droits strictement nécessaires à la tâche en cours, et pas au-delà. Chaque échange est journalisé, de façon à pouvoir reconstituer ce qui a été fait, quand, et sous quelle instruction. Ces trois exigences, une fois tenues ensemble, transforment un agent d'une boîte noire agissante en un composant dont on suit le comportement et que l'on peut interrompre.
La journalisation joue un rôle particulier, souvent négligé jusqu'au premier incident. Un agent qui se comporte mal ne le signale pas lui-même : il faut pouvoir remonter la séquence des actions pour comprendre ce qui l'a conduit là. Court-circuiter les vérifications côté service est un risque majeur : un agent ne doit pas dépendre de sa propre discipline pour respecter les limites. Les points d'application sont les services exposés eux-mêmes, qui décident seuls d'accorder ou de refuser l'accès, indépendamment de ce que l'agent prétend être autorisé à faire, ce qui n'est pas neutre pour l'organisation comme pour la personne.
Le moindre privilège appliqué aux outils et aux données
Un agent ne vaut que par les outils qu'on lui donne, et ce sont précisément ces outils qui élargissent sa surface d'action. Chaque outil connecté devient un chemin possible vers une donnée sensible ou une opération irréversible. Le principe du moindre privilège conduit à limiter à la fois les droits accordés et le nombre d'outils accessibles à un même agent : un assistant polyvalent qui peut tout faire est aussi un point de défaillance qui peut tout compromettre. Fragmenter les capacités en plusieurs agents spécialisés réduit ce que la compromission de l'un permet d'atteindre, et rend plus lisible qui peut faire quoi.
La sensibilité des données impose une seconde limite. Un agent doit connaître son périmètre : quelles bases il peut consulter, quelles informations restent hors de sa portée, ce qui relève d'une classification particulière. Ce point rejoint les obligations du RGPD, qui impose de limiter les traitements à la finalité poursuivie et de restreindre l'accès aux seules personnes, ou composants, qui en ont besoin. La conception doit intégrer ces contraintes dès la spécification, plutôt que de les traiter comme une couche ajoutée après coup sur un dispositif déjà largement ouvert, ce qui n'est pas neutre pour l'organisation comme pour la personne.
Détecter l'usage détourné d'un agent
Même bien limité, un agent reste exposé à des tentatives de détournement. Une instruction malveillante glissée dans un document qu'il doit lire peut le conduire à accomplir une action non prévue, et le contenu qu'il traite ne doit jamais être considéré comme une source fiable de commandes. La défense consiste à séparer nettement les instructions légitimes des données lues, à vérifier les actions sensibles avant de les exécuter, en particulier celles qui modifient un état ou s'adressent à l'extérieur de l'organisation, et à exiger une confirmation pour toute opération difficilement réversible.
Détecter ces usages suppose d'observer le comportement plus que le contenu. Un agent qui soudain consulte des ressources hors de son périmètre habituel, ou émet des requêtes en volume inhabituel, signale une anomalie à examiner. Ces signaux n'ont de valeur que s'ils sont collectés et rapprochés les uns des autres, sur une durée assez longue pour distinguer l'incident isolé de la dérive lente. Le zero trust n'est donc pas un produit que l'on installe, mais une posture de méfiance calculée, entretenue par des vérifications continues et par la capacité à couper court dès qu'un comportement sort du cadre attendu.
Aller plus loin
Sécuriser des agents d'IA demande de maîtriser à la fois l'architecture, les accès et les techniques de détournement que ces systèmes subissent. Le catalogue des 31 formations comprend le parcours de spécialiste de la sécurité des agents d'IA.
Vous voulez maîtriser ce sujet en pratique ?
Cabinet MARA forme en ligne, sur des cas réels, avec des modules courts et un suivi de progression.
Voir la formation liée Les 31 formations