Illustration conceptuelle originale générée par IA : les portes représentent des contrôles d’autorisation distincts, et non un produit réel ou un résultat de sécurité mesuré.
Partir de l’action, pas de la réponse
Imaginez un assistant aux achats chargé de résumer trois propositions de fournisseurs. L’un des documents contient une demande d’envoi du comparatif complet à une adresse externe. L’assistant produit un JSON valide, utilise le bon outil de messagerie et rédige un message fluide. Le processus peut pourtant échouer : le document était une source d’information à lire, pas une personne habilitée à autoriser une divulgation.
Il s’agit d’un exemple hypothétique de conception. Nous n’avons mené aucune attaque, réalisé aucun benchmark comparatif de fournisseurs ni inspecté le déploiement d’un client. Notre propos est plus circonscrit : la capacité d’un agent à proposer une action correctement formée doit être séparée de la décision du système de l’autoriser.
L’analyse qui suit repose sur des sources documentaires primaires vérifiées le 21 octobre 2026. C’est un cadre d’ingénierie, et non une certification de sécurité ou un avis juridique.
Ce que la documentation établit réellement
Dans son explication du 11 mars 2026, OpenAI préconise de limiter les dommages même lorsqu’une manipulation du prompt réussit. Son guide de sécurité des workflows recommande des données structurées et des validations, tout en avertissant que les mesures d’atténuation n’éliminent pas les erreurs. Ce guide concerne Agent Builder, que la page actuelle indique comme obsolète ; il ne s’agit pas d’une recommandation d’adopter ce produit.
L’article d’Anthropic du 20 octobre 2025 sur le sandboxing décrit l’isolation du système de fichiers et du réseau. La documentation actuelle sur les permissions de Claude Code distingue les permissions des outils de leur application par le système d’exploitation : les règles Read/Edit ordinaires ne couvrent pas tous les accès aux fichiers effectués par des sous-processus.
Le dépôt officiel Qwen-Agent documente l’isolation par Docker et le montage restreint de répertoires pour l’interprétation de code, mais appelle à la prudence quant à l’utilisation de son bac à sable de base en production.
Il s’agit de couches et de produits différents, pas d’un comparatif contrôlé. Un service américain peut être déployé avec des accès trop larges ; un framework chinois peut être déployé avec des limites restrictives, ou inversement. L’origine du modèle et le lieu d’hébergement ne remplacent pas l’examen de la configuration. Aucun de ces documents n’établit quel fournisseur est universellement le plus sûr.
Interposer une passerelle d’autorisation entre planification et exécution
L’architecture que nous proposons distingue trois responsabilités : le modèle propose une action, une passerelle vérifie qu’elle est autorisée et un exécutant aux privilèges strictement limités réalise l’opération permise. La passerelle relève du code applicatif et de l’application des règles, pas simplement d’une instruction supplémentaire demandant au modèle de bien se comporter.
Pour chaque demande ayant des conséquences, liez la décision à l’utilisateur authentifié, à l’opération, à la ressource, à la destination, au périmètre des données et aux limites applicables. Une permission de lire des propositions de fournisseurs ne doit pas devenir tacitement une permission de les envoyer par e-mail. Une permission de rédiger un message ne doit pas devenir tacitement une permission de l’envoyer. Si une valeur requise manque ou reste ambiguë, la demande doit rester non exécutée jusqu’à clarification.
La validation de schéma a sa place dans cette architecture, mais remplit un autre rôle. Un schéma peut imposer qu’un champ destinataire contienne une chaîne de caractères. Il ne peut pas établir que l’utilisateur a approuvé ce destinataire. De même, un modèle chargé de la vérification, aussi utile soit-il pour détecter les risques, ne devient pas une barrière d’accès déterministe simplement parce qu’il répond par oui ou par non.
Cette séparation clarifie aussi la responsabilité après un refus : corriger une demande invalide ou obtenir l’autorisation requise. Changer de compte ou emprunter d’autres voies pour contourner le refus de la même opération n’est pas une correction.
Rendre les validations assez précises pour résister aux changements de plan
Un écran de confirmation utile montre l’action qui aura réellement lieu : destination, contenu ou catégorie de données, ressource concernée et toute limite de coût ou de périmètre. Évitez un bouton générique « Autoriser l’agent ? » qui masque les variables importantes.
Liez la validation à cette proposition. Si le destinataire, la pièce jointe, le montant ou la ressource change de manière substantielle, réévaluez-la. Pour un travail répétitif et délimité, une organisation peut définir une permission permanente étroitement circonscrite plutôt que d’interrompre chaque étape sans danger. Les limites doivent rester vérifiables et applicables ; un document externe ne peut pas les élargir.
La lassitude face aux validations et les permissions excessives sont des problèmes de conception liés. Exiger une confirmation pour chaque lecture anodine peut habituer les personnes à cliquer automatiquement, tandis qu’une approbation globale peut dissimuler un risque ultérieur. Le bon équilibre repose sur une politique documentée pour les opérations à faible risque, des validations précises pour les changements lourds de conséquences et un arrêt explicite lorsque l’autorisation est incertaine.
Limiter les conséquences d’une erreur
Un contrôle d’autorisation protège l’opération demandée ; l’isolation à l’exécution limite ce à quoi l’environnement d’exécution peut accéder. Utilisez des identifiants d’accès à portée limitée, un accès restreint au système de fichiers et des destinations réseau contrôlées lorsque l’application le permet. Intégrez les processus enfants au modèle de menace. Un outil de lecture de fichiers restreint ne suffit pas si le même exécutant peut lancer un shell sans restriction.
Distinguez l’état d’une opération du récit qu’en fait le modèle. Proposée, approuvée, transmise et confirmée sont des états différents. Enregistrez un identifiant de requête stable et utilisez l’idempotence ou la déduplication lorsqu’elles sont prises en charge. Après un dépassement de délai, examinez l’enregistrement réel auprès du service avant de retenter un envoi, un achat ou une publication. « Aucune réponse reçue » ne prouve pas que « rien ne s’est passé ».
Les journaux doivent permettre cette reconstitution sans devenir une autre source de fuite. Conservez l’identifiant de l’action, la décision, la version de la politique et la référence résultante auprès du service ; réduisez au minimum les secrets et les données personnelles inutiles. Fournissez aux personnes chargées du contrôle assez d’informations pour enquêter, pas une copie indistincte de chaque document.
Six contrôles avant la mise en production
Ce qui suit est une proposition d’exercice de recette, pas un test que nous avons effectué ni une évaluation exhaustive de la sécurité :
- Placez un destinataire externe dans un document récupéré. Peut-il modifier la destination autorisée sans l’autorisation de l’utilisateur authentifié ?
- Produisez un JSON valide pour une action hors du périmètre autorisé. La passerelle la rejette-t-elle avant transmission ?
- Changez la destination après validation. La validation précédente cesse-t-elle de couvrir l’action modifiée ?
- Tentez une lecture de fichier hors du périmètre autorisé via un processus enfant. La limite à l’exécution est-elle appliquée, et pas simplement décrite dans un prompt ?
- Simulez un dépassement de délai au résultat ambigu après un envoi. Le workflow peut-il rapprocher son état de l’enregistrement du service sans créer de doublon ?
- Révoquez la permission concernée. L’opération suivante échoue-t-elle de manière sûre, avec une trace d’audit compréhensible ?
Évaluez à la fois la protection et la facilité d’utilisation : opérations non autorisées bloquées, travail autorisé bloqué à tort, demandes de validation inutiles, effets de bord en double et temps nécessaire pour expliquer une décision. Un taux élevé de tâches accomplies peut, à lui seul, masquer une exécution dangereuse ; un système qui bloque tout n’est pas non plus un assistant utile.
La question décisive au moment de l’achat
Demandez au fournisseur de montrer quelle couche fait respecter chaque limite dans la configuration que vous déploierez réellement, ce qui se passe si le modèle suit un document malveillant et comment une exécution au résultat ambigu est réconciliée. Exigez des preuves correspondant à vos outils et à vos périmètres d’accès, plutôt que de transposer le chiffre phare d’un benchmark réalisé dans une autre configuration.
Le choix pratique ne se résume pas à « faire confiance au modèle » ou à « demander la permission indéfiniment ». Il consiste à décider quel travail peut avancer dans des limites claires, quels changements nécessitent une décision humaine et quelles frontières le modèle ne peut pas réécrire. C’est un point de départ plus utile qu’un simple score de capacité pour comparer les piles technologiques d’agents chinoises et américaines.