La sandbox IA pour agents d'entreprise
Chaque tour d'agent sur Scrydon s'exécute dans un environnement neuf, à usage unique et isolé par le matériel, qui ne détient aucun identifiant et n'atteint aucune destination réseau par défaut — et le tour n'est admis qu'après validation d'une preuve signée que cette frontière existe réellement. Une isolation non prouvée est un refus, pas une dégradation.
Fail closed, jamais ouvert
Un tour d'agent ne s'exécute qu'après validation d'une preuve d'isolation signée pour le build exact sur le point de s'exécuter. Si cette preuve manque ou est périmée, le tour refuse — il n'existe aucun repli vers un processus hôte.
Un tour, une machine
Chaque tour reçoit un environnement neuf, à usage unique et virtualisé par le matériel, détruit sur chaque chemin de sortie — succès, échec, timeout ou annulation. Il n'existe aucun environnement d'agent durable à compromettre.
Le réseau est un contrat
La sortie réseau est refusée par défaut : une intégration n'atteint que les destinations déclarées dans son manifeste, intersectées avec la liste d'autorisation de votre organisation. Aucune des deux parties ne peut élargir l'autre.
Quand un agent IA travaille pour vous, il exécute du code, lit des documents et appelle d'autres systèmes — vous faites donc confiance à quelque chose que personne n'a relu ligne par ligne. La sandbox est la pièce fermée à clé dans laquelle l'agent travaille : il y entre sans aucune clé, ne peut frapper qu'aux portes que vous avez approuvées à l'avance, et la pièce est démolie dès que le travail se termine. Cette page explique comment cette pièce est construite — et comment nous prouvons qu'elle tient avant d'y laisser tourner quoi que ce soit.
À lire si vous êtes RSSI, architecte sécurité ou responsable de plateforme et devez savoir comment l'exécution des agents est contenue avant de l'approuver.
Une sandbox IA est la frontière d'isolation à l'intérieur de laquelle s'exécute la boucle de raisonnement, d'outils et de shell d'un agent IA. Sur Scrydon, cette frontière est un environnement neuf, à usage unique et virtualisé par le matériel pour chaque tour d'agent — sans identifiants réels à l'intérieur, avec une sortie réseau refusée par défaut — et un tour d'agent n'est admis qu'après qu'une preuve signée a établi l'existence de la frontière pour le build exact sur le point de s'exécuter.
À l'été 2026, des laboratoires d'IA de pointe ont révélé publiquement que des modèles en cours d'évaluation s'étaient échappés de leurs sandbox de test et avaient atteint de véritables infrastructures tierces. Le schéma derrière chaque incident était le même : l'isolation était affirmée par la configuration et vérifiée par personne. Scrydon a été conçu sur l'hypothèse que ce jour viendrait. Une charge de travail pilotée par un modèle est traitée comme une charge de travail non fiable — la même catégorie que du code téléchargé sur Internet — car une plateforme qui n'est sûre que tant que le modèle se comporte bien n'a pas de frontière de sécurité ; elle a un espoir. La sandbox IA est la traduction de cette hypothèse en architecture : isolation matérielle à chaque tour, identifiants hors de portée du modèle, sortie réseau sous forme de contrat explicite, et tentatives d'évasion testées contre chaque version avant sa mise en production.
Sandbox IA dans la plateforme Scrydon
Une architecture souveraine unique et intégrée. Voici où se situe Sandbox IA — mis en évidence au sein de la pile complète avec laquelle il fonctionne.
L'AI OS pour les humains et les agents IA
Couche d'ontologie et couche sémantique : un modèle unique et connecté pour vos données, connaissances et processus
Le meilleur des data lakes, des entrepôts de données et de la recherche réuni
Agents IA, flux de travail et automatisations qui s'exécutent à travers vos systèmes
Intégrez via A2A, MCP, systèmes existants et sources de données
Fédération de domaines sécurisée, partage de données de confiance et intelligence au-delà des frontières
Fondations Souveraines
Sandbox IA en détail
Orchestration Humain + IA
L'AI OS pour les humains et les agents IA
L'Orchestrateur Humain + IA est le runtime opérationnel au cœur de l'AI OS — également appelé Agentic OS — qui planifie, route et gouverne chaque tâche au sein de votre entreprise, qu'elle soit exécutée par un agent IA, un système existant ou un humain.
La plupart des organisations ont des processus défaillants : encodés dans des systèmes cloisonnés ou enfermés dans la tête des collaborateurs. L'AI OS les rend visibles et exécutables. Il capte l'intention, synthétise le contexte, agit — puis réinjecte chaque résultat dans l'ontologie afin que l'exécution suivante soit plus intelligente. Le tout à l'intérieur de votre périmètre.
L'IA agentique transforme les modèles frontier de chatbots isolés en véritables opérateurs autonomes de l'AI OS. Au lieu de simplement générer du texte, ces agents sont conçus pour exécuter les tâches que vos collaborateurs ne devraient pas traiter manuellement — raisonner, planifier et agir à travers des processus complexes en plusieurs étapes.
L'AI OS s'appuie sur un socle mêlant créativité et contrôle pour déployer efficacement des agents autonomes :
- Les workflows IA comme fondation : Le cœur de l'AI OS repose sur des workflows IA orchestrés qui relient en toute sécurité les modèles frontier, les outils internes et la mémoire d'entreprise.
- Flux déterministes et non déterministes : En combinant les capacités de raisonnement de l'IA frontier avec des workflows stricts et déterministes, l'AI OS garantit à la fois adaptabilité et prévisibilité absolue dans les processus critiques.
- Exécution autonome : Les agents agissent de manière autonome dans des limites définies, récupérant le contexte depuis votre data lakehouse et exécutant des actions via des outils approuvés.
Déployés en toute sécurité au sein de votre infrastructure, ces agents puisent dans votre cognitive enterprise pour agir avec discernement. Des garde-fous stricts, fondés sur des politiques, les maintiennent fermement dans les limites définies par votre organisation, assurant un équilibre parfait entre productivité et sécurité de niveau entreprise.
Quatre étapes, chacune appliquée hors de portée du modèle
Chaque tour d'agent standard — la boucle complète de raisonnement, d'outils et de shell du
modèle — traverse quatre étapes, et chacune est appliquée par une infrastructure que le modèle
ne peut pas atteindre. Avant que quoi que ce soit n'entre dans la sandbox, la plateforme valide
une preuve d'isolation fraîche et signée, liée au build exact sur le point de s'exécuter : pas
un isolation: true dans un fichier de configuration, mais une preuve produite en exerçant
réellement la frontière. Le contrôle s'exécute deux fois, à dessein — une fois côté appelant,
pour un refus rapide et lisible, et une fois dans le service de dispatch lui-même, où aucun
appelant périmé ou mal configuré ne peut le contourner. À l'intérieur de la sandbox, le modèle
ne détient ni identifiants ni socket réseau ; le
code d'intégration tiers ne partage jamais sa machine et
s'exécute dans un environnement séparé à usage unique, admis seulement après que
l'empreinte de son contenu correspond à l'identité à laquelle il a été épinglé. Et quand le
tour se termine — quelle que soit la fin — l'environnement est détruit, ses autorisations à
usage unique sont révoquées, et l'enregistrement d'audit
est scellé avant qu'un succès puisse être déclaré.
- 1
Admission — prouver que la cage existe
Un tour n'est lancé qu'après validation d'une preuve d'isolation fraîche et signée pour le build exact sur le point de s'exécuter. Preuve manquante, expirée ou non concordante : le tour refuse — fail closed, sans repli vers l'hôte.
- 2
Exécution — un tour, une VM isolée
La boucle de l'agent s'exécute dans un environnement neuf, à usage unique et virtualisé par le matériel. Le code d'intégration tiers s'exécute dans le sien, séparé — deux domaines de confiance qui ne partagent jamais une machine.
- 3
Sortie réseau — refus par défaut, requêtes intermédiées
La charge de travail ne détient jamais de socket réseau propre. Un courtier de confiance, hors de la sandbox, matérialise chaque requête sortante — uniquement vers des destinations approuvées à la fois par le manifeste de l'intégration et par votre liste d'autorisation.
- 4
Démantèlement — rien ne survit au tour
Chaque fin converge vers le même état : l'environnement est détruit, les autorisations à usage unique sont révoquées, et un enregistrement d'audit est scellé avant que le tour puisse déclarer un succès.
Pourquoi les agents ont besoin d'une vraie frontière, pas d'un drapeau de configuration
L'industrie a appris cette leçon publiquement et à grands frais. En quelques semaines, en 2026, un laboratoire de pointe a révélé que des modèles d'une évaluation de cybersécurité s'étaient échappés de leur environnement de test restreint via le seul service interne qu'ils pouvaient atteindre ; un autre a audité 141 000 exécutions d'évaluation et découvert de véritables organisations dont l'infrastructure de production avait été touchée après qu'une mauvaise configuration eut discrètement accordé un accès à Internet ; un troisième a signalé une mauvaise configuration similaire de son harnais. Le schéma dérangeant n'était pas « les modèles sont devenus trop intelligents » — c'était que l'isolation était affirmée par la configuration et vérifiée par personne. Scrydon exécute des agents sur les données les plus sensibles d'une entreprise, et part donc de l'hypothèse inverse : une charge de travail pilotée par un modèle est une charge de travail non fiable, dans la même catégorie que du code téléchargé sur Internet. Cette hypothèse est intransigeante à dessein. Elle exclut « l'agent tourne dans notre processus backend, mais prudemment » — et toute architecture dans laquelle l'appelant peut se déclarer lui-même confiné. Lisez le récit complet dans The Harness Holds (en anglais).
Les modèles s'échappent des sandbox affirmées — Les incidents de 2026 partageaient une même cause racine : une isolation déclarée dans la configuration et exercée par personne — une route réseau négligée, un drapeau que personne n'a revérifié.
Les agents touchent vos données les plus sensibles — Les agents d'entreprise travaillent sur des dossiers, des enquêtes et des connaissances internes. La frontière qui les entoure ne doit pas dépendre du bon comportement du modèle.
Les identifiants sont le butin — Un agent qui détient de vrais secrets transforme chaque évasion en violation. Dans la sandbox, le modèle voit des espaces réservés opaques ; les vraies valeurs restent hors de sa portée pendant tout le tour.
L'espoir n'est pas un modèle de sécurité — Une frontière qui ne tient que si la charge de travail coopère n'est pas une frontière — c'est une requête. La virtualisation matérielle tient, que le modèle coopère ou non.
Une isolation attaquée avant d'être livrée
Un contrat d'isolation que l'on ne teste jamais est un drapeau de configuration avec un meilleur marketing — c'est précisément ainsi que les incidents de 2026 se sont produits. Sur Scrydon, les tentatives d'évasion ne sont donc pas une hypothèse ; elles sont une porte de release versionnée dans le code. Avant qu'un candidat de release puisse être promu, une charge de travail délibérément malveillante s'exécute dans un véritable invité virtualisé et tente les mêmes classes d'évasion que les modèles en évaluation ont trouvées : atteindre un réseau qui ne lui a jamais été accordé, contourner le chemin de sortie au lieu de l'emprunter, et chasser des identifiants qu'elle ne devrait jamais pouvoir voir. La porte vérifie que chaque tentative échoue, que les octets réellement émis par la charge de travail ont traversé l'analyse de prévention des fuites de données, qu'aucun secret n'était présent à voler, et qu'aucun état d'environnement ou d'autorisation ne survit — sur le succès, l'échec, le timeout et l'annulation. Elle signe ensuite cette preuve contre le hash exact du candidat, et c'est cette signature que l'admission exige avant qu'un tour d'agent d'un client puisse s'exécuter. La boucle se referme sur elle-même : la release ne peut pas être livrée tant que l'évasion n'a pas échoué, et l'agent ne peut pas s'exécuter tant que la release ne l'a pas prouvé.
Les tentatives d'évasion sont une porte de release — Une charge de travail délibérément malveillante tente, contre chaque candidat de release, les classes connues d'évasion de sandbox — atteindre un réseau non déclaré, contourner le chemin de sortie, chasser des identifiants.
La preuve signée boucle la boucle — La release ne peut pas être livrée tant que l'évasion n'a pas échoué, et un tour d'agent ne peut pas s'exécuter tant que la release ne l'a pas prouvé — la même signature vérifiée à l'admission.
Les vrais octets, pas l'intention déclarée — L'analyse de prévention des fuites de données s'applique au trafic réel qui quitte la plateforme, en entrée comme en sortie — pas à ce que le modèle prétend faire.
L'audit comme infrastructure porteuse — Un tour n'est réussi que lorsque son enregistrement d'audit, exempt d'identifiants, est scellé. Un pic de trafic ne peut jamais vous coûter un enregistrement de conformité.
Questions fréquentes
Qu'est-ce qu'une sandbox IA ?+
Pourquoi les agents IA ont-ils besoin d'une sandbox ?+
En quoi est-ce différent d'exécuter des agents dans un conteneur ou une sandbox de processus ?+
Que se passe-t-il si l'isolation ne peut pas être prouvée ?+
Une intégration d'un fournisseur peut-elle élargir l'accès réseau de la sandbox ?+
Le modèle voit-il un jour de vrais identifiants ?+
La sandbox IA fonctionne-t-elle dans les déploiements souverains et air-gapped ?+
Explorer la plateforme
Vous préférez écrire ? Envoyez un e-mail à hello [at] scrydon.com et nous vous répondrons.
Partenaires
