Un agent IA se connecte à un outil interne avec un jeton parfaitement valide. L’annuaire d’entreprise confirme ses droits, la trace d’audit reste propre. Deux minutes plus tard, il a glissé dans un rapport client trois documents que personne ne lui avait demandé d’ouvrir.
Rien n’a été piraté, aucune règle d’accès n’a été contournée. Le problème naît après l’ouverture de la porte, dans les décisions que l’agent prend une fois entré.
Un badge répond à une question, une seule
La sécurité d’entreprise répond depuis vingt ans à trois questions : qui êtes-vous, à quoi avez-vous accès, quelles actions avez-vous le droit de déclencher. Fournisseurs d’identité, authentification multifacteur (MFA), droits attribués par rôle, architectures zero trust : cette dernière brique a été codifiée par le NIST, l’institut de normalisation américain, dans sa publication SP 800-207. Pour des humains et des applications classiques, l’ensemble fonctionne.
Une application classique exécute une logique écrite à l’avance par un développeur. Un agent décide en cours de route : quel outil appeler, quelle API (interface de programmation) interroger, quelle information aller chercher, dans quel ordre enchaîner les étapes. L’authentification photographie un instant, celui de l’entrée. Le comportement, lui, se construit après.
Prenez l’image du badge d’immeuble. Il ouvre la porte parce qu’il est valide, il ne dit rien de ce que son porteur fera une fois à l’intérieur. Chez un salarié, l’écart reste borné par le bon sens, la hiérarchie et les conséquences. Un agent n’a que son objectif et le contexte qu’on lui donne.
Trois dérapages qui commencent après l’authentification
- La dérive d’objectif. L’agent part d’une consigne légitime et s’en éloigne à mesure qu’il cherche à mieux atteindre son but. Chargé de préparer un rapport client, il va chercher de lui-même des informations confidentielles sans rapport, parce qu’elles enrichissent le document.
- L’exposition de données. L’agent dialogue avec des serveurs MCP (Model Context Protocol, le standard qui expose des outils aux modèles), des bases vectorielles, des systèmes RAG (génération augmentée par recherche documentaire), des API métier, des plateformes SaaS et parfois d’autres agents. Une seule API trop permissive dans cette chaîne suffit à faire sortir ce qui devait rester à l’intérieur.
- L’empoisonnement de la mémoire. Une source de connaissance compromise, un outil corrompu, un document manipulé : l’instruction hostile n’arrive plus par le prompt de l’utilisateur, mais par ce que l’agent va lire lui-même pour se documenter. Elle contamine alors toutes les décisions qui suivent.
Ces trois défaillances ont une propriété commune : elles apparaissent pendant l’exécution, pas au déploiement. Un contrôle qui s’exerce à l’entrée ne les voit jamais.
La passerelle elle-même a fini au catalogue de la CISA
Le réflexe des équipes consiste à installer une passerelle, point de passage unique par lequel transite le trafic des agents, avec ses règles. L’intention est saine. La séquence l’est moins.
En juin, la CISA, l’agence américaine de cybersécurité, a ajouté une faille de LiteLLM, passerelle très répandue devant les modèles, à son catalogue des vulnérabilités activement exploitées : des attaquants s’en servaient déjà. Le défaut permettait d’exécuter des commandes sur la machine hôte à travers la passerelle elle-même ; combiné à une seconde faille, il ne réclamait plus aucune authentification. Sept vulnérabilités ont reçu un identifiant CVE dans ce seul produit en un mois.
Un agent de rapprochement comptable tente maintenant de modifier un enregistrement en production. La passerelle valide le jeton de l’utilisateur, vérifie l’appel d’API, laisse passer. Elle ne peut pas savoir que la requête vient d’un agent et non d’un humain, que cet agent exerce une fonction bien plus étroite, ni que cet appel appartient à une chaîne d’outils déclenchée par un document dont personne n’a vérifié l’origine. Le jeton est bon, l’appel est autorisé, l’action contredit la délégation.
Limiter un agent aux droits de la personne qu’il sert garde son utilité : cela pose un plafond de privilèges. Mais cela n’attribue rien à personne. Vingt agents peuvent tourner sous les permissions d’un même salarié et réclamer chacun leur identité propre, leur journal d’audit, leur profil de comportement et leur procédure de révocation.
L’inventaire et l’identité passent avant la passerelle
La réponse qui circule chez les praticiens de la sécurité prend la forme d’une séquence de contrôles emboîtés. Chaque étage a besoin du contexte produit par celui qui le précède, et rien ne sert de déclarer un contrôle opérationnel tant que le palier situé avant lui n’a pas passé son test de sortie. Le modèle en compte six ; la passerelle n’arrive qu’au cinquième.
Les trois premiers donnent le ton, et aucun ne s’achète sur étagère.
- L’inventaire des agents : chaque agent en production a un propriétaire nommé, une finalité, une liste d’outils approuvés et un état de cycle de vie.
- Une identité distincte par agent, assortie du contexte de délégation. Le système doit pouvoir dire quel agent agit, qui en répond, et pour le compte de qui il travaille.
- Des identifiants de courte durée, délivrés pour une tâche précise plutôt que pour un accès permanent.
Les fournisseurs d’identité ont pris ce virage avant leurs clients : Microsoft a étendu son annuaire Entra aux agents, et Okta a ouvert à tous ses clients, le 24 août, un Agent SSO qui enregistre chaque agent comme une identité à part entière, aux côtés des salariés, et lui délivre des jetons de courte durée au lieu d’une clé d’API permanente. Son protocole Cross App Access sert désormais d’extension d’autorisation d’entreprise au Model Context Protocol. La brique technique existe donc déjà ; ce qui manque se situe en amont.
Tant que ces trois paliers manquent, la passerelle applique une règle à un objet qu’elle ne sait pas nommer. Elle bloquera les violations grossières ; elle restera aveugle à la différence entre une action justifiée et une action techniquement permise mais inappropriée.
La règle doit s’exécuter là où l’action a lieu
Reste la couche la plus inconfortable, celle des données. Une politique de sécurité rédigée dans un document ne s’exécute pas. Le contrôle doit descendre au niveau opérationnel, au moment précis où l’agent agit, et tenir compte du contexte : la même écriture en base peut être banale sur un jeu de test et appeler un jugement plus fin sur un dossier client sensible. Une règle littérale et figée ne fait pas cette différence.
Le chantier relève de l’architecture, pas d’un paragraphe de politique ajouté au-dessus du modèle. La qualité du modèle ne rattrapera pas ce retard : un modèle excellent en moyenne qui se trompe une fois sur mille finit par produire un incident dès qu’il agit sans validation humaine.
Un assistant propose une réponse et attend l’approbation, un agent exécute. Une transaction lancée, un enregistrement client modifié, un virement déclenché sur une mauvaise interprétation ne se corrigent pas comme une phrase mal tournée. Avant d’installer le poste de contrôle, il faut savoir nommer ce qui se présente devant lui.
