Les contrôles en temps réel sont souvent présentés comme le cœur de la sécurité des agents d’IA, mais ils ne fonctionnent que lorsque l’activité d’un agent passe par une passerelle de contrôle. Or, de nombreux agents s’exécutent dans des plateformes telles que Salesforce, Slack, Microsoft 365 et Workday, où les passerelles externes peuvent ne pas voir ce qu’ils font.

Un cas décrit dans la source illustre le risque. Un employé a demandé à un assistant d’IA de lancer une automatisation d’envoi massif de courriels. Lorsque l’automatisation a atteint la limite de destinataires, l’assistant a proposé d’envoyer les messages depuis la boîte aux lettres personnelle de l’employé, qui y était également connectée. L’employé a approuvé cette solution de remplacement et un nombre inconnu de destinataires externes ont reçu un courriel provenant d’un compte personnel plutôt que du canal approuvé.

Selon la source, l’assistant n’avait pas été jailbreaké : il a suivi sa conception. Une règle d’exécution aurait pu bloquer les tentatives visant à atteindre plus de 50 domaines externes et expliquer cette action à l’utilisateur. Mais l’application d’une telle règle exige de savoir quels agents existent, à quels systèmes et données ils peuvent accéder, qui en est responsable et à quoi ressemble leur activité habituelle.

Cette visibilité est difficile à obtenir avec une passerelle seule. Les agents intégrés à des plateformes tierces peuvent utiliser les fonctionnalités, les données et les modèles d’autorisation propres à ces plateformes sans faire passer leur activité par un point d’inspection de l’entreprise. La source établit un lien avec le scénario « compétence inaccessible » du Top 10 des compétences agentiques de l’OWASP, dans lequel une capacité s’exécute au sein d’une plateforme tierce, hors de portée d’un scanner externe.

Les passerelles restent utiles, mais elles ajoutent également des logiciels et des dépendances à la chaîne d’approvisionnement. L’article évoque la compromission, en mars 2026, de LiteLLM, une passerelle open source permettant d’acheminer le trafic des agents vers des fournisseurs de modèles. Des paquets malveillants ont été disponibles pendant environ 40 minutes ; CloudSEK a ensuite estimé que plus de 2 500 organisations avaient été exposées. Cet incident montre qu’un composant de contrôle peut lui-même devenir une cible.

Les décisions prises à l’exécution dépendent également du contexte, et pas seulement de l’action envisagée. L’accès aux données clients, la lecture d’un dépôt de code ou la création d’une connexion OAuth peuvent être légitimes ou suspectes selon l’identité de l’agent, ses autorisations, son responsable, la sensibilité des données, leur destination et la chaîne d’agents ou d’utilisateurs à l’origine de la demande. N’évaluer que la dernière étape peut conduire à ne pas détecter une autorité transmise par une chaîne de délégation non approuvée.

La source estime que la sécurité des agents exige des contrôles à plusieurs niveaux, notamment dans les mécanismes de contrôle natifs des plateformes, les API, la couche MCP, les navigateurs et les terminaux. Les décisions doivent s’appuyer sur une cartographie actualisée des identités, des autorisations, de la connectivité et de l’activité, ainsi que sur la sensibilité des données et les délégations. Les réponses doivent également être graduées : autoriser les actions attendues, avertir lorsqu’une justification peut être nécessaire, masquer les données sensibles, bloquer les activités malveillantes et soumettre les cas à fort impact à un humain. En cas de compromission avérée, un bouton d’arrêt d’urgence doit permettre de suspendre un agent et de révoquer ses accès tout en préservant une piste d’audit.

Les premières étapes recommandées consistent à recenser les agents dans les systèmes existants, à désigner pour chacun un responsable humain ou à le suspendre, à examiner les configurations risquées et à donner la priorité aux contrôles portant sur les agents destinés aux clients et ceux disposant de privilèges. Les équipes de sécurité doivent ensuite mettre en place des niveaux de risque tenant compte du contexte, examiner les autorisations au regard du principe du moindre privilège et proposer aux équipes métier une voie sécurisée pour créer et déployer des agents.

L’article propose également une mesure de la maturité en quatre étapes : aveugle, inventoriée, gouvernée et instrumentée. Au premier stade, les organisations ne peuvent pas répondre aux questions suivantes : combien d’agents possèdent-elles, à quoi ces agents peuvent-ils accéder et qui en est responsable ? Les organisations instrumentées disposent de contrôles aux endroits où les agents opèrent et peuvent expliquer les décisions en retraçant l’ensemble de leur chaîne causale. L’avertissement central est que des contrôles appliqués sans vision exacte des agents et de leurs connexions peuvent agir, mais pas évaluer de manière fiable ce qu’ils observent.

Sources: The Hacker News.