La réponse en bref
Les sandboxes Cloud Run vous permettent d'exécuter du code non fiable ou généré par IA à l'intérieur de votre service Cloud Run existant, isolé de sorte qu'il ne peut, par défaut, ni lire vos variables d'environnement, ni appeler le serveur de métadonnées, ni atteindre le réseau. Google a annoncé la préversion publique le 10 juillet 2026 au WeAreDevelopers World Congress. Les sandboxes démarrent en quelques millisecondes ; dans une démonstration, un seul service a démarré, exécuté et arrêté 1 000 d'entre elles avec une latence moyenne de 500 ms. Comme elles partagent le CPU et la mémoire déjà alloués à votre instance, leur utilisation n'entraîne aucun surcoût, et la préversion est gratuite.
La lecture pratique pour les responsables techniques : la partie la plus difficile de la mise en production d'un agent IA qui écrit et exécute du code — le faire sans confier vos identifiants cloud à un LLM — devient sur Google Cloud un standard géré et bon marché. Cela ne remplace pas la modélisation des menaces, mais retire aux équipes un gros morceau de plomberie de sécurité indifférenciée qu'elles bâtissaient à la main.
Qu'a réellement livré Google ?
Le 10 juillet 2026, au WeAreDevelopers World Congress, Google Cloud a placé les sandboxes Cloud Run en préversion publique. Une sandbox est une frontière d'exécution légère et isolée que vous créez quasi instantanément à l'intérieur d'une instance de service Cloud Run existante. Au lieu de monter un cluster de conteneurs distinct ou de payer un service de micro-VM spécialisé, votre application crée un environnement jetable et verrouillé sur la capacité de calcul dont elle dispose déjà, y exécute du code non fiable, puis le démantèle.
Le problème qu'elle vise est précis et de plus en plus courant : comment exécuter en toute sécurité du code écrit par un LLM, ou soumis par un utilisateur, sans mettre en danger votre application hôte, vos données et vos identifiants Google Cloud ? Google présente cela comme une réponse à un changement qu'elle observe dans la conception des applications, où laisser un modèle écrire et exécuter du code — pour l'analyse de données, la navigation ou l'automatisation — devient une partie ordinaire du produit plutôt qu'un cas limite exotique. C'est le même schéma que nous rencontrons sans cesse lorsque des clients nous demandent de construire des fonctionnalités agentiques : l'agent n'est utile que s'il peut agir, et agir signifie souvent exécuter du code que vous n'avez pas écrit et auquel vous ne pouvez pas pleinement vous fier.
Google pointe trois cas d'usage concrets. Les interpréteurs de code LLM laissent un modèle écrire et exécuter du Python, du R ou du SQL pour analyser un jeu de données, générer des graphiques ou effectuer des calculs lourds à la demande. Les navigateurs headless offrent à un agent un espace confiné pour extraire des pages, prendre des captures d'écran et automatiser des workflows web. Et le bon vieux code soumis par les utilisateurs — plugins, scripts, soumissions de concours — peut s'exécuter sans devenir un point d'entrée dans votre service. Les sandboxes sont aussi intégrées à l'Agent Development Kit (ADK) de Google : un nouveau CloudRunSandboxCodeExecutor permet à un agent ADK s'exécutant sur Cloud Run d'exécuter du code en une seule ligne, et les applications peuvent également créer des sandboxes directement avec des appels de sous-processus standard.
Comment fonctionne l'isolation ?
Le modèle de sécurité repose sur trois frontières, et il vaut la peine de les comprendre précisément car elles définissent ce que la fonctionnalité protège et ce qu'elle ne protège pas. La première est l'isolation des identifiants : une sandbox ne peut pas lire les variables d'environnement du service Cloud Run et ne peut pas appeler le serveur de métadonnées Google Cloud. Cela compte, car le serveur de métadonnées est la voie habituelle par laquelle une charge de travail obtient ses jetons de compte de service ; coupé de lui, le code s'exécutant dans la sandbox n'a aucun chemin vers votre identité ou vos secrets, même s'il les cherche.
La deuxième est le trafic réseau sortant, refusé par défaut. D'origine, une sandbox n'a aucun accès réseau sortant ; si le code doit atteindre une API, vous activez explicitement la sortie pour cet appel plutôt que de laisser une porte ouverte. Pour quiconque a déjà vu du code malveillant tenter d'exfiltrer des données ou de « téléphoner à la maison », une posture réseau refusant par défaut est exactement la bonne forme. La troisième est une surcouche de système de fichiers sûre : la sandbox voit le système de fichiers de votre conteneur en lecture seule — elle peut donc utiliser vos paquets, runtimes et binaires installés — mais écrit tout dans une surcouche en mémoire isolée et temporaire qui est supprimée à la fin de l'exécution. Rien de ce que le code écrit ne survit, et rien de ce qu'il fait ne modifie votre service en cours d'exécution.
Deux faits opérationnels complètent le tableau. Côté performance, les sandboxes démarrent en quelques millisecondes, et la démonstration de Google en a fait passer 1 000 par un cycle complet démarrage-exécution-arrêt à une moyenne de 500 ms chacune — assez rapide pour rendre réaliste le sandboxing par requête plutôt qu'une astuce réservée au batch. Côté coût, comme elles s'exécutent sur le CPU et la mémoire déjà alloués à votre instance plutôt que sur des VM dédiées, Google indique qu'il n'y a aucun surcoût pour utiliser la fonctionnalité, et qu'elle est gratuite pendant la préversion publique. Ce modèle tarifaire est le titre discret : l'exécution de code isolée signifiait historiquement payer un hôte de sandbox spécialisé par invocation ; l'intégrer dans du calcul serverless que vous payez déjà change l'économie.
Pourquoi est-ce important maintenant ?
L'exécution de code sécurisée est discrètement devenue l'un des problèmes porteurs de l'ère des agents. Tout framework d'agent sérieux finit par se heurter au même mur : pour être utile, l'agent doit exécuter du code, et exécuter du code arbitraire à côté de votre application est la façon de perdre vos données ou votre compte cloud. Les équipes l'ont résolu avec gVisor, des micro-VM Firecracker, des startups de sandbox dédiées ou une isolation Kubernetes élaborée — tout cela fonctionne, et tout cela représente un vrai travail d'ingénierie et un vrai coût opérationnel. Une sandbox gérée qui vit à l'intérieur de votre runtime serverless existant abaisse cette barrière pour une large catégorie d'applications.
Cela fait aussi partie d'une tendance visible chez les grands clouds. Google déploie des primitives d'isolation pour les agents aux deux extrémités de son spectre de calcul — une GKE Agent Sandbox pour les charges de travail à forte composante Kubernetes, et désormais les sandboxes Cloud Run pour le côté serverless. Si votre stratégie de plateforme s'appuie sur Kubernetes, la voie GKE peut convenir ; si vous êtes déjà serverless-first sur Cloud Run, les nouvelles sandboxes vous rejoignent là où vous en êtes. Dans tous les cas, le signal est que les hyperscalers traitent désormais « exécuter ce code non fiable en toute sécurité » comme une capacité de plateforme de premier ordre plutôt que comme quelque chose que chaque équipe réinvente.
Ce que cela signifie pour les équipes logicielles US & UE
En retirant l'effet d'annonce, trois implications durables demeurent. La première est que l'exécution en sandbox est désormais le standard attendu pour les agents qui exécutent du code. Si vous construisez une fonctionnalité IA qui écrit et exécute du code, la laisser s'exécuter dans le processus n'est plus défendable — l'outillage pour l'isoler est bon marché et disponible. Concevez la frontière d'exécution dès le départ ; ajouter l'isolation après un incident est la voie coûteuse, et l'incident est du genre à finir dans un rapport de violation.
La deuxième est que l'isolation est un contrôle, pas un certificat de conformité. Les sandboxes Cloud Run coupent les identifiants, le réseau et la persistance, ce qui referme les trous les plus dangereux — mais si vous opérez dans la FinTech ou traitez des données réglementées, les questions les plus difficiles vous appartiennent toujours : quelles données vous laissez entrer dans la sandbox, où la sortie est autorisée à aller, comment vous journalisez et révisez ce que l'agent a exécuté, et comment tout cela s'applique au RGPD, à SOC 2 ou aux règles de votre secteur. Traitez la sandbox comme une couche d'une conception de défense en profondeur et gardez-la dans votre revue de sécurité habituelle plutôt que de supposer qu'une fonctionnalité gérée fait disparaître le modèle de menace.
La troisième est architecturale et transcende les fournisseurs : gardez la couche d'exécution interchangeable. Les sandboxes Cloud Run sont attrayantes, mais les alternatives le sont aussi, et le paysage de l'isolation évolue vite. Placez l'exécution de code de l'agent derrière une interface propre afin de pouvoir l'exécuter sur Cloud Run aujourd'hui et la déplacer — vers GKE, vers un autre cloud, vers une sandbox auto-hébergée — sans réécrire l'agent. Cette portabilité est bon marché à construire maintenant et pénible à ajouter plus tard, et c'est la même discipline qui garde n'importe quelle plateforme cloud maintenable à mesure que les fournisseurs changent leurs conditions et leurs capacités.
Que faire maintenant
Voici la version livrable. Traitez les sandboxes Cloud Run comme une incitation à bien construire l'histoire d'exécution de code de votre agent, que vous adoptiez ou non cette fonctionnalité précise.
- Isolez l'exécution de code par défaut. Si un agent ou un utilisateur peut exécuter du code, il ne devrait jamais s'exécuter dans le processus de votre application avec accès à vos identifiants.
- Refusez le réseau et les secrets, puis accordez de façon étroite. Partez de zéro sortie et d'aucun accès aux identifiants ; n'ouvrez que les chemins précis dont une tâche a réellement besoin.
- Gardez la couche sandbox interchangeable. Placez l'exécution derrière une interface pour que Cloud Run, GKE ou une autre sandbox puisse la porter sans réécrire l'agent.
- Journalisez ce que l'agent a exécuté. Capturez les entrées, le code et les sorties pour l'audit et la revue d'incident ; une surcouche supprimée est une bonne hygiène mais pas une piste d'audit.
- Intégrez-la à votre modèle de menace. Une sandbox gérée est un contrôle ; révisez-la aux côtés des flux de données, des règles de sortie et de vos obligations de conformité.
- Pilotez avant de vous engager. Les fonctionnalités en préversion changent ; validez la latence, les limites et le comportement sur votre charge de travail réelle avant qu'elle ne se retrouve sur un chemin critique.
Rien de tout cela n'est un conseil juridique, et vos obligations exactes dépendent de votre secteur et de votre juridiction. Mais le signal stratégique est clair : exécuter du code écrit par IA en toute sécurité devient un standard résolu et bon marché sur les grands clouds, et les équipes qui gagnent sont celles qui conçoivent l'isolation tôt, la gardent interchangeable et traitent la sandbox comme un contrôle au sein d'une posture de sécurité plus large.
Questions fréquentes
Que sont les sandboxes Cloud Run ?
Les sandboxes Cloud Run sont des frontières d'exécution légères et isolées que vous créez quasi instantanément à l'intérieur d'une instance de service Google Cloud Run existante pour exécuter en toute sécurité du code non fiable ou généré par IA. Google les a placées en préversion publique le 10 juillet 2026. Une sandbox n'a pas accès aux variables d'environnement du service, ne peut pas appeler le serveur de métadonnées Google Cloud et n'a, par défaut, aucun accès réseau sortant, de sorte que le code écrit par un LLM ne peut pas atteindre vos identifiants ni vos données à moins que vous ne l'autorisiez explicitement.
Quelle est la rapidité et le coût des sandboxes Cloud Run ?
Les sandboxes démarrent en quelques millisecondes. Dans la démonstration de Google, un seul service Cloud Run a démarré, exécuté et arrêté 1 000 sandboxes avec une latence moyenne de 500 ms. Côté coût, les sandboxes s'exécutent sur le CPU et la mémoire déjà alloués à votre instance Cloud Run en cours, plutôt que sur des VM dédiées distinctes, de sorte qu'il n'y a aucun surcoût pour utiliser la fonctionnalité, et elle est gratuite pendant la préversion publique.
Pourquoi les agents IA ont-ils besoin d'une sandbox de code ?
Les agents IA écrivent et exécutent de plus en plus leur propre code, ou exécutent du code et des scripts soumis par des utilisateurs. Exécuter ce code non fiable dans le même processus que votre application expose votre hôte, vos données et vos identifiants cloud si le code est malveillant ou simplement erroné. Une sandbox isole l'exécution, de sorte qu'un interpréteur de code LLM peut exécuter du Python, du R ou du SQL, ou qu'un navigateur headless peut extraire une page, sans pouvoir lire vos secrets ni atteindre le réseau à moins que vous ne l'accordiez.
Comment les sandboxes Cloud Run isolent-elles le code non fiable ?
Trois frontières. D'abord, les identifiants : les sandboxes ne peuvent pas lire les variables d'environnement du service Cloud Run et ne peuvent pas appeler le serveur de métadonnées Google Cloud, elles ne peuvent donc pas obtenir vos jetons de compte de service. Ensuite, le réseau : l'accès sortant est refusé par défaut et doit être explicitement activé pour chaque appel. Enfin, le système de fichiers : la sandbox voit le système de fichiers de votre conteneur en lecture seule et écrit les modifications dans une surcouche temporaire en mémoire qui est supprimée à la fin de l'exécution, de sorte que rien de ce qu'elle fait ne persiste dans votre service.
Comment utiliser les sandboxes Cloud Run dans un agent ?
Votre application peut créer des sandboxes par programmation avec des appels de sous-processus standard, et l'Agent Development Kit (ADK) de Google fournit un CloudRunSandboxCodeExecutor pour qu'un agent ADK s'exécutant sur Cloud Run puisse exécuter du code en une seule ligne. La fonctionnalité vise trois cas courants : les interpréteurs de code LLM pour l'analyse de données, les navigateurs headless pour les tâches web des agents et l'exécution sûre de scripts ou de plugins soumis par des utilisateurs.
Sources
Google Cloud Blog — Google Cloud Run sandboxes are in public preview
SecurityBrief Australia — Google Cloud puts Cloud Run sandboxes into preview
Google Cloud Documentation — Code execution in Cloud Run