La risposta in breve
Le sandbox Cloud Run ti permettono di eseguire codice non attendibile o generato dall'IA all'interno del tuo servizio Cloud Run esistente, isolato in modo che, per impostazione predefinita, non possa né leggere le tue variabili d'ambiente, né chiamare il server dei metadati, né raggiungere la rete. Google ha annunciato l'anteprima pubblica il 10 luglio 2026 al WeAreDevelopers World Congress. Le sandbox si avviano in millisecondi; in una demo, un singolo servizio ne ha avviate, eseguite e arrestate 1.000 con una latenza media di 500 ms. Poiché condividono la CPU e la memoria già allocate alla tua istanza, il loro utilizzo non comporta alcun sovrapprezzo, e l'anteprima è gratuita.
La lettura pratica per i responsabili tecnici: la parte più difficile del rilascio di un agente IA che scrive ed esegue codice — farlo senza consegnare le tue credenziali cloud a un LLM — su Google Cloud diventa uno standard gestito ed economico. Non sostituisce la modellazione delle minacce, ma toglie ai team un grosso pezzo di infrastruttura di sicurezza indifferenziata che costruivano a mano.
Cosa ha rilasciato davvero Google?
Il 10 luglio 2026, al WeAreDevelopers World Congress, Google Cloud ha portato le sandbox Cloud Run in anteprima pubblica. Una sandbox è un confine di esecuzione leggero e isolato che crei quasi istantaneamente all'interno di un'istanza di servizio Cloud Run esistente. Invece di predisporre un cluster di container separato o pagare per un servizio di micro-VM specializzato, la tua applicazione crea un ambiente usa e getta e blindato sulla capacità di calcolo di cui già dispone, vi esegue del codice non attendibile e poi lo smantella.
Il problema che affronta è specifico e sempre più comune: come esegui in sicurezza codice scritto da un LLM, o inviato da un utente, senza mettere a rischio la tua applicazione host, i tuoi dati e le tue credenziali Google Cloud? Google lo presenta come una risposta a un cambiamento che osserva nel design delle applicazioni, in cui lasciare che un modello scriva ed esegua codice — per l'analisi dei dati, la navigazione o l'automazione — sta diventando una parte ordinaria del prodotto anziché un caso limite esotico. È lo stesso schema che incontriamo di continuo quando i clienti ci chiedono di costruire funzionalità agentiche: l'agente è utile solo se può agire, e agire spesso significa eseguire codice che non hai scritto e di cui non puoi fidarti del tutto.
Google indica tre casi d'uso concreti. Gli interpreti di codice LLM lasciano che un modello scriva ed esegua Python, R o SQL per analizzare un set di dati, generare grafici o svolgere calcoli impegnativi su richiesta. I browser headless danno a un agente un luogo confinato in cui estrarre pagine, catturare screenshot e automatizzare flussi di lavoro web. E il classico codice inviato dagli utenti — plugin, script, proposte per contest — può girare senza diventare un punto d'appoggio verso il tuo servizio. Le sandbox vengono inoltre integrate nell'Agent Development Kit (ADK) di Google: un nuovo CloudRunSandboxCodeExecutor permette a un agente ADK in esecuzione su Cloud Run di eseguire codice in una sola riga, e le applicazioni possono anche creare sandbox direttamente con chiamate di sottoprocesso standard.
Come funziona l'isolamento?
Il modello di sicurezza poggia su tre confini, e vale la pena comprenderli con precisione perché definiscono ciò che la funzionalità protegge e ciò che non protegge. Il primo è l'isolamento delle credenziali: una sandbox non può leggere le variabili d'ambiente del servizio Cloud Run e non può chiamare il server dei metadati di Google Cloud. Ciò è cruciale, perché il server dei metadati è la via consueta con cui un carico di lavoro ottiene i token del proprio account di servizio; tagliato fuori da esso, il codice in esecuzione nella sandbox non ha alcun percorso verso la tua identità o i tuoi segreti, anche se li va a cercare.
Il secondo è il traffico di rete in uscita, negato per impostazione predefinita. Di base una sandbox non ha alcun accesso di rete in uscita; se il codice deve raggiungere un'API, abiliti la sortita esplicitamente per quella chiamata anziché lasciare una porta aperta. Per chiunque abbia visto codice malevolo tentare di esfiltrare dati o «telefonare a casa», una postura di rete che nega per impostazione predefinita è esattamente la forma giusta. Il terzo è un overlay del file system sicuro: la sandbox vede il file system del tuo container in sola lettura — quindi può usare i tuoi pacchetti, runtime e binari installati — ma scrive tutto in un overlay in memoria isolato e temporaneo che viene eliminato al termine dell'esecuzione. Nulla di ciò che il codice scrive sopravvive, e nulla di ciò che fa modifica il tuo servizio in esecuzione.
Due fatti operativi completano il quadro. Sulla performance, le sandbox si avviano in millisecondi, e la demo di Google ne ha fatte passare 1.000 attraverso un ciclo completo di avvio-esecuzione-arresto a una media di 500 ms ciascuna — abbastanza veloce da rendere realistico il sandboxing per singola richiesta anziché un trucco riservato al batch. Sul costo, poiché girano sulla CPU e sulla memoria già allocate alla tua istanza anziché su VM dedicate, Google afferma che non c'è alcun sovrapprezzo per usare la funzionalità, ed è gratuita durante l'anteprima pubblica. Questo modello di prezzo è il titolo sommesso: l'esecuzione di codice isolata storicamente significava pagare un host di sandbox specializzato per ogni invocazione; integrarla nel calcolo serverless che già paghi cambia l'economia.
Perché è importante ora?
L'esecuzione sicura del codice è diventata silenziosamente uno dei problemi portanti dell'era degli agenti. Ogni framework di agenti serio finisce per sbattere contro lo stesso muro: per essere utile, l'agente deve eseguire codice, ed eseguire codice arbitrario accanto alla tua applicazione è il modo in cui perdi i tuoi dati o il tuo account cloud. I team lo hanno risolto con gVisor, micro-VM Firecracker, startup dedicate alle sandbox o un'elaborata isolazione Kubernetes — tutte soluzioni che funzionano, e tutte con un vero costo di ingegneria e operativo. Una sandbox gestita che vive all'interno del tuo runtime serverless esistente abbassa quella barriera per un'ampia categoria di applicazioni.
È anche parte di una tendenza visibile tra i grandi cloud. Google sta rilasciando primitive di isolamento per gli agenti a entrambe le estremità del suo spettro di calcolo — una GKE Agent Sandbox per i carichi di lavoro con forte componente Kubernetes, e ora le sandbox Cloud Run per il lato serverless. Se la tua strategia di piattaforma si appoggia su Kubernetes, il percorso GKE può andare bene; se sei già serverless-first su Cloud Run, le nuove sandbox ti vengono incontro dove ti trovi. In ogni caso, il segnale è che gli hyperscaler ora trattano «esegui questo codice non attendibile in sicurezza» come una capacità di piattaforma di prima classe anziché come qualcosa che ogni team reinventa.
Cosa significa per i team software di USA e UE
Tolto l'effetto annuncio, restano tre implicazioni durature. La prima è che l'esecuzione in sandbox è ormai lo standard atteso per gli agenti che eseguono codice. Se stai costruendo una funzionalità IA che scrive ed esegue codice, lasciarla girare nel processo non è più difendibile — gli strumenti per isolarla sono economici e disponibili. Progetta il confine di esecuzione fin dall'inizio; aggiungere l'isolamento dopo un incidente è la via costosa, e l'incidente è di quelli che finiscono in un rapporto di violazione.
La seconda è che l'isolamento è un controllo, non un certificato di conformità. Le sandbox Cloud Run tagliano fuori credenziali, rete e persistenza, chiudendo i buchi più pericolosi — ma se operi nel FinTech o tratti dati regolamentati, restano tue le domande più difficili: quali dati lasci entrare nella sandbox, dove è consentito andare al traffico in uscita, come registri e riesamini ciò che l'agente ha eseguito, e come tutto questo si mappa su GDPR, SOC 2 o le regole del tuo settore. Tratta la sandbox come un livello in un design di difesa in profondità e tienila all'interno della tua normale revisione di sicurezza anziché supporre che una funzionalità gestita faccia sparire il modello di minaccia.
La terza è architetturale e vale trasversalmente ai fornitori: mantieni il livello di esecuzione intercambiabile. Le sandbox Cloud Run sono allettanti, ma lo sono anche le alternative, e il panorama dell'isolamento si muove in fretta. Metti l'esecuzione del codice dell'agente dietro un'interfaccia pulita così da poterla eseguire oggi su Cloud Run e spostarla — su GKE, su un altro cloud, su una sandbox self-hosted — senza riscrivere l'agente. Questa portabilità è economica da costruire ora e dolorosa da aggiungere dopo, ed è la stessa disciplina che mantiene manutenibile qualunque piattaforma cloud quando i fornitori cambiano condizioni e capacità.
Cosa fare ora
Ecco la versione operativa. Tratta le sandbox Cloud Run come uno stimolo a impostare correttamente la storia di esecuzione del codice del tuo agente, che tu adotti o meno questa funzionalità specifica.
- Isola l'esecuzione del codice per impostazione predefinita. Se un agente o un utente può eseguire codice, non dovrebbe mai girare nel processo della tua applicazione con accesso alle tue credenziali.
- Nega rete e segreti, poi concedi in modo mirato. Parti da zero traffico in uscita e nessun accesso alle credenziali; apri solo i percorsi specifici di cui un'attività ha davvero bisogno.
- Mantieni il livello sandbox intercambiabile. Metti l'esecuzione dietro un'interfaccia così che Cloud Run, GKE o un'altra sandbox possano sostenerla senza riscrivere l'agente.
- Registra ciò che l'agente ha eseguito. Cattura input, codice e output per l'audit e la revisione degli incidenti; un overlay eliminato è buona igiene ma non una pista di controllo.
- Integrala nel tuo modello di minaccia. Una sandbox gestita è un controllo; riesaminala insieme ai flussi di dati, alle regole del traffico in uscita e ai tuoi obblighi di conformità.
- Fai un pilota prima di impegnarti. Le funzionalità in anteprima cambiano; convalida latenza, limiti e comportamento sul tuo carico di lavoro reale prima che finisca su un percorso critico.
Nulla di tutto ciò è un parere legale, e i tuoi obblighi precisi dipendono dal tuo settore e dalla tua giurisdizione. Ma il segnale strategico è chiaro: eseguire in sicurezza codice scritto dall'IA sta diventando uno standard risolto ed economico sui grandi cloud, e a vincere sono i team che progettano l'isolamento presto, lo mantengono intercambiabile e trattano la sandbox come un controllo all'interno di una postura di sicurezza più ampia.
Domande frequenti
Cosa sono le sandbox Cloud Run?
Le sandbox Cloud Run sono confini di esecuzione leggeri e isolati che crei quasi istantaneamente all'interno di un'istanza di servizio Google Cloud Run esistente per eseguire in sicurezza codice non attendibile o generato dall'IA. Google le ha portate in anteprima pubblica il 10 luglio 2026. Una sandbox non ha accesso alle variabili d'ambiente del servizio, non può chiamare il server dei metadati di Google Cloud e per impostazione predefinita non ha alcun accesso di rete in uscita, quindi il codice scritto da un LLM non può raggiungere le tue credenziali o i tuoi dati a meno che tu non lo consenta esplicitamente.
Quanto sono veloci e quanto costano le sandbox Cloud Run?
Le sandbox si avviano in millisecondi. Nella dimostrazione di Google, un singolo servizio Cloud Run ha avviato, eseguito e arrestato 1.000 sandbox con una latenza media di 500 ms. Sul fronte dei costi, le sandbox girano sulla CPU e sulla memoria già allocate alla tua istanza Cloud Run in esecuzione, anziché su VM dedicate separate, quindi non c'è alcun sovrapprezzo per usare la funzionalità, ed è gratuita durante l'anteprima pubblica.
Perché gli agenti IA hanno bisogno di una sandbox per il codice?
Gli agenti IA scrivono ed eseguono sempre più spesso il proprio codice, oppure eseguono codice e script inviati dagli utenti. Eseguire quel codice non attendibile nello stesso processo della tua applicazione espone il tuo host, i tuoi dati e le tue credenziali cloud se il codice è malevolo o semplicemente sbagliato. Una sandbox isola l'esecuzione, così un interprete di codice LLM può eseguire Python, R o SQL, oppure un browser headless può estrarre una pagina, senza poter leggere i tuoi segreti né raggiungere la rete a meno che tu non lo conceda.
Come isolano il codice non attendibile le sandbox Cloud Run?
Tre confini. Primo, le credenziali: le sandbox non possono leggere le variabili d'ambiente del servizio Cloud Run e non possono chiamare il server dei metadati di Google Cloud, quindi non possono ottenere i token del tuo account di servizio. Secondo, la rete: l'accesso in uscita è negato per impostazione predefinita e deve essere abilitato esplicitamente per ogni chiamata. Terzo, il file system: la sandbox vede il file system del tuo container in sola lettura e scrive le modifiche in un overlay temporaneo in memoria che viene eliminato al termine dell'esecuzione, così nulla di ciò che fa persiste nel tuo servizio.
Come si usano le sandbox Cloud Run in un agente?
La tua applicazione può creare le sandbox in modo programmatico con chiamate di sottoprocesso standard, e l'Agent Development Kit (ADK) di Google fornisce un CloudRunSandboxCodeExecutor perché un agente ADK in esecuzione su Cloud Run possa eseguire codice in una sola riga. La funzionalità punta a tre schemi comuni: interpreti di codice LLM per l'analisi dei dati, browser headless per le attività web degli agenti ed esecuzione sicura di script o plugin inviati dagli utenti.
Fonti
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