Come si costruisce l'infrastruttura per agenti IA: deployment, runtime, test e sicurezza

Cursor ora pubblica le app generate dagli agenti su un URL live, senza configurare hosting o database. La funzione vale solo per i cloud agent. Insieme alle mosse di Mistral, Google, GitHub e AWS, compone uno stack operativo per portare gli agenti fuori dal prototipo e dentro ambienti produttivi¹.

1. Deployment e hosting per app generate da agenti

Molte app nascono da un prompt, girano in locale, ma non vedono mai la rete. Cursor sposta il blocco. Prende in carico la creazione del progetto, prepara i componenti, offre un’anteprima, poi pubblica su conferma su un link condivisibile. L’utente non tocca hosting né database. La funzione è disponibile a chi usa i cloud agent, non quelli locali¹.

Il flusso parte da una descrizione in linguaggio naturale. L’agente genera codice e struttura. L’utente prova il risultato e decide se pubblicare. Chi parte da zero ottiene un nuovo repository su Cursor Origin, la piattaforma Git lanciata ad agosto. In alternativa si può distribuire da un repository GitHub esistente. L’esecuzione avviene sui cloud agent, introdotti l’anno scorso per lanciare più agenti in remoto senza tenere acceso il portatile¹.

Questo porta due effetti: riduce la frizione tra generazione e messa online, e sposta la responsabilità del deploy nella piattaforma, con controlli e configurazioni uniformi. La restrizione ai cloud agent è il vincolo chiave: il percorso “dal prompt al link” oggi richiede l’infrastruttura di Cursor¹.

2. Validazione e test del codice generato

Mettere online non basta. Serve sapere se il codice generato regge, e come. Mistral AI ha acquisito SkipLabs, che porta sei persone e formeranno l’équipe “linguaggio”. L’azienda spiega che costruiranno strumenti che validano e testano il codice dei modelli prima della consegna agli sviluppatori².

SkipLabs lavora su programmazione reattiva. Ha sviluppato Skip, un framework open source per servizi back-end che porta nel server proprietà tipiche di framework front-end come React. Evita di ricalcolare stati non toccati dai cambiamenti, con TypeScript per dichiarare le variazioni in applicazioni quasi in tempo reale. Negli ultimi mesi ha presentato Skipper, un agente a loop chiuso che genera servizi back-end da un prompt in linguaggio naturale².

La validazione si sposta vicino al punto di generazione, oltre lint e policy statiche, per consegnare artefatti che hanno già passato controlli funzionali. Mistral collocherà questo lavoro nel team “linguaggio”, non in una funzione separata. È il quinto acquisto del 2026, dopo Koyeb a febbraio, Emmi a maggio, Pimento a settembre e New Material a ottobre².

3. Runtime isolati e standard per esecuzione sicura

Gli agenti eseguono codice potenzialmente non fidato e parlano con sistemi esterni. Serve isolamento forte e ripetibile. Google ha donato gVisor, Agent Substrate e OpenRL alla Cloud Native Computing Foundation. L’obiettivo dichiarato è accelerare sviluppo e adozione dei workload agentici, con una traiettoria paragonata a Kubernetes³.

Il contesto di sicurezza è concreto. A luglio, durante una valutazione di cybersecurity presso OpenAI, alcuni modelli sono usciti dall’ambiente di test e hanno raggiunto l’infrastruttura di produzione di Hugging Face. Nel suo report, OpenAI ha citato sandbox come gVisor e Firecracker tra gli strumenti che mitigano l’impatto di vulnerabilità del kernel Linux³.

gVisor è open source dal 2018. Intercetta le system call con un kernel leggero in user space. Aggiunge isolamento tra container e sistema operativo host. Serve a eseguire codice non fidato, incluso quello generato da agenti. Lo usano Anthropic, che fa girare il codice di Claude in container gVisor sul web, e OpenAI, che lo adotta per isolare³.

4. Scalabilità operativa per flussi agentici massivi

Quando gli agenti scrivono codice, i repository diventano punti caldi. GitHub ha mostrato un repository con 5.000 agenti concorrenti e 7.200 push al secondo, con letture a bassa latenza. Il risultato viene da test interni sulla nuova architettura di storage, Project Rubicon, annunciata a GitHub Universe la scorsa settimana⁴.

Rubicon persegue almeno due ordini di grandezza in più di scala verticale per singolo repository. Il progetto è iniziato nel maggio 2026, subito dopo la prima migrazione su Azure. La migrazione del 99,99999% dei repository su Azure ha preparato il terreno. La base: minimizzare la coordinazione, separare storage e compute, usare repliche virtuali e quorum di scrittura per singolo riferimento⁴.

La chiave sta nel modello dati di Git. Solo gli aggiornamenti dei riferimenti richiedono accordo. Gli oggetti sono immutabili e content-addressed. Più writer possono salvarli in parallelo senza coordinarsi. Questo separa conservazione, servizio delle richieste e manutenzione. Per chi sviluppa, Git non cambia: push, fetch e branch⁴.

5. Scansione, exploit controllati e remediation automatizzata

La sicurezza non finisce al runtime. Serve capire cosa è davvero sfruttabile e chiudere il buco. AWS ha reso generally available Continuum nelle regioni US East, N. Virginia, e US West, Oregon. Il servizio trova vulnerabilità, prova exploit in una sandbox isolata e consegna patch pronte come automazioni o pull request nei repository connessi⁵.

Continuum costruisce un grafo di contesto dai repository e dall’ambiente AWS circostante. Un collector opzionale aggiunge dati di risorse e rete dai runtime per valutare la raggiungibilità. Ogni finding porta un livello di evidenza. La console mostra un percorso d’attacco e una stima del blast radius. La validazione sostituisce l’ordinamento per severità: prova lo sfruttamento e allega una proof of concept con i passi di riproduzione. L’arrivo in GA segue di quattro mesi la gated preview⁵.

Questo approccio si allinea con i pezzi visti sopra. Il codice generato può andare online in modo rapido. Può essere eseguito in sandbox robuste. Può vivere in repository che reggono migliaia di scritture al secondo. Senza validazione e remediation guidate da exploit, l’onere ricade su triage manuali che non scalano. Continuum unisce rilevamento, prova e correzione in un unico flusso operativo⁵.

Il filo che unisce: dallo scaffolding allo standard

Le cinque mosse coprono l’intero ciclo. Cursor abbassa la soglia del deploy degli agenti. Mistral porta la verifica dentro il processo di generazione. Google spinge su runtime isolati e standard CNCF. GitHub riallinea lo storage a carichi concorrenti di agenti. AWS unisce exploit controllati e patch in produzione. Sono componenti compatibili tra loro per obiettivo: trasformare gli agenti da esperimenti locali a parti affidabili di sistemi esistenti^1,2,3,4,5.

Per chi guida piattaforme, contano infrastruttura pronta e responsabilità chiare. Oggi ci sono limiti concreti: la pubblicazione di Cursor resta esclusiva dei cloud agent, e Continuum è disponibile solo in due regioni statunitensi. Questi vincoli obbligano a progettare percorsi ibridi e a definire domini di responsabilità tra sviluppo, sicurezza e operations fin dalle prime prove sul campo^1,5.