Construire un AI Data Analyst avec Python sandboxé et accès contrôlé aux packages

Un AI Data Analyst a besoin de Python sandboxé lorsque des jeux de données fournis par l’utilisateur, du code généré par le modèle, des installations de packages, des graphiques générés et des résultats téléchargeables doivent s’exécuter dans un environnement isolé et observable. Le flux de mise en œuvre pratique est le suivant : télécharger un fichier, inspecter le schéma avec du code de confiance, demander un plan au modèle, examiner le code Python généré, l’exécuter dans un sandbox contraint, valider les artefacts produits et montrer à l’utilisateur ce qui s’est passé.

Architecture de l’AI Data Analyst : Téléchargement, Analyse, Révision

Le modèle produit est simple en apparence : un utilisateur télécharge un CSV, pose une question en langage naturel et s’attend à obtenir des tableaux utiles, des graphiques et des fichiers téléchargeables. En coulisses, l’application exécute un petit workflow d’agent avec de réels effets de bord. Le modèle planifie l’analyse et rédige le code Python, tandis que l’application décide quel code, quels packages, quels fichiers, quel accès réseau et quelles sorties sont autorisés.

Construisez la première version autour d’un seul chemin clair :

1. Accepter un téléchargement CSV pour un travail d’analyse.
2. Créer un espace de travail sandboxé pour le travail.
3. Exécuter un code d’inspection de schéma propriétaire avant de demander du Python au modèle.
4. Demander au modèle un plan d’analyse, puis un script conforme à vos règles de fichiers et de packages.
5. Exécuter le script avec des limites de temps, mémoire, disque, packages et réseau.
6. Collecter uniquement les artefacts validés depuis un répertoire de sortie connu.
7. Montrer à l’utilisateur la réponse, les graphiques, les avertissements, les logs et les fichiers sélectionnés pour le téléchargement.

Cette séparation maintient des responsabilités claires. Le modèle propose et explique l’analyse. Le backend applique la politique produit et l’orchestration. Le sandbox exécute le code avec des fichiers, packages, temps, mémoire, accès réseau et secrets limités.

Que s’exécute-t-il dans un Sandbox Python pour l’Analyse de Données ?

Placez l’espace de travail d’analyse à l’intérieur du sandbox, pas sur votre serveur d’application principal. Le sandbox doit recevoir un ensemble d’entrées étroit pour un seul travail d’analyse : le fichier téléchargé, un petit manifeste, un script généré et toute configuration d’exécution approuvée. Le backend de l’application doit garder l’authentification, la facturation, l’identité utilisateur, le stockage à long terme et les secrets de production en dehors de cet espace de travail.

Pour un AI Data Analyst, le sandbox gère généralement ces tâches :

Tâche du sandbox	Pourquoi elle y appartient
Staging des fichiers	Le CSV téléchargé peut être analysé et copié dans un répertoire de travail isolé avant que Python ne le touche.
Inspection du schéma	L’application peut déduire les noms de colonnes, les types, les taux de nullité, le nombre de lignes et des valeurs d’exemple sans exposer le fichier complet au modèle.
Exécution Python	Le code généré par le modèle s’exécute loin du serveur d’application et peut être limité dans le temps.
Préparation des packages	Seules les dépendances approuvées sont installées ou mises à disposition du travail.
Rendu des graphiques	Les images de graphiques sont écrites sous forme de fichiers et examinées avant téléchargement.
Emballage des résultats	Les artefacts finaux peuvent être collectés depuis un répertoire de sortie connu.
Nettoyage	Les fichiers temporaires, le code généré et l’état de session peuvent être supprimés ou autorisés à expirer.

Gardez le prompt du modèle plus petit que les données. Envoyez un résumé du schéma, quelques lignes représentatives si la politique le permet, des descriptions de colonnes, l’intention de l’utilisateur et des contraintes comme “n’entraînez pas de modèle” ou “utilisez uniquement les packages approuvés”. Le jeu de données brut doit rester dans le système de fichiers du sandbox, sauf si votre produit a une raison spécifique et examinée d’en exposer davantage.

Comment devraient fonctionner le Téléchargement CSV et l’Inspection du Schéma ?

Commencez par traiter chaque téléchargement comme une entrée non fiable. Validez le type de fichier, la taille, l’encodage, le délimiteur, le nombre de lignes, le nombre de colonnes et les formules suspectes avant que le modèle ne soit impliqué. Un CSV peut encore contenir des valeurs qui déclenchent l’exécution de formules de tableur lorsqu’il est ouvert plus tard, donc les fichiers exportés doivent également être nettoyés pour le format cible.

Un flux de téléchargement pratique ressemble à ceci :

1. L’utilisateur télécharge un CSV vers l’application.
2. Le backend stocke le fichier original sous une clé objet ou un chemin de staging lié au travail.
3. Le backend crée une session sandbox pour le travail.
4. Le backend copie le fichier dans un répertoire de travail du sandbox.
5. Un petit script d’inspection déterministe lit le fichier et produit un résumé du schéma.
6. Le modèle reçoit le résumé du schéma, la question de l’utilisateur, les bibliothèques autorisées et les exigences de sortie.

L’étape d’inspection doit être un code déterministe que vous possédez, pas un code généré par le modèle. Elle peut produire un résumé JSON compact comme celui-ci :

{
  "file": "sales.csv",
  "rows": 84231,
  "columns": [
    {"name": "order_date", "type": "date", "null_rate": 0.01},
    {"name": "region", "type": "string", "sample_values": ["NA", "EMEA", "APAC"]},
    {"name": "revenue", "type": "number", "null_rate": 0.0}
  ],
  "safe_sample_rows": 5
}

Ce résumé donne au modèle suffisamment de contexte pour rédiger une analyse sans lui remettre l’ensemble du jeu de données. Pour les charges de travail sensibles, réduisez ou supprimez les valeurs d’exemple, masquez les colonnes, ou exigez que l’utilisateur approuve les colonnes pouvant être utilisées.

Comment le modèle génère-t-il et exécute-t-il Python en Toute Sécurité ?

Le modèle doit produire un plan avant de produire du code. Un bon plan nomme les colonnes qu’il utilisera, les transformations qu’il prévoit d’exécuter, les graphiques qu’il compte créer et les fichiers de sortie qu’il écrira. Cela donne à votre application un point de contrôle pour la politique et la révision par l’utilisateur.

Une fois le plan accepté, demandez du Python qui respecte un contrat étroit :

• Lire les fichiers d’entrée uniquement depuis un répertoire input/.
• Écrire les artefacts uniquement dans un répertoire output/.
• Utiliser uniquement les packages approuvés.
• Éviter les appels réseau sauf si la politique du travail les autorise explicitement.
• Imprimer un résumé structuré à la fin.
• Échouer clairement lorsque des colonnes requises sont manquantes.

Au niveau conceptuel, la boucle d’orchestration ressemble à ceci :

job = create_analysis_job(user_id, uploaded_file)
sandbox = create_sandbox(job_id=job.id, timeout_seconds=300)

copy_file_to_sandbox(uploaded_file, sandbox_path="/work/input/data.csv")
schema = run_owned_schema_inspector(sandbox, "/work/input/data.csv")

plan = ask_model_for_analysis_plan(
    user_question=job.question,
    schema=schema,
    allowed_packages=["pandas", "numpy", "matplotlib"],
    output_contract={"directory": "/work/output", "formats": ["png", "csv", "json"]},
)

review_policy(plan)

script = ask_model_for_python(plan=plan, schema=schema)
review_static_code_policy(script)

result = run_python_in_sandbox(
    sandbox=sandbox,
    script=script,
    working_dir="/work",
    timeout_seconds=120,
    memory_limit_mb=1024,
)

artifacts = collect_outputs(sandbox, "/work/output")
review_outputs(artifacts)
return_answer_to_user(result.summary, artifacts)

Ceci est du pseudo-code, pas un contrat SDK produit. L’important est la frontière : le code généré est examiné, exécuté avec un délai d’attente, contraint à des répertoires connus, et suivi d’une collecte et d’une révision des sorties.

Si le script échoue, renvoyez le message d’erreur et un petit extrait de code au modèle pour réparation. N’envoyez pas de logs illimités. La réparation des erreurs doit conserver la même politique de packages, fichiers, réseau et sortie que la première tentative.

Accès Contrôlé aux Packages Python pour l’Analyse de Données par IA

L’accès aux packages est l’endroit où de nombreuses démos d’AI Data Analyst deviennent risquées. Un modèle peut demander une bibliothèque parce qu’il l’a vue dans un tutoriel, parce qu’un nom de package semble plausible, ou parce que le prompt de l’utilisateur l’a suggérée. Votre application ne doit pas transformer ces suggestions en installations de packages non restreintes.

Utilisez une politique adaptée à la sensibilité des données :

Politique de package	Meilleur ajustement	Compromis
Image pré-construite uniquement	Charges de travail de production avec des besoins d’analyse prévisibles	Flexibilité la plus faible, surface de révision la plus simple
Liste blanche de packages	La plupart des assistants d’analyse CSV	Bon équilibre pour pandas, le traçage et les packages statistiques courants
Installations avec versions épinglées	Travaux d’analyse reproductibles	Nécessite une maintenance des packages et une révision des vulnérabilités
Miroir interne en cache	Entreprise ou flux de travail réglementés	Plus de travail opérationnel, meilleur contrôle de la chaîne d’approvisionnement
Installations approuvées par l’utilisateur	Outils exploratoires pour utilisateurs de confiance	Plus flexible, mais plus lent et nécessite des avertissements clairs

Pour une première version de production, commencez par un environnement pré-construit ou une courte liste blanche. La plupart des questions CSV peuvent être traitées avec un petit ensemble de bibliothèques : pandas, numpy, matplotlib, seaborn, scipy, et parfois scikit-learn. Si un travail nécessite un autre package, demandez au modèle d’expliquer pourquoi, puis acheminez cette demande via une approbation humaine ou un flux de révision de package.

Journalisez le nom du package, la version, le registre source, le temps d’installation et la raison pour laquelle le package a été demandé. Si votre équipe de sécurité utilise des scanners de dépendances ou des registres privés, intégrez ce processus au lieu de laisser l’agent le contourner.

Comment Valider les Graphiques et les Fichiers de Sortie

Les fichiers générés font partie de l’expérience produit, mais ils font également partie de la frontière de confiance. Un graphique peut être erroné. Un CSV peut contenir des valeurs de type formule. Un notebook peut inclure du code caché. Un ZIP peut contenir des chemins inattendus. Traitez les artefacts comme des sorties à inspecter, pas seulement comme des fichiers à télécharger.

Définissez un contrat de sortie simple :

{
  "required_files": ["summary.json"],
  "optional_files": ["chart-*.png", "filtered-data.csv"],
  "blocked_extensions": [".exe", ".sh", ".bat", ".html"],
  "max_total_size_mb": 25
}

Pour chaque travail terminé, collectez les fichiers uniquement depuis le répertoire de sortie attendu. Validez le type MIME, l’extension, la taille et le chemin. Pour les images, générez des miniatures pour l’aperçu. Pour les exportations CSV, échappez les formules de tableur si le fichier peut être ouvert dans Excel ou Google Sheets. Pour les résumés JSON, validez par rapport à un schéma avant de les utiliser dans l’interface utilisateur.

Offrez aux utilisateurs une étape de révision avant qu’ils ne téléchargent ou partagent les résultats. L’écran de révision doit montrer :

• La question originale.
• Le nom du jeu de données et le schéma utilisé.
• Les étapes de l’analyse en langage simple.
• Les graphiques et tableaux générés.
• Toute colonne exclue pour des raisons de politique.
• Avertissements, erreurs, tentatives ou demandes de packages.

Le modèle peut rédiger une explication narrative, mais l’application doit fonder cette explication sur les fichiers et les logs de l’exécution du sandbox.

Points de Contrôle de Sécurité Avant la Production

Un AI Data Analyst n’est un outil interne utile que si les équipes de sécurité et de plateforme peuvent raisonner sur ce qu’il est autorisé à faire. La révision doit couvrir l’isolation, les limites de ressources, la politique de packages, le comportement réseau, les secrets, les logs et la suppression.

Utilisez cette liste de contrôle avant de dépasser le stade du prototype :

Point de contrôle	Question à répondre
Frontière d’isolation	Qu’est-ce qui sépare le code et les fichiers d’un utilisateur de l’hôte et des autres utilisateurs ?
Accès aux fichiers	Le code généré peut-il lire uniquement le répertoire du travail, ou peut-il voir un stockage plus large ?
Limites de ressources	Qu’est-ce qui plafonne le temps CPU, la mémoire, le disque, le nombre de processus et le temps réel ?
Politique réseau	L’accès réseau sortant est-il désactivé, sur liste blanche, proxyé ou complètement ouvert ?
Politique de packages	Quels packages peuvent être installés, depuis où, et avec quels contrôles de version ?
Frontière des secrets	Les clés API, les identifiants de base de données et les jetons de service sont-ils gardés hors du sandbox sauf si explicitement délimités ?
Logs	Les commandes, installations de packages, erreurs, lectures/écritures de fichiers et artefacts de sortie sont-ils enregistrés ?
Révision humaine	Quels plans, extraits de code, demandes de packages et sorties nécessitent une approbation ?
Nettoyage	Quand l’état du sandbox, les fichiers téléchargés, les scripts générés, les logs et les sorties sont-ils supprimés ?

Évitez les affirmations absolues telles que “le code ne peut pas s’échapper” ou “les données ne peuvent pas fuir”. La norme pratique est plus concrète : définissez la frontière, documentez les contrôles, testez les modes de défaillance, et conservez suffisamment de piste d’audit pour enquêter sur un comportement inattendu.

Pour la politique réseau et de packages, rappelez-vous que l’installation de dépendances est une forme de sortie réseau à moins que les packages ne proviennent d’une image pré-construite ou d’un miroir contrôlé. Si le jeu de données est sensible, l’accès réseau doit être bloqué ou strictement listé par défaut. Si l’analyste a besoin de données externes en direct, faites-en un outil séparé avec sa propre approbation et son propre chemin de journalisation.

Utiliser Novita Agent Sandbox comme Couche d’Exécution

Novita Agent Sandbox fournit des environnements d’exécution isolés et avec état pour les agents IA. La documentation actuelle de Novita décrit la prise en charge de l’exécution de code, de l’installation de dépendances, de l’accès aux fichiers, de l’utilisation de navigateurs et de la préservation de l’état d’exécution entre les sessions. Pour un AI Data Analyst, ces primitives correspondent directement à la partie exécution de l’architecture : créer un espace de travail pour le travail, déplacer des fichiers, exécuter le code d’analyse, collecter les artefacts et nettoyer ou préserver l’état en fonction de la conception de la session.

La documentation du SDK et du CLI de Novita Agent Sandbox liste la prise en charge officielle du SDK pour Python et JavaScript/TypeScript, ce qui correspond aux backends d’application courants. La documentation du système de fichiers du sandbox décrit un système de fichiers isolé avec un espace de stockage fixe de 20 Go pour les sandbox, utile pour le staging des fichiers CSV et des artefacts générés dans un espace de travail dédié au travail.

Gardez la distinction claire :

• Les conseils de mise en œuvre dans cet article décrivent une architecture générale pour les applications AI Data Analyst.
• Novita Agent Sandbox peut fournir la couche d’exécution sandbox pour ces flux de travail.
• Votre application possède toujours l’authentification utilisateur, la politique de conservation des données, l’approbation des packages, la politique réseau, la révision des sorties et les décisions de publication/déploiement.

Cette séparation aide les équipes à construire avec un modèle de responsabilités clair. Le modèle suggère et explique l’analyse. L’application applique la politique produit. Le sandbox fournit l’environnement d’exécution contrôlé où le code, les fichiers, les packages, les graphiques et les logs peuvent être traités loin du serveur d’application principal.

Conclusion

La conception la plus solide pour un AI Data Analyst n’est pas “laisser le modèle exécuter Python”. C’est une boucle contrôlée : inspecter le jeu de données, demander un plan au modèle, examiner le code généré, l’exécuter dans un sandbox, collecter les artefacts validés, montrer à l’utilisateur ce qui s’est passé et nettoyer l’état une fois le travail terminé. Cette structure maintient l’expérience utilisateur rapide tout en donnant aux équipes d’ingénierie et de sécurité des points de contrôle concrets à évaluer avant la production.

Pour les équipes qui construisent ce modèle, commencez petit : téléchargement CSV, inspection du schéma, une courte liste blanche de packages, sortie de graphiques, délais d’attente stricts et un écran de révision visible. Ajoutez un accès élargi aux packages, des outils réseau, de la persistance et de l’automatisation uniquement après que les frontières sont documentées et testées.

FAQ

Pourquoi un AI Data Analyst a-t-il besoin d’un sandbox ?

Il a besoin d’un sandbox car le flux de travail combine des fichiers non fiables, du code Python généré par le modèle, des demandes de packages, la génération de graphiques et des artefacts téléchargeables. Exécuter ce travail dans un environnement séparé donne à votre application un endroit pour appliquer des contrôles sur les fichiers, les ressources, les packages, le réseau, la journalisation et le nettoyage.

Le modèle doit-il voir le CSV complet ?

Généralement non. Commencez par envoyer au modèle un résumé du schéma, des échantillons sûrs, des descriptions de colonnes et la question de l’utilisateur. Gardez le fichier brut dans le sandbox, sauf si votre produit a une raison examinée d’exposer plus de données au modèle.

Les installations de packages peuvent-elles être autorisées ?

Oui, mais elles doivent être contrôlées. Utilisez une image pré-construite, une liste blanche, des versions épinglées, un miroir privé ou un flux d’approbation. Ne laissez pas le code généré par le modèle installer des packages arbitraires depuis Internet public sans révision.

Quels fichiers l’application doit-elle retourner aux utilisateurs ?

Retournez uniquement les fichiers validés provenant d’un répertoire de sortie connu, comme des images de graphiques, un JSON de résumé et des exportations CSV nettoyées. Bloquez les extensions inattendues, les fichiers volumineux, les chemins cachés et les artefacts qui ne faisaient pas partie du contrat de sortie.

Est-ce une garantie de conformité ?

Non. Un sandbox est une partie de l’architecture d’exécution. L’approbation de conformité et de sécurité dépend de vos données, de votre modèle de menace, de vos contrôles, de votre journalisation, de votre conservation, de votre processus de révision et de votre environnement de déploiement.

Articles recommandés

• Exécuter Codex ou un agent de codage dans un sandbox sécurisé
• Serveurs MCP dans des sandbox isolés : fichiers, secrets et compromis réseau
• Firecracker pour les sandbox d’agents IA : avantages, limites et questions d’évaluation