Sécurité des agents IA : isoler leurs outils d’exécution
Découvrez comment un sas d’exécution peut limiter les risques des agents IA : architecture, latence annoncée, limites techniques et critères de déploiement.
Agents IA : sécuriser l'exécution sans leur faire confiance aveuglément
Un agent IA capable de lancer des commandes, d'interroger une base de données ou d'appeler des services web n'est plus un simple assistant conversationnel. Il peut agir sur des systèmes réels, parfois avec les droits de la personne qui l'utilise. Et là, le problème change de nature : une consigne mal comprise, une page web piégée ou un outil trop permissif peut transformer une erreur « de génération » en incident opérationnel.
Les garde-fous intégrés au prompt restent utiles. Mais ils ne suffisent pas. Pour réduire le risque, il faut aussi contrôler ce que l'agent a le droit de faire, où il l'exécute et avec quelles données. Une approche pratique consiste à mettre un sas entre l'agent et ses outils : inspection des requêtes, permissions limitées, exécution isolée et arrêt rapide si quelque chose dévie.
Dans cet article, on détaille ce que cette architecture apporte, ce que recouvrent les promesses de sandbox éphémère et de latence annoncée à 0,12 ms, et surtout comment évaluer une solution avant de la brancher dans un environnement pro. L'objectif n'est pas de rendre un agent « inoffensif par principe », mais de limiter concrètement ce qu'il peut faire.
Pourquoi les garde-fous dans le prompt ne suffisent pas
Dire à un agent « ne divulgue pas de secrets » agit sur ce qu'il essaie de faire. Ça ne lui retire pas, pour autant, les permissions techniques que vous lui avez données. Si l'agent peut lire des fichiers, exécuter un interpréteur de commandes ou envoyer des requêtes réseau, alors le système doit pouvoir refuser l'action dangereuse, même si le modèle en fait la demande.
C'est exactement le point : intention et capacité ne se recouvrent pas. Un agent peut produire une réponse correcte, puis déclencher un appel d'outil risqué. Et il peut aussi être « influencé » par des instructions qui viennent de l'extérieur : une page consultée, un document partagé, un ticket client, des résultats de recherche. Le contenu malveillant n'a pas besoin de se présenter comme une consigne évidente. Il suffit qu'il transforme le contexte de décision.
Les chemins d'attaque passent par les entrées et les outils
Les attaques peuvent jouer avec des séparateurs qui imitent des balises système, des caractères Unicode invisibles, ou des instructions « cachées » dans un document récupéré. Ces techniques ne garantissent pas que le modèle obéira, mais elles montrent un problème plus large : dès que l'agent agrège plusieurs sources, la frontière entre données et instructions devient fragile.
Le risque augmente encore quand l'agent dispose d'outils qui peuvent produire des effets externes. Lire une clé privée, transmettre une variable d'environnement, installer un composant persistant ou lancer une rafale de processus ne ressemble pas à une « erreur de formulation ». Ce sont des opérations système dont l'impact dépend directement des droits accordés et des contrôles réellement en place.
La défense doit exister à plusieurs niveaux
Les garde-fous côté prompt sont un bon point de départ : ils orientent le modèle et réduisent certains comportements indésirables. Mais il faut les compléter avec des contrôles indépendants : authentification, autorisations minimales, filtrage des arguments, limitation réseau, journalisation et isolation du processus.
Et surtout : ne demandez pas au modèle de décider seul si une action est « sûre ». La politique d'accès doit être définie en dehors du modèle, puis appliquée au moment où l'action est exécutée. Même si l'agent contourne le texte de consigne, il doit encore se heurter à une frontière technique qui bloque l'opération.
Comment vérifier les performances et les garanties
Une démo « qui marche » ne prouve pas, à elle seule, que votre environnement restera protégé. Il faut tester les scénarios dangereux, mesurer les coûts opérationnels et regarder les garanties techniques, de façon précise. En clair : la vraie question n'est pas seulement « bloque-t-il cette commande ? ». C'est « qu'est-ce qu'il peut réellement empêcher, dans quelles conditions, et que se passe-t-il si le contrôle échoue ? »
Définir le périmètre avant de mesurer
Commencez par lister les outils accessibles à l'agent : commandes, fichiers, bases de données, services internes, connexions sortantes. Pour chacun, documentez les permissions nécessaires et les effets possibles. Un agent de support qui lit une base en lecture seule n'a pas du tout le même profil de risque qu'un agent de développement capable de modifier du code et de déployer une version.
Ensuite, mesurez la latence à plusieurs endroits : contrôle de la requête, démarrage de l'environnement, exécution de l'outil, puis durée totale perçue par l'utilisateur. Une inspection annoncée à 0,12 ms ne veut pas dire que l'appel complet finira dans ce délai. Faites des tests sous charge, avec des requêtes représentatives, et regardez des percentiles plutôt qu'une moyenne « sur un coup ».
Tester les échecs, pas seulement les cas prévus
Préparez une batterie de scénarios basée sur votre réalité : tentative de lecture d'un fichier sensible, envoi d'une donnée vers un domaine non autorisé, création de processus en boucle, commande mal formée, et interruption d'un appel d'outil. Vérifiez aussi ce qui se passe quand la passerelle est indisponible, quand une règle est ambiguë ou quand une dépendance échoue.
Pour chaque test, notez quatre choses : l'action a-t-elle été bloquée, l'événement a-t-il été journalisé correctement, l'agent a-t-il pu continuer par un autre chemin, et l'équipe peut-elle comprendre l'incident ? Et si une intégration permet à l'agent d'appeler directement un outil sans passer par le sas, alors le contrôle centralisé perd une grande partie de sa valeur.
Vérifier les garanties indépendamment
Demandez la documentation de la menace couverte, les limites connues, les paramètres requis et des résultats de tests reproductibles. Regardez le code ou faites une revue indépendante si l'enjeu le justifie. Vérifiez notamment la gestion des clés, les règles réseau, les journaux, le cycle de vie de la mémoire et les mécanismes de mise à jour.
Enfin, une sandbox ne rend pas automatiquement un traitement conforme au RGPD. Il faut préciser quelles données personnelles sont transmises, sur quelle base, pour quelle durée et à quels sous-traitants. La sécurité d'exécution est une brique parmi d'autres : ce n'est pas un « certificat de conformité ».
À retenir : une latence faible ne compte vraiment que si le contrôle couvre tous les chemins d'exécution, si les refus sont testés, et si les limites sont documentées.
Dans quels cas cette approche est-elle utile
Un sas devient particulièrement pertinent quand l'agent agit au-delà de la conversation : automatiser un support, manipuler des dépôts de code, consulter des dossiers internes ou lancer des tâches dans une infrastructure. Dans une entreprise française, un prototype qui résume des documents publics n'a pas le même niveau de risque qu'un outil connecté à des données clients, à un CRM ou à des systèmes financiers.
Commencer par les actions à fort impact
Priorisez les actions avec deux critères : l'étendue des droits et la difficulté d'annuler les effets. Lire des données sensibles peut suffire à déclencher un incident, même sans modification. Une opération d'écriture ou un accès réseau élargit encore le risque. Concentrez d'abord vos contrôles sur ce qui peut divulguer des informations, modifier des ressources ou déclencher des dépenses.
Pour un agent interne, ça peut vouloir dire : accès en lecture seule par défaut, liste de commandes autorisées, répertoires explicitement accessibles et destinations réseau limitées. Une demande de suppression ou de transfert important peut nécessiter une validation humaine. Ce sont des mesures moins « spectaculaires » qu'un arrêt ultrarapide, mais elles réduisent directement les conséquences possibles.
Comparer le coût de contrôle au coût d'incident
L'isolation a un prix : configuration Linux, gestion des politiques, supervision, compatibilité avec les outils existants, et traitement des faux positifs. Trop strict, et vous bloquez des tâches légitimes, ce qui dégrade l'expérience. Trop permissif, et vous créez une illusion de sécurité « facile à croire » parce que tout semble cadré.
La bonne décision dépend donc du profil de l'agent et du coût d'une erreur. Pour un assistant sans accès externe, des autorisations applicatives et une validation humaine peuvent suffire. Pour un agent qui exécute du code ou manipule des secrets, une isolation dédiée et une surveillance des appels sont plus défendables. Pesez le coût total : intégration, maintenance, temps de résolution des alertes, et impact sur les délais.
Déployer progressivement et garder une sortie de secours
Commencez en mode observation si c'est possible : collectez les appels, identifiez les usages légitimes et ajustez les règles avant de bloquer en production. Passez ensuite à une expérimentation limitée, avec des utilisateurs et des données non critiques. Suivez des indicateurs simples : taux de blocage confirmé, faux positifs, latence ajoutée, incidents évités, et temps nécessaire pour diagnostiquer une alerte.
Préparez aussi un mode dégradé. Si le sas est indisponible, le choix le plus sûr consiste souvent à refuser les actions sensibles plutôt que d'autoriser l'agent à accéder directement aux outils. Oui, ça peut casser un flux métier : c'est justement pour ça que ça doit être décidé et documenté en amont, pas découvert au milieu d'un incident.
Conclusion : contrôler les actions, pas seulement les réponses
Les agents « autonomes » introduisent un risque particulier : une réponse imparfaite peut se transformer en action sur un fichier, une base de données ou un service distant. Les consignes de sécurité restent nécessaires, mais elles ne remplacent ni les permissions minimales, ni un contrôle placé au point d'exécution.
Un sas avec inspection, exécution isolée et arrêt d'urgence peut réduire la surface d'attaque. À condition que tous les appels passent effectivement par lui, et que ses garanties soient testées. Les chiffres de latence et les promesses de non-persistance doivent être vérifiés chez vous, pas acceptés comme des propriétés universelles.
Avant d'intégrer un agent dans un processus métier, identifiez ses capacités, limitez ses droits, et testez le comportement quand une action est refusée... ou quand le contrôle est contourné. La sécurité utile n'est pas un produit miracle : c'est une architecture où chaque action risquée rencontre une règle vérifiable.
Comment fonctionne un sas d'exécution pour agents IA
Un sas d'exécution se place entre l'agent et les outils qu'il peut appeler. Concrètement, l'agent soumet une requête, et le sas vérifie : qui demande, ce que l'agent est autorisé à faire, puis si l'action doit être autorisée, refusée, ou exécutée dans un environnement restreint. L'intérêt, c'est de centraliser les règles au lieu de les dupliquer dans chaque agent ou dans chaque intégration.
Dans l'architecture présentée par Iris Computing, la passerelle agit comme superviseur compatible avec le protocole MCP. Le système prévoit deux voies : une action jugée suspecte déclenche un arrêt du processus et une trace cryptographique ; une action autorisée s'exécute dans un espace mémoire éphémère, avec des limites de ressources et des mécanismes d'interception.
Inspection rapide et contrat de capacités
Avant toute exécution, on vérifie ce que l'agent a le droit de faire, puis on examine l'appel d'outil et son contexte. Un contrat de capacités signé (par exemple avec Ed25519) peut servir à authentifier une politique ou une autorisation. Ce n'est pas une preuve que la commande est « safe » en soi : ça garantit plutôt que la décision s'appuie sur une règle identifiée et non modifiée.
Le fournisseur annonce un moteur de contrôle « Tier-0 » avec une latence de 0,12 ms. Cette valeur doit être lue comme une mesure revendiquée pour une étape précise, dans un contexte précis. Le coût réel dépendra du matériel, du contenu analysé, de la charge, du chemin réseau et de la définition exacte du point de mesure.
Environnement éphémère et arrêt d'urgence
L'exécution dans un descripteur mémoire Linux créé avec
memfd_createvise à éviter d'écrire des exécutables ou des fichiers intermédiaires sur un système de fichiers classique. Les mécanismes de scellement peuvent limiter certaines modifications. Et des limites de mémoire, ainsi que l'interception des accès aux fichiers, réduisent la surface d'action.Mais il faut rester rigoureux : « pas de fichier persistant dans le répertoire de travail » n'est pas la même chose que « aucune donnée ne touche jamais un stockage ». Le comportement réel dépend de la configuration de l'échange mémoire, des journaux, des outils appelés et des sorties réseau. Si on vous promet une absence totale de persistance, ça doit être validé sur la configuration réellement déployée.
Le mécanisme d'arrêt peut envoyer un signal de terminaison, purger l'environnement et enregistrer l'événement. C'est utile pour interrompre vite une action suspecte, mais ça n'annule pas forcément un effet déjà produit ailleurs : un courriel envoyé, une donnée transmise ou une modification distante peut exiger une procédure de remédiation à part.
Canaris cryptographiques : détecter sans confondre
Les identifiants leurres peuvent être placés dans un environnement de test ou dans un contexte contrôlé. Si un agent tente de les transmettre, l'événement devient un signal d'alerte. Cette technique peut aider à détecter certaines tentatives d'exfiltration, mais elle ne remplace ni la protection des vrais secrets, ni la limitation stricte des accès.
Pour éviter d'inventer de nouveaux risques, ces leurres doivent être non fonctionnels, reconnaissables par l'équipe sécurité, et exclus des systèmes de production où leur présence pourrait créer des effets inattendus.