Per oltre un decennio abbiamo costruito il cloud intorno a container, Pod e microservizi. L’arrivo degli AI Agent cambia il problema: non dobbiamo più decidere soltanto dove eseguire un’applicazione, ma soprattutto fino a dove possiamo permettere a un agente autonomo di arrivare.
Docker ha standardizzato il container. Kubernetes ha trasformato il Pod nell’unità operativa attraverso cui distribuire, scalare e gestire applicazioni moderne.
Con gli AI Agent, però, questo modello inizia a mostrare un limite strutturale.
Un agente AI non è semplicemente un altro microservizio.
Un microservizio tradizionale esegue codice deterministico sviluppato, testato e distribuito dall’organizzazione. Riceve una richiesta, esegue una funzione relativamente prevedibile e restituisce una risposta.
Un agente può invece decidere dinamicamente quali azioni eseguire.
Può interrogare database, chiamare API, utilizzare strumenti tramite MCP, creare file, eseguire codice Python, aprire una sessione shell, consultare documenti aziendali, interrogare sistemi RAG, avviare processi o coordinare altri agenti.
In alcuni scenari può persino generare il codice che eseguirà pochi secondi dopo.
Dal container al perimetro di esecuzione
Consideriamo un normale backend sviluppato con NestJS. Possiamo distribuirlo in un container Docker e orchestrarlo attraverso Kubernetes.
Conosciamo il codice, le dipendenze, le porte di rete e, almeno approssimativamente, le risorse necessarie.
Un agente AI presenta caratteristiche diverse.
Immaginiamo un agente dedicato all’analisi finanziaria che riceva questa richiesta:
confrontali con il budget e individua eventuali anomalie."
Per completare il compito potrebbe interrogare il database aziendale, recuperare documenti, generare query SQL, scrivere codice Python, eseguirlo, creare file temporanei, interrogare uno o più LLM e utilizzare altri agenti.
Non sta semplicemente eseguendo una funzione. Sta costruendo dinamicamente un percorso di esecuzione.
Ed è proprio questa autonomia che rende insufficiente considerare l’agente soltanto come un processo dentro un container.
Il vero problema è il blast radius
Se questo agente sbaglia, fino a dove può arrivare?
Questa dovrebbe diventare una delle domande fondamentali nella progettazione di sistemi agentici enterprise.
Supponiamo che un agente disponga di una shell Linux. Se nello stesso ambiente trova anche credenziali del database, accesso alla rete interna e filesystem condivisi, un errore può produrre conseguenze molto più ampie del task originale.
Non è necessario immaginare un attacco sofisticato.
Può bastare un’interpretazione sbagliata di un’istruzione, un tool richiamato con parametri errati o una prompt injection contenuta in un documento elaborato dall’agente.
La conseguenza architetturale è netta: dobbiamo assumere che una parte dell’esecuzione agentica possa essere non affidabile.
Il Sandbox come nuova unità dell’agente
Il modello tradizionale:
può quindi evolvere verso:
Il cambiamento sembra minimo. In realtà modifica profondamente il modo di progettare l’infrastruttura.
Il sandbox non è semplicemente un altro container: diventa il confine operativo dell’agente.
All’interno di quel confine possiamo definire CPU, RAM, GPU, filesystem, accesso alla rete, credenziali, durata dell’esecuzione, strumenti utilizzabili, policy di sicurezza, logging, audit e persistenza.
I container non sono sempre un confine sufficiente
I container Linux tradizionali offrono un eccellente compromesso tra isolamento, densità e prestazioni. Ma normalmente condividono il kernel dell’host.
Per applicazioni controllate è spesso una scelta perfettamente ragionevole.
Per ambienti capaci di eseguire codice generato dinamicamente, il livello di isolamento richiesto può però essere superiore.
Da qui l’interesse crescente verso tecnologie come gVisor, Kata Containers e Firecracker.
gVisor introduce un ulteriore livello tra applicazione e kernel host. Kata Containers utilizza la virtualizzazione hardware per fornire un isolamento più vicino a quello di una macchina virtuale mantenendo un’esperienza compatibile con il mondo container. Firecracker porta il concetto verso microVM leggere e rapidamente istanziabili.
Non esiste necessariamente un runtime corretto per ogni workload.
Un agente interno che utilizza esclusivamente API controllate potrebbe richiedere un isolamento relativamente leggero. Un agente autorizzato a generare ed eseguire codice arbitrario potrebbe invece essere confinato in una microVM.
Kubernetes cambia ruolo
Kubernetes rimane centrale, ma cambia il livello di astrazione.
Oggi ragioniamo principalmente attraverso risorse come Pod, Deployment, Service e Job.
Nelle infrastrutture agentiche inizieremo sempre più a ragionare in termini di Agent, Sandbox, Sandbox Template, Sandbox Pool e Agent Job.
L’orchestratore non deve sapere soltanto dove avviare un processo. Deve conoscere anche quale ambiente di sicurezza è necessario per quel processo.
Tre agenti, tre perimetri completamente diversi
MCP non risolve questo problema
Il Model Context Protocol sta rendendo più semplice collegare gli agenti a strumenti e sistemi esterni.
Ma MCP e sandbox risolvono problemi differenti.
“Come può l’agente utilizzare uno strumento?”
Il Sandbox risponde alla domanda:
“Dove può farlo, con quali privilegi e fino a quali limiti?”
Sono quindi due livelli complementari, non alternativi.
Da dieci agenti a centomila agenti
Molti sistemi attuali utilizzano pochi agenti relativamente persistenti. È improbabile che questo rimanga il modello dominante.
Potremmo avere agenti estremamente specializzati e temporanei.
Un Research Agent potrebbe generare un agente per cercare documenti, uno per analizzare dati, uno per verificare le fonti, uno per confrontare risultati e un altro per produrre il report finale.
Ognuno potrebbe vivere soltanto alcuni secondi.
Quando il modello diventa questo, il tempo necessario per creare un ambiente isolato diventa una metrica infrastrutturale fondamentale.
Se servono trenta secondi per creare il sandbox, molti workflow diventano impraticabili. Se può essere assegnato quasi immediatamente, possiamo costruire sistemi completamente differenti.
Warm pool: sandbox già pronti
Una possibile risposta è mantenere pool di ambienti preinizializzati.
Quando nasce un nuovo agente non è necessario costruire l’intero ambiente da zero: gli viene assegnato un sandbox già disponibile, configurato secondo un template specifico.
È concettualmente simile ai connection pool dei database, ma applicato agli ambienti di esecuzione.
Anche lo scheduling dovrà cambiare
Quando i task agentici diventano migliaia o milioni, non conta soltanto dove si trova una GPU libera.
Conta dove si trovano GPU, modello, dati e servizi.
Immaginiamo un’infrastruttura distribuita tra Milano, Roma e Francoforte. Un agente deve analizzare centinaia di gigabyte presenti a Milano.
Spostare quei dati verso una GPU libera a Francoforte potrebbe essere meno efficiente che spostare il workload verso i dati.
Lo scheduler dovrà quindi valutare contemporaneamente:
GPU locality
Data locality
Model locality
Network latency
Security policy
Cost
La domanda non sarà più soltanto “Dove c’è una GPU disponibile?”.
Diventerà:
Qual è il luogo migliore e autorizzato nel quale eseguire questo agente considerando dati, modelli, sicurezza, latenza e costo?
Il Sandbox diventa ancora più importante nella Private AI
Nelle infrastrutture Private AI il concetto assume un valore ancora maggiore.
Un’organizzazione può avere modelli proprietari, database interni, repository software, documentazione riservata, dati personali, ERP, CRM e sistemi finanziari.
Permettere a un agente di muoversi liberamente attraverso questo patrimonio informativo sarebbe una pessima architettura.
Ogni agente dovrebbe invece avere un perimetro esplicito.
Il sandbox diventa quindi uno strumento concreto per implementare il principio del least privilege nel mondo agentico.
Dal controllo degli utenti al controllo degli agenti
Per decenni la cybersecurity enterprise si è concentrata sulle identità umane.
Chi è l’utente? A quali sistemi può accedere? Quali operazioni può eseguire?
Gli agenti introducono una nuova categoria di identità operative.
Dobbiamo iniziare a progettare anche la Agent Identity.
Ogni agente dovrebbe possedere identità, autorizzazioni, policy, credenziali temporanee e audit trail.
Dovremmo poter ricostruire chi ha avviato l’agente, quale modello ha utilizzato, quali dati ha consultato, quali tool ha chiamato, quale codice ha eseguito, quali API ha contattato e quanto compute ha consumato.
Il sandbox rappresenta uno dei punti naturali nei quali applicare e osservare queste policy.
La nuova infrastruttura AI
L’evoluzione porta verso una separazione più netta tra quattro livelli.
1. Model Infrastructure
Inference server come vLLM, SGLang o Triton gestiscono l’esecuzione efficiente dei modelli e l’utilizzo delle GPU.
2. Agent Infrastructure
Framework e orchestratori gestiscono reasoning, workflow, memoria, pianificazione e coordinamento multi-agent.
3. Tool Infrastructure
MCP server, API gateway, RAG e servizi applicativi forniscono agli agenti le capacità operative.
4. Execution Infrastructure
Sandbox, Kubernetes, gVisor, Kata Containers e microVM stabiliscono dove l’agente può realmente operare e quali limiti non può superare.
Questa separazione permette di evolvere ogni livello indipendentemente.
Possiamo cambiare modello senza cambiare sandbox. Cambiare framework agentico senza modificare l’infrastruttura GPU. Aggiungere nuovi MCP server senza concedere automaticamente agli agenti accesso indiscriminato alla rete.
Dalla Agentic AI alla Physical AI
Il principio diventa ancora più evidente quando l’agente non controlla soltanto software ma sistemi fisici.
Un robot autonomo è, sotto molti aspetti, un agente con sensori, capacità decisionali e strumenti che producono conseguenze nel mondo reale.
Nel caso della Physical AI il concetto di perimetro operativo diventa quindi ancora più importante: autorizzazioni, safety, identità della macchina, accesso ai sistemi e audit devono essere progettati insieme all’intelligenza.
È lo stesso problema che emerge nell’evoluzione dei robot umanoidi: la difficoltà non è soltanto ottenere un modello capace di ragionare o un robot capace di muoversi, ma costruire l’intera infrastruttura necessaria perché possa operare in modo affidabile e controllabile.
Su questo tema: Robot umanoidi: stato dell’arte, autonomia e infrastruttura.
Il vero cambiamento non riguarda Kubernetes
Il punto più interessante non è una nuova funzionalità dell’orchestratore.
È un cambiamento nel modo in cui dobbiamo pensare il software.
Negli ultimi quindici anni abbiamo progressivamente trasformato l’applicazione nella nostra unità fondamentale di deployment.
Con l’AI agentica introduciamo software che non si limita a eseguire istruzioni predefinite, ma decide dinamicamente quali istruzioni eseguire.
Questo richiede un confine differente.
Il sandbox descrive soprattutto fino a dove quel software può arrivare.
Ed è probabilmente questa la distinzione destinata a diventare fondamentale.
Verso infrastrutture costruite per gli agenti
L’AI enterprise dei prossimi anni non sarà costituita soltanto da modelli più grandi e GPU più potenti.
Sarà costituita da un numero crescente di agenti specializzati che nasceranno, utilizzeranno strumenti, accederanno a dati, collaboreranno con altri agenti e scompariranno pochi secondi dopo.
La vera infrastruttura AI dovrà quindi occuparsi contemporaneamente di inference, orchestration, identity, security, networking, data locality, observability e lifecycle.
A quel punto la domanda principale non sarà più soltanto:
“Dove eseguiamo il modello?”
ma:
“Dove eseguiamo l’agente, cosa gli permettiamo di fare e come garantiamo che non possa oltrepassare quel confine?”
È in questo passaggio che il Sandbox può diventare la nuova unità fondamentale di deployment dell’AI agentica.