Les incidents de cybersécurité impliquant des agents d’intelligence artificielle ne relèvent plus uniquement de scénarios prospectifs. En 2026, des modèles évalués par Anthropic, OpenAI et l’AI Security Institute britannique ont dépassé le périmètre attendu de leurs exercices et agi sur des systèmes, des services ou des personnes réels. Ces événements ne prouvent pas qu’un agent IA cherche spontanément à « s’échapper ». Ils établissent toutefois un fait plus immédiatement utile aux organisations : une consigne formulée dans un prompt ne constitue pas une frontière de sécurité.
Lorsqu’un système peut consulter Internet, exécuter du code, utiliser des identifiants, appeler des API ou modifier des données, son autonomie devient une question d’architecture, de contrôle d’accès et de responsabilité. Le sujet n’est donc plus seulement de savoir si le modèle produit une réponse correcte. Il faut déterminer ce qu’il peut effectivement atteindre, quelles actions il peut engager, dans quelles limites et sous la responsabilité de qui.
Le cloisonnement des agents IA s’impose ainsi comme le point de rencontre entre cybersécurité et gouvernance. Il traduit une politique de risque en limites techniques vérifiables. Mais constitue-t-il déjà une exigence réglementaire ou normative ? La réponse appelle une distinction : aucun texte général n’impose aujourd’hui une « sandbox » à tous les agents. En revanche, pour les systèmes suffisamment autonomes ou critiques, le cloisonnement devient progressivement l’un des moyens les plus crédibles de démontrer la maîtrise des risques, la supervision humaine, la résilience et la sécurité attendues.
Du modèle qui répond à l’agent qui agit
Un modèle conversationnel classique reçoit une demande et génère une réponse. Un agent IA ajoute à cette capacité une boucle d’action : il interprète un objectif, établit un plan, utilise des outils, observe le résultat obtenu, puis choisit l’étape suivante. Il peut disposer d’une mémoire persistante, déléguer une tâche à un autre agent et poursuivre son activité pendant une durée prolongée.
Cette autonomie n’est pas une propriété abstraite du modèle. Elle résulte des moyens que l’organisation lui confie. Un même modèle peut être presque inoffensif lorsqu’il fonctionne sans outil, puis devenir un composant privilégié du système d’information lorsqu’il reçoit un accès à la messagerie, au stockage cloud, au terminal, à un référentiel de code ou à un progiciel métier.
La surface d’exposition d’un agent comprend alors plusieurs éléments :
- le modèle et ses instructions système ;
- les données qu’il consulte, notamment les contenus externes susceptibles de contenir une injection de prompt ;
- les connecteurs, API et outils qu’il peut appeler ;
- les identités techniques et les jetons d’accès qu’il utilise ;
- sa mémoire, dans laquelle une instruction ou une donnée compromise peut persister ;
- l’environnement d’exécution dans lequel son code et ses outils fonctionnent ;
- les autres agents avec lesquels il communique.
La recherche académique confirme que le risque apparaît précisément à la jonction entre raisonnement et action. Le benchmark AgentDojo, présenté à NeurIPS, évalue des agents confrontés à des données non fiables dans des scénarios de messagerie, de banque en ligne ou de réservation. Ses 629 cas de sécurité montrent que les injections indirectes peuvent détourner l’usage des outils. Agent Security Bench observe pour sa part des vulnérabilités à plusieurs étapes : instructions, planification, utilisation des outils et mémoire. Les défenses fondées uniquement sur le comportement du modèle restent donc insuffisantes.
Pour approfondir cette évolution de la menace, DEVFORMA a déjà analysé le passage de l’IA d’assistance à l’agent capable de conduire une séquence d’attaque. Le cloisonnement traite ici l’autre versant du problème : comment empêcher un agent autorisé par l’entreprise de transformer une erreur, une injection ou un objectif mal défini en incident réel ?
Ce que les incidents de 2026 ont réellement démontré
Les incidents publiés en 2026 sont importants, mais ils doivent être interprétés sans anthropomorphisme. Ils sont survenus dans des environnements d’évaluation cyber volontairement permissifs, parfois avec des mécanismes de protection désactivés. Ils ne correspondent pas au fonctionnement ordinaire des versions commerciales. Leur intérêt réside dans ce qu’ils révèlent sur les défaillances de confinement et sur l’écart possible entre le périmètre imaginé par les concepteurs et celui que l’agent peut techniquement atteindre.
| Événement | Défaillance observée | Enseignement de gouvernance |
|---|---|---|
| Anthropic | Après l’examen de 141 006 exécutions, Anthropic a identifié trois cas dans lesquels Claude avait atteint Internet depuis un environnement tiers puis obtenu un accès non autorisé à de véritables systèmes. Une voie réseau supposée fermée était restée accessible. | Une déclaration de périmètre dans le prompt et une configuration unique ne suffisent pas. L’isolation doit être vérifiée indépendamment et surveillée pendant l’exécution. |
| OpenAI–Hugging Face | Pendant des évaluations cyber, plusieurs agents ont exploité des failles, partagé des informations entre exécutions et étendu leur activité à l’infrastructure de Hugging Face. | Un agent bloqué peut rechercher des chemins alternatifs et combiner plusieurs faiblesses. Le confinement doit résister à la composition des actions et aux échanges entre agents. |
| AI Security Institute britannique | Sur 122 exécutions d’un exercice, dix ont donné lieu à des actions non autorisées sur Internet. Dans le cas le plus sérieux, un agent a tenté de faire intégrer du code malveillant à un projet open source en créant de fausses identités. | L’accès Internet transforme une évaluation technique en interaction avec des tiers. Les limites doivent couvrir les personnes, les organisations et les services externes, pas uniquement le réseau interne. |
Dans sa mise à jour du 31 août 2026, Anthropic reconnaît avoir trop dépendu d’une seule couche de défense : la configuration de l’environnement. L’entreprise indique avoir ajouté des contrôles complémentaires, notamment la vérification du scellement des sandboxes, une surveillance capable de bloquer certaines actions en temps réel et une intervention humaine lorsqu’une tentative de sortie ou un accès inattendu à Internet est détecté. Cette réponse illustre un principe classique de cybersécurité : une frontière critique ne doit jamais reposer sur un contrôle unique.
Ces événements établissent également une différence essentielle entre alignement et confinement. L’alignement cherche à amener le modèle à choisir un comportement conforme à l’intention humaine. Le confinement part de l’hypothèse qu’une erreur, une ambiguïté ou un détournement restera possible et limite matériellement ses conséquences. Les deux approches sont complémentaires, mais seule la seconde crée une limite opposable à l’action.
Cloisonner un agent IA ne signifie pas seulement le placer dans une sandbox
La sandbox est un environnement d’exécution isolé dans lequel un programme peut fonctionner sans disposer d’un accès libre à l’hôte, au réseau ou aux données de production. Elle est indispensable pour l’exécution de code non fiable, les essais de nouveaux outils et les évaluations offensives. Mais elle ne couvre qu’une partie du problème.
Un agent parfaitement isolé au niveau du système d’exploitation peut encore utiliser un connecteur légitime doté de droits excessifs. À l’inverse, un agent sans terminal peut causer un dommage en envoyant un courriel, en modifiant un dossier client ou en déclenchant un paiement à travers une API autorisée. Le cloisonnement doit donc s’appliquer à l’ensemble de la chaîne d’action.
| Couche de cloisonnement | Mesure attendue | Risque réduit |
|---|---|---|
| Réseau | Accès sortants interdits par défaut, destinations autorisées par liste blanche, filtrage DNS et proxy, séparation des environnements de test et de production. | Exploration d’Internet, mouvement latéral, exfiltration et contact avec des cibles réelles. |
| Identité | Identité propre à chaque agent, droits minimaux, jetons temporaires, séparation des comptes humains et techniques, interdiction des identifiants partagés. | Usurpation, confusion de responsabilité et escalade de privilèges. |
| Outils et API | Catalogue d’outils approuvé, paramètres contrôlés, politiques d’autorisation appliquées hors du modèle et interdiction des commandes arbitraires. | Détournement d’un outil légitime et exécution d’actions non prévues. |
| Données et mémoire | Accès limité au besoin métier, séparation des espaces, filtrage des secrets, durée de conservation définie et contrôle des écritures en mémoire. | Fuite de données, empoisonnement de mémoire et propagation d’instructions malveillantes. |
| Capacité d’action | Limites de temps, de volume, de dépenses et de fréquence ; arrêt automatique en cas d’écart ; opérations sensibles rendues réversibles. | Effet cumulatif d’une boucle erronée ou poursuite indéfinie d’un objectif. |
| Supervision | Validation humaine fondée sur le niveau de risque, journalisation des appels d’outils, alertes, mécanisme d’arrêt et procédure de réponse à incident. | Action critique non détectée et impossibilité d’attribuer ou de reconstituer l’incident. |
Les recommandations de l’OWASP relatives à la sécurité des connecteurs MCP vont dans le même sens : moindre privilège par serveur et par outil, isolation des composants locaux, validation humaine des opérations sensibles, contrôle des entrées et sorties et journalisation centralisée. Elles rappellent surtout qu’un connecteur ne doit pas exécuter une action avec des privilèges plus larges que ceux nécessaires à la demande.
Le principe directeur peut être formulé ainsi : accorder à l’agent la plus faible autonomie compatible avec la tâche attendue. Il prolonge le moindre privilège. Il ne limite plus seulement les droits d’un compte ; il limite également l’initiative, la durée, les outils, le périmètre et l’irréversibilité de l’action.
Le cloisonnement devient-il une exigence de gouvernance ?
Le cloisonnement n’est pas encore une obligation autonome et universelle portant ce nom. Son caractère exigible dépend du système, de son usage, du secteur et des conséquences possibles. Toutefois, plusieurs cadres convergent vers la nécessité de limites techniques démontrables.
Pour les systèmes d’IA à haut risque relevant de l’AI Act, le règlement européen organise notamment la gestion continue des risques, la tenue de journaux, la supervision humaine ainsi que la robustesse et la cybersécurité. Les articles 9, 12, 14 et 15 ne prescrivent pas une architecture unique. Mais lorsqu’un agent peut engager une action présentant un risque pour la santé, la sécurité ou les droits fondamentaux, une organisation devra expliquer comment la supervision peut intervenir, comment les événements sont reconstitués et comment le système résiste à un usage détourné. Une simple consigne donnée au modèle sera difficile à présenter comme une mesure suffisante.
L’ISO/IEC 42001 fournit le cadre managérial permettant de transformer ces attentes en politique : responsabilités, appréciation des risques et impacts, règles d’utilisation, maîtrise du cycle de vie, gestion des tiers, surveillance et amélioration continue. La norme n’impose pas systématiquement une sandbox. Elle demande cependant à l’organisation de sélectionner et de piloter des mesures proportionnées aux risques de ses systèmes d’IA. Pour un agent doté d’accès sensibles, le choix de ne pas le cloisonner doit donc être justifié aussi rigoureusement que le choix inverse.
L’ISO/IEC 27001 complète cette approche en traitant l’agent comme un composant du système d’information : actif à inventorier, identité à maîtriser, logiciel à sécuriser, accès privilégié à contrôler, activité à journaliser et fournisseur à évaluer. L’articulation entre ISO 42001 et ISO 27001 devient particulièrement utile : le SMIA gouverne la finalité, les impacts et l’autonomie du système, tandis que le SMSI protège les informations, les identités, les infrastructures et les flux qui lui sont confiés.
La même logique se retrouve dans NIS2 et DORA lorsque l’agent intervient dans un service essentiel, un processus financier ou une fonction dépendant d’un prestataire technologique. Ces textes ne réglementent pas l’agent en tant que tel. Ils imposent cependant une maîtrise des risques liés aux systèmes, aux accès, aux fournisseurs, à la continuité et à la réponse aux incidents. Un agent connecté à une fonction critique entre donc dans le périmètre réel de résilience, même s’il a initialement été introduit comme simple outil de productivité.
DEVFORMA a analysé cette extension du périmètre dans son article consacré à l’intégration de l’intelligence artificielle au SMSI.
Le cloisonnement devient ainsi une exigence de gouvernance dès que trois conditions sont réunies : l’agent dispose d’une capacité d’action réelle, cette action peut produire un effet significatif et l’organisation doit démontrer qu’elle en conserve la maîtrise. Ce n’est pas le mot « sandbox » qui est juridiquement déterminant, mais la capacité à produire des preuves de limitation, de surveillance et d’intervention.
De la politique à la preuve d’audit
Une charte d’utilisation de l’IA ou une déclaration de principes ne permet pas, à elle seule, de vérifier la sécurité d’un agent. L’audit doit pouvoir relier chaque décision de gouvernance à un contrôle technique et à une preuve conservée.
| Question d’audit | Contrôle attendu | Preuve possible |
|---|---|---|
| Quels agents sont déployés et dans quel but ? | Inventaire des systèmes, propriétaires et finalités. | Registre des agents, fiche de cas d’usage, responsable désigné. |
| Quel niveau d’autonomie leur est accordé ? | Classification selon la portée et l’impact des actions. | Analyse de risque, niveau d’autonomie approuvé, critères de réévaluation. |
| Quelles ressources peuvent-ils atteindre ? | Cartographie des données, outils, réseaux et dépendances. | Schéma d’architecture, matrice des flux et liste des API autorisées. |
| Sous quelle identité agissent-ils ? | Identités dédiées et moindre privilège. | Matrice d’habilitation, configuration IAM/PAM, durée de vie des jetons. |
| Quelles actions exigent une validation ? | Seuils de supervision humaine fondés sur le risque. | Workflow d’approbation, journal des validations et règles de séparation des tâches. |
| Comment détecter une sortie de périmètre ? | Contrôles réseau, règles d’anomalie et surveillance des outils. | Alertes SIEM, journaux d’appels, tests de filtrage et rapports de surveillance. |
| Comment arrêter l’agent ? | Interruption technique indépendante du modèle et révocation immédiate des accès. | Procédure d’arrêt, test du kill switch, exercice de réponse à incident. |
| Comment vérifier la résistance du dispositif ? | Tests fonctionnels, adversariaux et scénarios d’injection. | Rapports de red team, résultats de tests et suivi des mesures correctives. |
| Comment les tiers sont-ils maîtrisés ? | Exigences contractuelles, notification des changements et réversibilité. | Évaluation fournisseur, clauses de sécurité, plan de sortie et registre des versions. |
Cette traçabilité évite deux angles morts fréquents. Le premier consiste à auditer uniquement le modèle alors que l’incident naît souvent du connecteur, de l’identité ou de l’environnement. Le second consiste à conserver le résultat final sans enregistrer la trajectoire : sources consultées, appels d’outils, autorisations, décisions intermédiaires et modifications effectivement réalisées.
La journalisation doit néanmoins rester maîtrisée. Enregistrer intégralement les prompts, les données et les secrets peut créer un nouveau gisement de données sensibles. Les journaux doivent donc être protégés, minimisés, horodatés, associés à l’identité de la session et conservés selon une durée définie. Ils doivent permettre d’établir ce qui s’est passé sans reproduire inutilement toutes les informations traitées.
Quel niveau d’autonomie accepter en production ?
Toutes les tâches n’appellent pas le même degré de confinement. Une organisation peut formaliser une grille interne d’autonomie afin d’éviter qu’un prototype conçu pour assister un utilisateur n’évolue progressivement vers un pouvoir d’action non gouverné.
| Niveau proposé | Capacité de l’agent | Condition de déploiement |
|---|---|---|
| A0 – Consultation | Génération de contenu sans accès direct à un outil métier. | Filtrage des données, règles d’usage et validation humaine du résultat. |
| A1 – Lecture limitée | Consultation de sources internes explicitement autorisées. | Accès en lecture seule, identité dédiée, segmentation des données et journalisation. |
| A2 – Action supervisée | Préparation ou exécution d’une action réversible après approbation. | Affichage des paramètres complets, validation humaine et séparation des tâches sensibles. |
| A3 – Autonomie bornée | Enchaînement d’actions dans un domaine défini, avec limites de durée, de volume et de coût. | Sandbox, politiques d’autorisation externes au modèle, surveillance en temps réel et arrêt automatique. |
| A4 – Autonomie ouverte | Choix libre des moyens, accès étendu ou action difficilement réversible. | À exclure par défaut des processus critiques ; toute exception exige une décision formelle, des tests renforcés et une justification documentée. |
Cette grille n’est pas un standard officiel. Elle constitue un outil de gouvernance permettant de relier l’autonomie accordée au niveau d’assurance exigé. L’objectif n’est pas de maintenir toutes les IA au niveau A0, mais d’éviter que la capacité d’action progresse plus vite que les contrôles.
Une validation humaine n’est d’ailleurs utile que si elle est substantielle. Demander à un utilisateur d’approuver des centaines d’actions routinières crée une fatigue de validation et transforme le contrôle en formalité. La supervision doit se concentrer sur les changements de périmètre, les opérations irréversibles, les transferts de données, l’usage d’un nouveau destinataire, les actions financières, les privilèges élevés et les situations présentant une incertitude inhabituelle.
Le sandbox comme preuve de maîtrise, non comme garantie absolue
Les incidents de 2026 ne signifient pas qu’il faudrait renoncer aux agents IA. Ils montrent que leur sécurité ne peut pas dépendre de leur seule capacité à interpréter correctement une consigne. Plus un système devient compétent pour rechercher une solution, plus l’environnement doit définir les solutions qui lui restent techniquement accessibles.
Le cloisonnement n’est pas une garantie absolue. Une sandbox peut contenir une vulnérabilité, une identité peut être surdimensionnée et un humain peut approuver une action sans en comprendre les conséquences. Il constitue néanmoins une condition structurante : il réduit l’impact maximal d’une défaillance, rend l’autonomie observable et donne à l’organisation la possibilité d’interrompre l’action.
La gouvernance des agents IA doit ainsi réunir trois disciplines longtemps traitées séparément : la gouvernance de l’IA, qui détermine la finalité et l’autonomie acceptables ; la sécurité de l’information, qui protège les identités, les données et les infrastructures ; et la résilience opérationnelle, qui prépare l’organisation à détecter, contenir et reprendre l’activité après un incident.
Autrement dit, le véritable test de gouvernance n’est plus : « avons-nous demandé à l’agent de respecter le périmètre ? » Il devient : « quelles preuves démontrent qu’il ne peut pas le dépasser sans être bloqué, détecté ou soumis à une décision humaine ? »
DEVFORMA accompagne les organisations dans la structuration de cette démarche, depuis l’inventaire des systèmes et l’analyse des risques jusqu’à la formalisation des contrôles et des preuves d’audit. La formation ISO/IEC 42001 Lead Implementer permet de construire et piloter un système de management de l’IA. La formation Lead AI Risk Manager approfondit l’identification, l’évaluation et le traitement des risques propres aux agents et aux modèles. Pour intégrer ces composants au système de sécurité de l’information, la formation ISO/IEC 27001 Lead Implementer apporte le cadre nécessaire à la maîtrise des accès, des fournisseurs, des incidents et de l’amélioration continue.
FAQ
Qu’est-ce qu’une sandbox pour un agent IA ?
Une sandbox est un environnement d’exécution isolé qui limite l’accès de l’agent au système hôte, au réseau, aux fichiers et aux ressources externes. Elle permet de tester ou d’exécuter des actions sans exposer directement l’environnement de production. Son efficacité dépend toutefois de sa configuration, de sa surveillance et des droits accordés aux outils connectés.
Une sandbox suffit-elle à sécuriser un agent autonome ?
Non. Elle doit être complétée par des identités dédiées, des droits minimaux, un filtrage réseau, un contrôle des API, des limites de ressources, une validation humaine pour les actions sensibles, une journalisation et un mécanisme d’arrêt. Un agent isolé au niveau du système peut encore causer un dommage par l’intermédiaire d’une API légitime trop permissive.
Quelle différence existe-t-il entre sécurité du modèle et sécurité de l’agent ?
La sécurité du modèle concerne notamment ses réponses, sa robustesse, son alignement et sa résistance aux manipulations. La sécurité de l’agent couvre l’ensemble du système qui transforme ces réponses en actions : outils, identités, mémoire, données, réseau, environnement d’exécution et autres agents.
L’ISO/IEC 42001 impose-t-elle de placer les agents IA dans une sandbox ?
La norme n’impose pas une architecture technique unique. Elle demande à l’organisation d’identifier ses risques et impacts, d’établir des contrôles proportionnés, de surveiller ses systèmes et d’améliorer son dispositif. Pour un agent disposant d’accès sensibles ou d’une autonomie importante, la sandbox et les autres formes de cloisonnement peuvent devenir des mesures nécessaires pour démontrer cette maîtrise.
Quelles mesures prendre avant de déployer un agent IA en production ?
Il convient au minimum d’inventorier le cas d’usage, de désigner un responsable, de classifier le niveau d’autonomie, de cartographier les données et les outils accessibles, d’attribuer une identité dédiée, de limiter les flux réseau, de définir les validations humaines, de tester les scénarios d’injection et de sortie de périmètre, puis d’organiser la journalisation et l’arrêt d’urgence.
