Cloudflare Sandbox pour le code IA permet à un assistant de transformer des fichiers ou réaliser des calculs sans placer directement le code généré dans l’application principale. La décision essentielle concerne ce que l’environnement peut atteindre. Le code utilise les fichiers, identifiants, routes réseau et outils que vous lui rendez accessibles.
Exécutez le code généré dans une frontière adaptée à la charge, avec des entrées, accès réseau et capacités applicatives volontairement limités. Gardez les opérations importantes à l’extérieur et validez les fichiers retournés avant usage. Testez confinement, ressources et nettoyage avec du code hostile autant qu’ordinaire avant d’élargir l’accès.
Imaginez un analyste demandant de combiner des exports CSV autorisés et produire un graphique. L’assistant a besoin de ces fichiers et d’un emplacement de sortie. Il n’a besoin ni du compte de stockage complet de l’entreprise ni d’un identifiant capable de modifier le système source.
Cet article propose une architecture pour cette tâche. Il ne prétend ni que l’isolation élimine tout risque ni qu’un même environnement convienne à chaque langage et dépendance.
Cloudflare Sandbox pour le code IA : définir la frontière
La présentation de Sandboxes distingue environnements à conteneurs et Dynamic Workers. Le choix dépend des besoins d’exécution. Utilisez la documentation actuelle sans supposer qu’un ancien exemple du SDK Sandbox décrit l’interface d’aujourd’hui.
Pour la transformation de l’analyste, listez langage, bibliothèques, formats d’entrée, sorties et destinations réseau. Si le travail exige seulement un calcul local sur les fichiers fournis, tout accès externe supplémentaire doit avoir sa propre justification.
Le Worker d’orchestration doit décider à quel utilisateur authentifié appartient chaque tâche. L’environnement de code ne reçoit que les éléments permis pour cette tâche, pas des identifiants couvrant tout le compte qui lui permettraient de découvrir davantage de données.
| Capacité | Nécessaire dans l’exemple ? | Frontière à définir |
|---|---|---|
| Lire les exports sélectionnés | Oui | Entrées autorisées de la tâche uniquement |
| Écrire des résultats | Oui | Emplacement de sortie dédié |
| Accéder à Internet | Pas intrinsèquement | Destinations nommées et justifiées |
| Lire les identifiants de production | Non | Autorité du service hors de la tâche |
| Modifier les dossiers métier sources | Non | Opération applicative séparée et révisée |
Choisir l’environnement selon les besoins
Le guide de sélection d’environnement sert de départ à la comparaison. Confirmez langage, dépendances et durée de vie réellement pris en charge pour votre tâche.
Un environnement complet de commandes est utile si la chaîne d’outils l’exige. Il apporte aussi fichiers, processus et comportements de dépendances à prendre en compte. Une surface plus étroite peut être plus facile à réviser pour une transformation limitée.
Ne choisissez pas l’environnement le plus puissant simplement pour simplifier la première démonstration. La question d’achat est sa capacité à réaliser la tâche permise avec des contrôles explicables et maintenables.
Figez l’image d’exécution ou la configuration des dépendances si la plateforme choisie le permet. Consignez la configuration avec le résultat afin de relier une panne ultérieure à l’environnement qui a réellement exécuté le code.
Garder secrets et autorité métier dans l’application
Les indications sur identifiants et réseau expliquent les contrôles pertinents. Définissez comment l’environnement rejoint les services approuvés et vérifiez ce comportement directement dans la configuration de test.
Pour l’analyste, l’application d’orchestration peut obtenir les exports autorisés et les livrer comme entrées. Le programme généré travaille alors sur ces copies. S’il lui faut une autre source, il renvoie une demande à l’application, où identité et permissions restent contrôlées.
Ne transmettez pas un identifiant de stockage large en comptant sur le prompt pour définir le dossier autorisé. L’autorité réside dans l’identifiant et la frontière d’exécution, pas dans la politesse de l’instruction au modèle.
Appliquez le même principe aux sorties. La tâche peut proposer un fichier ou résultat. Un composant distinct décide de publier, envoyer ou importer. Le code généré ne transforme ainsi pas une demande de transformation en action métier non révisée.
Traiter les fichiers comme des entrées et sorties non fiables
Validez type et taille avant exécution selon une politique convenue. Gardez un manifeste permettant d’établir exactement quels fichiers sont entrés. Ne mélangez pas les fichiers d’utilisateurs différents dans un espace commun sans conception d’isolation vérifiée.
Inspectez aussi les sorties. Une extension attendue peut masquer format inattendu, contenu caché ou calcul trompeur. Confirmez type, emplacement autorisé et contrôles sémantiques avant de présenter un résultat terminé.
Pour un graphique financier, comparez les totaux aux sources et expliquez les exclusions. Un beau rendu ne prouve pas la justesse du calcul. Pour une archive ou un export documentaire, inspectez fichiers et données réellement contenus.
| Étape | Contrôle proposé | Ce qu’il évite |
|---|---|---|
| Admission des entrées | Source autorisée et format attendu | Traitement accidentel des données d’un autre utilisateur |
| Préparation de l’espace | Chemins propres à la tâche et contenu limité | Réemploi des éléments d’une autre tâche |
| Collecte des sorties | Type, chemin et taille attendus | Fichiers imprévus présentés comme livrables |
| Validation sémantique | Totaux, références ou contrôles métier | Résultats plausibles mais incorrects |
| Publication | Autorité applicative explicite | Distribution autonome des données par le code |
Tester le code hostile dans l’environnement permis
L’acceptation doit comprendre lecture hors de l’espace fourni, contact d’une destination non approuvée et consommation excessive. Utilisez données synthétiques et environnement dédié pour que le test lui-même ne puisse exposer la production.
Testez les contrôles réellement configurés. Un schéma sans connexion Internet ne prouve pas le blocage des sorties. Capturez le résultat de la tentative et la raison retournée par l’environnement.
Les recommandations de sécurité Sandbox sont la référence primaire des frontières. Les contrôles applicatifs demandent leurs propres tests, dont authentification, routage des tâches et publication des sorties.
Testez également les pannes ordinaires : import de dépendance échoué, CSV invalide, processus interminable et sortie dépassant la politique applicative. L’opérateur doit disposer d’une catégorie claire et d’un moyen sûr d’arrêter ou examiner la tâche.
Rendre durée de vie et nettoyage observables
Définissez début, événements de fin et éléments qui subsistent. Distinguez environnement d’exécution, résultats conservés et preuves opérationnelles. Arrêter un processus ne supprime pas forcément les fichiers copiés vers un autre stockage.
Si les espaces sont restaurés ou réutilisés, précisez quelles données peuvent revenir. Un espace persistant pratique devient un problème entre tâches si routage ou hypothèses de nettoyage sont faux.
Gardez responsable, manifeste source, configuration, motif de fin et sorties collectées. Ne conservez que le contenu nécessaire à la tâche et à sa politique de révision convenue.
Répétez annulation et nettoyage après échec. Confirmez que la tâche suivante ne peut pas inspecter les anciennes entrées et que l’application peut encore expliquer l’échec sans copie inutile de chaque fichier.
Estimer un service d’exécution contrôlé
Le coût comprend orchestration, identité, préparation, contrôles, validation des fichiers et exploitation. Il dépasse le code nécessaire pour lancer une commande une fois.
Demandez un devis en GBP définissant types de tâches et langages. Un service borné de transformation CSV est un premier périmètre plus clair qu’un assistant général autorisé à lancer n’importe quel programme dans les systèmes de l’entreprise.
Les coûts récurrents dépendent de l’environnement, durée d’exécution, stockage, modèle et traitement des pannes. Vérifiez les tarifs actuels correspondants. Ne transposez pas une estimation de conteneur à Dynamic Workers et ne supposez pas gratuits repos, échec ou restauration.
Le pilote doit produire des fichiers utiles et prouver leur frontière. Montrez tâche valide, capacité bloquée, annulation, nettoyage et sortie refusée. Le responsable pourra décider si un autre type de tâche peut être ajouté sans risque excessif.
Nous pouvons cadrer ce service avec notre pilote d’intégration IA . Demandez une proposition d’exécution en sandbox avec entrées d’exemple, outils requis et actions interdites sans autorité distincte.
Questions fréquentes
Une sandbox sécurise-t-elle automatiquement le code généré ? Non. L’isolation est utile, mais le code peut utiliser les capacités et données fournies. Définissez et testez fichiers, identifiants, réseau, ressources et traitement des sorties.
Le code doit-il recevoir des clés API de production ? Évitez une autorité large. Gardez les identifiants dans l’application où l’accès peut être contrôlé et n’exposez que les opérations limitées nécessaires. Vérifiez les contrôles d’identifiants et de réseau pris en charge.
Toutes les tâches exigent-elles un conteneur Linux ? Non. Choisissez selon langage, dépendances et exigences d’exécution. Cloudflare documente plusieurs approches ; une surface plus étroite peut suffire à une tâche limitée.
L’assistant peut-il publier automatiquement ses fichiers ? Uniquement selon une politique applicative convenue séparément. Création et distribution sont deux actions. Validez le fichier et contrôlez l’autorité avant importation, courriel ou exposition.
Que doit couvrir un test de confinement ? Avec données synthétiques et environnement dédié, testez accès fichiers interdit, destinations réseau non approuvées, excès de ressources, annulation et nettoyage. Gardez les preuves des contrôles plutôt que vous fier au dessin.
Peut-on réutiliser les espaces entre tâches ? Seulement avec une conception délibérée d’isolation et conservation. Le réemploi préserve du contexte utile mais peut aussi garder les données d’une autre tâche. Testez routage, contenu restauré et nettoyage avant d’en dépendre.
Qu’est-ce qui détermine le coût de réalisation ? Langages, dépendances, préparation des entrées, contrôles de capacités, validation des sorties et support. Commencez par une tâche limitée et demandez un devis en GBP incluant tests d’échec et remise opérationnelle.