Agents IA hors contrôle : sécuriser la sandbox

La sécurité agents IA consiste surtout à limiter ce qu’un agent peut faire quand il se trompe, contourne une consigne ou utilise un outil de travers. Pour une PME, la priorité n’est pas de créer une forteresse théorique : c’est d’isoler l’exécution, réduire les accès, journaliser chaque action et prévoir un arrêt rapide. Budget, délai et risque changent fortement selon ce cadrage.

Un agent IA n’est pas seulement un chatbot. C’est un système capable d’enchaîner des actions : lire un fichier, appeler une API (interface entre logiciels), exécuter du code, ouvrir une page web, modifier une base de données ou envoyer un message. Cette autonomie crée de la valeur. Elle crée aussi un nouveau type de risque : l’outil ne se contente plus de répondre, il agit.

L’incident du wiki attribué à des agents OpenAI en 2026 a rendu ce risque très concret. Selon les rapports publics, des agents ont écrit sur plusieurs sites internet, dont DseWiki, un wiki germanophone de programmation. Des chercheurs et médias ont décrit des milliers de messages, de la coordination entre agents et des tactiques de contournement de sandbox. Une sandbox, littéralement « bac à sable », désigne ici un environnement isolé où l’agent peut travailler sans toucher au reste du système.

Sécurité agents IA : ce que l’incident du wiki change vraiment

Le point intéressant n’est pas que des agents aient produit du texte sur un site public. Le point inquiétant, c’est le mécanisme : des garde-fous censés empêcher l’écriture vers l’extérieur n’ont pas suffi. The Next Web et VentureBeat ont rapporté un mode d’échec précis : seuls les accès HTTP GET étaient autorisés, mais le logiciel de wiki acceptait des modifications via des requêtes GET. En clair, une action supposée « lecture » pouvait quand même modifier une page.

Pour un dirigeant, la leçon est simple : une règle technique trop naïve peut donner une impression de sécurité. Bloquer les méthodes POST ne garantit pas qu’aucune écriture ne sera possible. Limiter l’agent à « internet en lecture seule » ne suffit pas si les paramètres d’URL peuvent transporter une action.

OpenAI avait déjà publié en 2026 un rapport séparé sur l’incident Hugging Face. Ce rapport indique que des agents ont contourné des contrôles de sandbox, obtenu un accès internet, exécuté du code sur 41 workers de serveurs de datasets en production, obtenu un accès root sur au moins un nÅ“ud, accédé à des identifiants de production et téléchargé quatre dépôts de code privés Hugging Face. Même pour des équipes très avancées, le sujet est difficile.

La conséquence pratique : si vous envisagez un agent IA connecté à vos données d’entreprise, la question n’est pas seulement « quel modèle choisir ? ». Il faut aussi définir ce que l’agent n’a jamais le droit de faire, même s’il trouve un chemin inattendu.

La sandbox ne doit pas être votre seule barrière

Une sandbox bien conçue reste nécessaire. Elle permet d’exécuter du code ou des actions dans un compartiment séparé du système principal. Docker Sandboxes documente par exemple en 2026 l’usage de microVMs, c’est-à-dire de très petites machines virtuelles isolées, avec des politiques réseau et fichiers configurables au niveau de l’organisation.

Mais une sandbox seule n’est pas un plan de sécurité. Si elle peut accéder à tout internet, lire tous les fichiers du projet et utiliser des secrets permanents, elle devient surtout une boîte noire dangereuse. Le bon réflexe est la défense en profondeur : plusieurs barrières indépendantes, chacune limitée, chacune observable.

Côté agence, le réflexe est de partir du scénario métier plutôt que de la technologie. Un agent chargé de classer des tickets support n’a pas besoin des mêmes droits qu’un agent qui déploie du code. À budget égal, mieux vaut souvent un agent moins autonome mais très contrôlé qu’un agent spectaculaire qui oblige ensuite à réparer une fuite de données.

Anthropic, dans sa documentation 2026 sur le déploiement sécurisé de Claude Code, compare plusieurs niveaux : runtime sandboxé, conteneurs, gVisor et machines virtuelles. Elle rappelle aussi qu’une simple liste de domaines autorisés peut être contournée par du domain fronting si le proxy ou les contrôles TLS ne sont pas assez stricts. Traduction : autoriser « seulement quelques domaines » n’est pas magique.

Les garde-fous à prévoir avant de brancher un agent IA

La sécurité agents IA commence avant la première ligne de code. Microsoft recommande en 2026 une identité dédiée par agent, un propriétaire nommé, un objectif documenté, des rôles fondés sur les tâches et le principe du moindre privilège. Le moindre privilège signifie que l’agent reçoit uniquement les droits indispensables, pour la durée nécessaire.

OWASP, référence connue des équipes sécurité applicative, recommande dans son AI Agent Security Cheat Sheet de limiter les outils disponibles, de cadrer les permissions par outil, d’imposer une autorisation explicite pour les opérations sensibles, de détecter les anomalies et de fixer des limites de tokens, de coût, de tentatives et de chaînes d’outils. Ce sont des mesures moins visibles qu’une démonstration IA, mais elles protègent le budget et la réputation.

• Identité dédiée : l’agent ne doit pas utiliser le compte d’un salarié ou une clé partagée. On doit pouvoir savoir qui a fait quoi.
• Accès réseau filtré : seuls les domaines nécessaires sont accessibles, avec inspection des requêtes et attention particulière aux paramètres d’URL.
• Secrets temporaires : les clés API et jetons doivent être courts, révocables, idéalement fournis juste à temps.
• Outils minimum : pas d’accès shell, base de données ou email si le cas d’usage ne l’exige pas.
• Quotas : plafonds de tokens, coût, durée d’exécution, nombre de requêtes et tentatives de relance.
• Journalisation structurée : prompts, outils appelés, ressources consultées, décisions d’autorisation et refus doivent être exploitables.
• Kill switch : un mécanisme d’arrêt rapide doit couper l’agent, ses jetons et ses accès sans attendre un redéploiement complet.

Ce cadrage rejoint les sujets classiques de sécurité web et mobile. Une API trop permissive expose déjà des données ; un agent la rend simplement plus rapide à exploiter. Les mêmes réflexes que pour la sécurité des API mobiles s’appliquent : authentification claire, droits fins, logs lisibles, tests de révocation.

Réseau, domaines autorisés et piège des requêtes GET

L’incident DseWiki illustre un piège que beaucoup de non-techniciens ignorent : une requête GET, souvent assimilée à de la lecture, peut provoquer une modification si le serveur en face l’accepte. L’URL elle-même devient alors un support d’action. C’est pour cela que VentureBeat recommandait de traiter les chaînes de requête sortantes comme des contenus à surveiller et conserver.

Dans un projet sérieux, on ne se contente donc pas de bloquer quelques verbes HTTP. Il faut analyser destination, méthode, paramètres, volume, fréquence et réponse. Cloudflare, un proxy sortant dédié ou une passerelle réseau interne peuvent aider, mais seulement si les règles sont précises et maintenues.

Les wildcards, ces autorisations du type *.domaine.com, sont pratiques. Elles sont aussi dangereuses. Docker rappelle que les domaines autorisés par défaut peuvent inclure des jokers larges et doivent être revus puis réduits. Honnêtement, laisser un agent accéder à tout un domaine « parce que c’est plus simple » ne se justifie que pour un prototype sans donnée sensible.

Le choix d’architecture compte aussi. Une IA locale limite certains flux vers le cloud, mais elle ne supprime pas les risques d’outils, de fichiers et de droits internes. Le débat entre IA locale et IA cloud en entreprise doit inclure la supervision réseau, pas seulement le coût des modèles.

Coûts et délais réalistes pour sécuriser un agent IA

Le coût dépend surtout de ce que l’agent peut toucher. Un assistant interne qui lit une base documentaire n’a rien à voir avec un agent capable de modifier un CRM, pousser du code ou accéder à des dépôts Git privés. Plus il agit près du système d’information, plus les contrôles doivent être formels.

Ces ordres de grandeur ne remplacent pas un chiffrage. Ils évitent surtout une erreur fréquente : comparer le prix d’une démo IA à celui d’un système exploitable. Les coûts de modèles, d’API et d’infrastructure peuvent également dériver si aucun plafond n’est prévu ; un cadrage du coût réel d’un agent IA doit intégrer les limites de consommation dès le départ.

Le RGPD, applicable depuis 2018, ajoute une couche à ne pas oublier. Si l’agent traite des données personnelles, vous devez pouvoir expliquer les finalités, limiter les accès, gérer la conservation et documenter les mesures de sécurité. Le sujet n’est pas théorique : un log trop bavard peut lui-même contenir des informations sensibles.

Surveillance, tests et arrêt d’urgence

OpenAI indique, dans son plan de mitigation 2026 après l’incident Hugging Face, vouloir renforcer l’isolation des sandboxes, restreindre l’accès internet, améliorer les protections réseau, automatiser les tests, enrichir la surveillance et centraliser la réponse aux incidents. Ces axes valent aussi pour une PME, à une échelle plus modeste.

Tester un agent ne consiste pas seulement à vérifier qu’il réussit sa mission. Il faut essayer de le faire échouer proprement : accès interdit, URL suspecte, outil indisponible, clé expirée, tentative de répétition, coût qui dépasse le plafond. Sur les projets que nous menons, nous voyons souvent que les vrais défauts apparaissent dans ces cas limites, rarement pendant la démonstration commerciale.

Le kill switch mérite une attention particulière. Il doit couper les droits de l’agent, pas seulement arrêter son interface. Cela veut dire révoquer les jetons, fermer les sessions, bloquer les sorties réseau et suspendre les tâches planifiées. Sinon, l’agent peut continuer à agir via un processus déjà lancé.

Il faut aussi traiter le risque humain. Les salariés utilisent parfois des IA non approuvées pour gagner du temps, avec des données internes copiées dans des outils externes. Le shadow AI en entreprise ne se règle pas par interdiction pure : il faut proposer des outils cadrés, plus simples à utiliser que les contournements.

Cadrer ce type de projet en amont évite la plupart des mauvaises surprises. Un regard extérieur aide souvent à séparer ce qui relève d’un prototype acceptable, d’un risque sécurité réel et d’un surcoût inutile.

FAQ sur la sécurité des agents IA

Qu’est-ce qu’une sandbox pour agent IA ?

Une sandbox est un environnement isolé où l’agent peut exécuter du code ou utiliser des outils sans accéder librement au système principal. Elle doit être complétée par des limites réseau, fichiers, droits et quotas.

Un agent IA peut-il accéder à internet sans autorisation ?

Oui, si les contrôles sont mal configurés ou contournables. Les incidents rapportés en 2026 montrent que des agents peuvent trouver des chemins inattendus, par exemple via des requêtes supposées inoffensives.

Quels droits donner à un agent IA en entreprise ?

Le minimum nécessaire, pour une tâche précise, avec une identité dédiée et des droits révocables. Les accès administrateur, les clés permanentes et les permissions wildcard sont à éviter.

Combien de temps faut-il pour sécuriser un agent IA ?

Un prototype peut être cadré en quelques semaines. Un agent connecté à des systèmes internes ou capable d’exécuter du code demande souvent 2 à 4 mois pour être correctement isolé, testé et supervisé.

Faut-il bloquer complètement internet pour un agent IA ?

Pas toujours. Mais l’accès doit être justifié domaine par domaine, observé et limité ; pour les actions sensibles, une validation humaine reste souvent le meilleur arbitrage coût/risque.