Les agents IA qui réussissent l’authentification peuvent toujours dériver, exposer des données ou être empoisonnés en mémoire

Il existe une tendance claire et récurrente dans les déploiements d’agents : la passerelle est la première cible que les équipes de contrôle recherchent, mais c’est celle qu’elles sont le moins prêtes à exécuter. En effet, les passerelles se situent au-dessus des couches d’identité et d’attribution qui n’existent pour la plupart pas.

Le premier niveau de risque n’est pas hypothétique. En juin, CISA a ajouté une faille LiteLLM à son catalogue de vulnérabilités exploitées connues après que des attaquants ont été surpris en train d’en abuser dans la nature. Le bogue exécutait des commandes sur l’hôte via la passerelle elle-même et, enchaîné avec une deuxième faille, il ne nécessitait aucune information d’identification. Il s’agissait de l’une des sept vulnérabilités et expositions courantes (CVE) divulguées dans cette seule passerelle d’IA en un mois. C’est la couche vers laquelle de nombreuses entreprises se tournent en premier pour sécuriser leurs agents IA.

Lorsque l’on envisage une architecture d’agent sécurisée, les contrôles de passerelle ne doivent pas être le premier contrôle. Ils devraient être le cinquième.

La plupart des modèles sur la maturité de la sécurité des agents décrivent les contrôles dont une entreprise aura besoin à l’avenir. D’après mon expérience, ils ont tendance à passer à côté du problème plus difficile de la description du scénario des friches industrielles : dans quel ordre ces contrôles devraient-ils être superposés en conjonction avec un système de gestion des identités et des accès déjà en place ?

Si le plan de contrôle ne sait pas quel agent agit, qui a délégué le travail, quelle tâche l’agent doit effectuer et quelles informations d’identification sont utilisées, alors le contexte est incomplet. Une passerelle peut bloquer des violations claires de politiques, mais elle aura du mal à distinguer une action justifiée d’une action techniquement autorisée mais opérationnellement inappropriée.

Le schéma d’échec est clair lors du séquençage de ces contrôles pour les déploiements de production d’agents : l’application est prise tôt, alors que le contexte d’identité et d’attribution dont elle dépend n’a pas encore été développé. La sécurité des agents fonctionne comme une chaîne de dépendances, chaque contrôle dépendant du contexte généré en amont.

Le mauvais point de départ

Pensez au trafic des agents de routage via une nouvelle passerelle d’exécution. Un agent de rapprochement financier tente de modifier un enregistrement en production. La passerelle authentifie le jeton utilisateur et vérifie l’appel API. Ce qu’il ne peut pas observer, c’est que la requête est initiée par l’agent, que l’agent exécute une fonction plus limitée ou que la requête fait partie d’une chaîne d’outils invoquée par un artefact non fiable.

Le titre est valide. L’appel API est autorisé. Cette action contredit le but de la délégation. La passerelle est là, mais son ensemble de supports semble absent, de sorte qu’un contrôle coûteux est appliqué à une très petite partie de l’ensemble.

Il est utile de limiter les privilèges d’un agent à ceux du mandant humain afin que l’agent n’excède pas la personne qu’il sert. Toutefois, le fait d’avoir un plafond de privilèges ne crée pas d’attribution distincte. Vingt agents peuvent fonctionner avec les autorisations d’une seule personne et ont néanmoins besoin d’identités uniques, de journaux d’audit, de profils de comportement et de chemins de révocation.

Déploiement contrôlé par les dépendances

J’appelle ce processus le déploiement contrôlé par les dépendances. Les tests de sortie en amont doivent être satisfaits avant qu’un contrôle en aval ne soit considéré comme terminé sur le plan opérationnel. Le développement simultané de contrôles en aval est autorisé.

Voici les six portes et la preuve qu’elles fonctionnent :

Les six portes de dépendance pour les contrôles de sécurité des agents. Chaque contrôle est contextualisé par les portes situées au-dessus. D’après l’analyse de l’auteur sur les déploiements d’agents de production.

Commencez par les agents que vous pouvez réellement nommer

Pour commencer, reconnaissez les agents de production dans les frameworks open source, les offres cloud, les services SaaS et les outils de développement. Pour chacun, enregistrez le propriétaire, la responsabilité, l’étape du cycle de vie, les outils autorisés, les domaines de données et les sources d’informations d’identification.

Si vous contournez cette étape, l’organisation perdra la première heure de réponse aux incidents le temps de déterminer ce qui aurait dû être évident. L’inventaire identifie l’actif que régit par la suite chaque contrôle.

Un agent a besoin de sa propre identité, mais il ne peut pas perdre l’humain qui se cache derrière lui.

Un agent ne doit pas être enfoui dans un jeton de développeur, un compte de service partagé ou une session humaine. Il ne suffit pas de savoir simplement que l’appelant est un agent. Le plan de contrôle nécessite un contexte de délégation supplémentaire : qui a délégué le travail, quelle tâche spécifique l’agent a été chargé d’exécuter et à quelles ressources l’agent a besoin de l’autorité pour accéder. L’identité précise quel acteur a passé l’appel. La délégation est la réponse à l’autorité de qui elle agit et pour quelle raison.

Une fois cette connexion coupée, les journaux en aval attribuent l’agent de rapprochement à l’employé dont il a emprunté le token, et chaque action entreprise est attribuée à quelqu’un qui ne l’a pas démarré.

Réduisez l’autorité avant d’inspecter le comportement

Une fois qu’un agent peut être identifié, ses capacités doivent être limitées. Les restrictions d’accès doivent être limitées dans le temps à la tâche et limitées aux outils et aux ressources nécessaires à l’exécution de la tâche. Cela peut être mis en œuvre à l’aide de fonctionnalités de gestion des accès aux identités (IAM) telles que l’identité de la charge de travail, l’échange de jetons, l’accès conditionnel et les droits limités dans le temps que l’organisation possède déjà.

En ce qui concerne le Étude de téléportation 2026 impliquant 205 responsables de la sécurité, la portée de l’accès dépasse la capacité prédictive du secteur, la maturité ou l’assurance en matière de prévision des incidents liés à l’IA. Par exemple, les organisations disposant de privilèges excessifs en matière d’IA ont signalé un taux d’incidents de 76 %, alors que les incidents d’IA se sont produits dans 17 % des organisations les moins privilégiées. Cela indique que la portée de l’accès dans la chaîne de dépendances est plus importante que l’application de l’exécution contextuelle.

Le principe premier est la délégation monotone. Tout transfert de responsabilité doit préserver ou diminuer l’autorité ; en aucun cas, cela ne doit accroître l’autorité. Pour l’agent de rapprochement, cela signifie un agent qui peut consulter un grand livre plutôt qu’un agent qui hérite de l’accès de l’employé à tous les systèmes auxquels l’employé peut accéder.

Corrigez l’attribution avant d’automatiser l’application

La plupart des piles d’audit peuvent capturer quelle ressource a été accédée et quels informations d’identification ont autorisé l’accès. Dans les déploiements d’agents que j’ai examinés, il s’agit de la porte la plus souvent manquée. Avant d’utiliser une stratégie d’exécution adaptative, associez tout appel d’outil pertinent à l’identité de l’agent, au principal initiateur, à l’ID de tâche, à l’action parent et au résultat. Après cela, examinez la télémétrie : pour une tâche terminée, voyez si vous pouvez retrouver l’initiateur, l’agent qui l’a exécutée, l’autorité sous laquelle l’action a été entreprise, les outils utilisés et le résultat. Dans des environnements réglementés, une surveillance qui n’est pas attribuée ne peut être justifiée.

Maintenant, la passerelle gagne sa place

La passerelle peut utiliser des identités enregistrées, une délégation explicite, des informations d’identification étendues et une télémétrie attribuable pour se demander si cet agent est autorisé à effectuer cette action, pour ce principal, dans le cadre de cette tâche, impliquant cette ressource. Bien que les informations d’identification de l’utilisateur puissent fournir un accès en écriture à l’agent de rapprochement financier, la passerelle a un contexte situationnel et détermine donc qu’il est hors de portée. C’est le point le plus précieux du contrôle. Les contrôles les plus stricts doivent être appliqués aux limites irréversibles : paiements, changements de politique d’accès, suppressions, modifications de l’environnement de production et exportations de données.

La détection et le kill path viennent en dernier

Les lignes de base comportementales sont élaborées en dernier lieu, car une activité d’agent distincte et attribuable doit être établie pour établir une norme. Les équipes de sécurité sont ensuite en mesure d’identifier les modèles anormaux d’utilisation des outils, les accès inter-domaines inattendus et les écarts par rapport aux tâches qui leur sont assignées. Le confinement ne se résume pas à la simple désactivation d’un seul objet d’annuaire : un chemin d’arrêt approprié implique la désactivation de l’identité de l’agent, l’invalidation des informations d’identification actives et dérivées, le blocage de l’activation de l’outil, l’arrêt des tâches actives et l’isolement de la charge de travail qui contient l’agent.

Commencez sans remplacer votre IAM

Concevoir un tout nouveau programme d’identité n’est pas nécessaire. Si le fournisseur d’identité existant ne traite pas les agents comme des types d’objets natifs, commencez par un registre faisant autorité lié aux identités de charge de travail existantes. Ensuite, étendez les identifiants d’agent et de tâche en tant que contextes d’exécution fiables, implémentez des informations d’identification de courte durée pour atténuer les privilèges hérités et incluez ces identifiants dans les journaux d’appels d’outils pour l’ingestion ultérieure de la passerelle. Le modèle de dépendance reste inchangé à mesure que le support des fournisseurs évolue.

Les écarts de contrôle sont mesurables. Dans Enquête Okta 2026seuls 34 % des dirigeants déclarent que leur organisation applique toujours le même niveau de rigueur en matière de sécurité à sa main-d’œuvre agente qu’à sa main-d’œuvre humaine. Le dernier contrôle de la chaîne ne peut pas être appliqué en premier pour combler cet écart.

Que faire dans les 30 prochains jours

Commencez avec 10 agents de production. Pour chacun, identifiez le propriétaire, l’objectif, les outils approuvés et les informations d’identification. À présent, vous devriez avoir les débuts d’un registre d’agents et peut-être vos premières idées sur la gouvernance.

Attribution des tests. Découvrez si l’IAM et la journalisation peuvent distinguer chaque agent de l’humain ou du service qui a délégué la tâche. Si ce type de différenciation n’était pas possible, une passerelle fonctionnerait sans aucune visibilité.

Reconstruisez une tâche d’agent terminée au sein d’une chaîne d’action, du début à la fin, y compris les effets en aval. Là où la chaîne se brise, c’est là que votre déploiement échoue.

L’ajout d’une application en aval avant le contexte requis brise la sécurité de l’agent. Les modèles de maturité décrivent la destination. Un ordre de construction vous y amène sans interrompre la production en cours de route.

Nik Kale est un ingénieur principal spécialisé dans les plates-formes d’IA d’entreprise et la sécurité.

Bienvenue dans la communauté VentureBeat !

Notre programme de publication d’invités est l’endroit où des experts techniques partagent leurs idées et fournissent des analyses approfondies neutres et non acquises sur l’IA, l’infrastructure de données, la cybersécurité et d’autres technologies de pointe qui façonnent l’avenir de l’entreprise.

En savoir plus de notre programme de publications d’invités – et consultez notre lignes directrices si vous souhaitez contribuer à votre propre article !