Nik Kale, spécialiste des plateformes d’intelligence artificielle d’entreprise et de la sécurité, estime que de nombreuses organisations commencent par la passerelle d’exécution des agents, qu’elles considèrent comme le principal point de contrôle, alors que ces passerelles dépendent de couches d’identité et d’attribution qui ne sont pas toujours présentes ou suffisamment matures. Il en résulte que la passerelle peut vérifier la validité du jeton et de la requête d’API, mais qu’elle ne sait pas toujours quel agent a exécuté la requête, qui l’a mandaté, quelle tâche il accomplissait, ni si la requête faisait partie d’une chaîne d’outils initiée par un composant non fiable.
Cette problématique prend une importance pratique avec l’extension du déploiement des agents. En juin, l’Agence américaine de cybersécurité et de sécurité des infrastructures (CISA) a ajouté une vulnérabilité de LiteLLM à son catalogue des vulnérabilités exploitées connues, après avoir constaté qu’elle était effectivement exploitée. La vulnérabilité permettait d’exécuter des commandes sur l’hôte via la passerelle elle-même et, lorsqu’elle était associée à une seconde vulnérabilité, pouvait être exploitée sans identifiants. La source indique que la passerelle a fait l’objet de la divulgation de sept vulnérabilités et expositions courantes (CVEs) en un seul mois.
La sécurité est ici une chaîne de confiance, pas un point de contrôle unique
Kale propose ce qu’il appelle le « déploiement fondé sur la confiance », selon lequel aucune couche ultérieure ne doit être considérée comme opérationnellement complète avant que les tests requis pour les couches précédentes aient été réussis. Les contrôles peuvent être développés en parallèle, mais leur activation en production doit suivre un ordre clair :
- Inventaire des agents et propriété responsable : chaque agent de production doit avoir un propriétaire connu, une finalité définie, des outils approuvés et un état dans son cycle de vie.
- Identité indépendante et contexte de délégation : le système doit connaître l’agent, son propriétaire, ainsi que l’utilisateur ou l’entité pour le compte duquel l’agent exécute le travail.
- Identifiants à court terme et limités à la tâche : un agent compromis ne doit pas pouvoir accéder à des ressources sans rapport avec la tâche qui lui a été confiée.
- Mesure traçable : la tâche doit pouvoir être reconstituée depuis son lancement jusqu’à son impact final sur les autres systèmes.
- Application des procédures à l’exécution : les décisions de politique doivent s’appuyer sur l’identité de l’agent, l’entité délégante, la tâche et l’action, et non sur la seule validité du jeton.
- Référence comportementale et mécanisme d’arrêt intersystèmes : les équipes de sécurité doivent pouvoir interrompre l’autorité effective de l’agent dans tous les endroits auxquels il accède.
Commencer par ce qui peut être défini et attribué
La première étape, selon le cadre proposé, consiste à recenser les agents de production présents dans les frameworks open source, les services cloud, les produits SaaS et les outils de développement. Le registre comprend le propriétaire de l’agent, sa responsabilité, l’étape de son cycle de vie, les outils autorisés, les périmètres de données et les sources des identifiants. L’absence de cet inventaire ne constitue pas seulement un problème documentaire ; elle peut aussi consommer une partie du temps de réponse aux incidents dans une tentative d’identifier l’actif que l’organisation est censée connaître à l’avance.
L’auteur souligne que l’identité de l’agent ne devrait pas être enfouie dans un code de développeur, un compte de service partagé ou une session utilisateur. Savoir que l’appelant est un « agent » ne suffit pas. Il faut également enregistrer qui a délégué la tâche, la tâche précise et les ressources auxquelles l’agent doit accéder. L’identité désigne l’acteur, tandis que la délégation précise l’entité au nom de laquelle l’agent agit et la raison pour laquelle cette autorité lui a été accordée.
Réduire les privilèges avant d’analyser le comportement
Après avoir défini l’identité de l’agent, il convient de limiter ses capacités dans le temps et en fonction de la tâche, des outils et des ressources nécessaires à celle-ci. La source indique qu’il est possible de s’appuyer sur des fonctions déjà présentes dans les systèmes de gestion des identités et des accès (IAM), telles que l’identité de charge de travail, l’échange de jetons, l’accès conditionnel et les habilitations limitées dans le temps.
Kale cite une étude de Teleport menée en 2026 auprès de 205 responsables de la sécurité : les organisations utilisant une intelligence artificielle excessivement privilégiée ont déclaré un taux d’incidents de 76 %, contre 17 % pour les organisations appliquant le principe du moindre privilège. Selon son analyse, cela indique que l’étendue des accès pourrait être un facteur plus en amont dans la chaîne de confiance que l’application de politiques d’exécution sensibles au contexte.
Le principe avancé par l’auteur est celui de la « délégation monotone » : chaque transfert de responsabilité doit maintenir ou réduire l’autorité, et ne doit jamais l’augmenter. Dans l’exemple d’un agent de rapprochement financier, cela signifie lui accorder l’autorisation de consulter un grand livre déterminé, plutôt que de lui transmettre tous les systèmes auxquels l’employé à l’origine de la demande peut accéder.
Quand la passerelle devient-elle réellement utile ?
La passerelle d’exécution n’acquiert sa pleine valeur qu’une fois disponibles une identité enregistrée pour l’agent, un contexte de délégation explicite, des identifiants spécifiques et des journaux traçables. Elle peut alors évaluer si l’agent est autorisé à exécuter une action donnée, pour le compte d’une entité précise, dans le cadre d’une tâche déterminée et sur une ressource donnée. Le jeton utilisateur peut être valide pour accorder à l’agent de rapprochement une autorisation d’écriture, mais le contexte complet peut montrer que l’action sort du périmètre de la tâche.
Les contrôles les plus stricts doivent être dirigés vers les limites dont les effets sont difficiles à inverser, telles que les paiements, les modifications des politiques d’accès, les suppressions, les changements de l’environnement de production et l’exportation de données. Les références comportementales viennent ensuite, une fois que les activités de l’agent sont devenues distinguables et attribuables ; il est alors possible de détecter une utilisation inhabituelle des outils, un accès inattendu entre les périmètres de données ou un écart par rapport à la tâche.
Le mécanisme d’arrêt ne se limite pas à désactiver un seul objet dans l’annuaire d’identités. L’arrêt complet, tel que le décrit la source, exige de désactiver l’identité de l’agent, de révoquer les identifiants actifs et dérivés, d’empêcher l’exécution des outils, de terminer les tâches en cours et d’isoler la charge de travail qui contient l’agent.
Plan de test sur 30 jours
L’auteur ne propose pas de remplacer le programme de gestion des identités existant. Si le fournisseur d’identité ne traite pas les agents comme des types d’actifs natifs, il est possible de commencer par un registre fiable associé aux identités de charges de travail existantes, puis d’ajouter les identifiants de l’agent et de la tâche comme contextes d’exécution fiables, d’utiliser des identifiants à court terme et d’inclure ces identifiants dans les journaux des appels d’outils.
Concrètement, il propose de commencer par dix agents de production et de documenter pour chacun son propriétaire, sa finalité, ses outils et ses identifiants. Il faut ensuite vérifier si les systèmes de gestion des identités et les journaux distinguent l’agent de l’humain ou du service ayant délégué la tâche, puis reconstituer une tâche complète de bout en bout, y compris ses effets ultérieurs. L’endroit où la chaîne s’interrompt révèle la lacune à traiter avant d’ajouter une nouvelle mesure d’application opérationnelle.
Lecture éditoriale : la valeur de ce cadre ne réside pas dans la proposition d’une nouvelle passerelle, mais dans la réorganisation du point de départ. Les faits mentionnés concernant LiteLLM, ainsi que les chiffres de Teleport et d’Okta, étayent l’importance de la réduction des privilèges et de l’attribution, mais ne prouvent pas à eux seuls que l’ordre des couches proposé constitue la seule solution ou qu’il convient à toutes les architectures d’entreprise. En outre, le contenu est une analyse de l’auteur et non une norme officielle ; son application nécessite donc un examen des détails des systèmes d’identité, de journalisation et des mécanismes d’arrêt existants dans chaque organisation.