Far costruire l'infrastruttura cloud a un agente AI: cosa gli stai dando in mano
Un agente AI che costruisce infrastruttura cloud è un agente di coding a cui sono stati aggiunti due pezzi: un server MCP che sa parlare con le API del fornitore, e le credenziali con cui chiamarle. Il 19 agosto 2026 AWS ha pubblicato sul proprio blog Compute un articolo firmato da D Surya Sai e Sahithi Ginjupalli che riduce quei due pezzi a un pulsante solo, dentro la console di Step Functions.
Il pulsante si chiama Copy agent prompt e copia negli appunti un'istruzione di fetch che punta a una guida di configurazione ospitata sulla documentazione AWS. La si incolla nell'agente, l'agente legge la guida e si configura da solo. AWS scrive che la funzione è disponibile in tutte le regioni commerciali e senza costi aggiuntivi.
La notizia però non è il pulsante. È che il pezzo noioso di questa storia, cioè la configurazione, adesso lo consegna il fornitore cloud invece di lasciarlo a chi costruisce, e quindi la domanda interessante si sposta di un passo: cosa si ritrova in mano quell'agente un secondo dopo che il setup è finito.
Cosa installa davvero il pulsante di AWS
Il setup descritto da AWS il 19 agosto 2026 installa due componenti nell'agente: la AWS Serverless skill, che fa parte dell'Agent Toolkit for AWS, e l'AWS Serverless MCP Server. Sono due cose diverse e conviene tenerle separate in testa, perché una insegna e l'altra esegue.
Gli agenti supportati elencati nell'articolo di AWS sono sette: Claude Code, Kiro CLI, Codex, Cursor, GitHub Copilot, Devin Desktop e OpenCode. È più o meno l'elenco di chi parla MCP oggi, ed è il motivo per cui una guida di configurazione scritta una volta sola funziona su tutti e sette.
Chi ha già installato una skill dentro un agente di coding riconosce subito lo schema: la skill è testo che l'agente legge quando serve, il server MCP è un processo che espone operazioni verso l'esterno. Il primo cambia cosa l'agente sa, il secondo cambia cosa l'agente può toccare.
Le credenziali sono il punto, non il pulsante
Sulle credenziali l'articolo di AWS del 19 agosto 2026 è esplicito, e la frase merita di essere letta due volte: il server MCP usa il profilo AWS locale, e non servono nuovi ruoli o permessi IAM oltre a quelli già in uso per lo sviluppo su Step Functions.
Letta dal lato della comodità, è la frase migliore dell'articolo: niente da configurare, si parte. Letta dal lato di chi deve rispondere di quell'account, è la frase che sposta tutto il peso della decisione altrove. Il perimetro di quello che l'agente può fare non lo definisce l'agente, e nemmeno AWS: lo definisce il profilo che si trova nella shell da cui l'agente è partito. È lo stesso principio per cui l'AI in azienda lavora con i permessi di chi la accende, applicato a un posto dove le risorse costano a consumo.
Cosa sa fare un agente AI sull'infrastruttura cloud
Dopo il setup, secondo l'articolo AWS del 19 agosto 2026, l'agente arriva fino al deploy. Non si ferma alla generazione del file, che è il punto in cui questi strumenti si fermavano fino a poco fa.
| Cosa fa l'agente dopo il setup | Come lo descrive AWS |
|---|---|
| Scrive ASL | il formato con cui si descrive una macchina a stati di Step Functions |
| Struttura i workflow | con retry e gestione degli errori |
| Sceglie il tipo di workflow | fra Standard ed Express |
| Implementa pattern noti | saga orchestration e parallel fan-out |
| Esegue il deploy | con AWS SAM oppure AWS CDK |
| Accede alle risorse AWS | direttamente, tramite il server MCP |
Il deploy è la riga che cambia la natura della cosa
Fra tutte le capacità elencate da AWS, l'esecuzione del deploy è quella che sposta il problema. Un agente che scrive un template lo fa dentro il repository, e il repository ha una revisione, una pull request e qualcuno che guarda. Un agente che esegue il deploy salta quel passaggio per costruzione, a meno che non sia qualcuno ad averlo rimesso in mezzo di proposito.
La scelta fra Standard ed Express, per dire, non è una preferenza di stile: sono due modelli di esecuzione con due modelli di prezzo. Delegarla a un agente senza aver deciso prima quale dei due si vuole significa scoprire la risposta in fattura, ed è la stessa dinamica per cui un agente AI in azienda va limitato prima di essere acceso e non dopo.
Cosa cambia per lo sviluppo software con l'intelligenza artificiale
Lo sviluppo software con l'intelligenza artificiale sta finendo la fase in cui l'agente scriveva e una persona metteva online. Quando è il fornitore cloud a pubblicare la guida di configurazione, il pattern smette di essere un esperimento di qualcuno su GitHub e diventa un percorso supportato, con la documentazione ufficiale dietro. È la prosecuzione naturale del fatto che scrivere codice è diventato la parte economica del lavoro: adesso lo sta diventando anche metterlo online.
Nelle automazioni di questo sito ho preso la strada opposta, ed è documentata in automazione-blog/README.md: il cloud agent non entra mai nella VPS via SSH, chiama soltanto un endpoint HTTP protetto da token, e la VPS espone quella singola finestrella e nient'altro. Non l'ho fatto perché l'agente sia inaffidabile, l'ho fatto perché così il danno massimo possibile è una cosa che so elencare in anticipo. Con un profilo AWS completo quell'elenco non si può scrivere, e quando un elenco non si riesce a scrivere di solito vuol dire che il permesso è troppo largo.
Il consiglio quindi non è evitare il setup di AWS, che è ben fatto e fa risparmiare mezz'ora vera. È non far coincidere il profilo che usi tu con quello che dai all'agente, perché sono due utenti con abitudini diverse. Uno esita, l'altro no.
Cosa controllare prima di dare le chiavi del cloud a un agente AI
Ci sono quattro controlli concreti da fare prima di lanciare un agente AI sull'infrastruttura cloud, e nessuno richiede più di qualche minuto.
- Verifica con quale identità sta lavorando l'agente, non quale credi che stia usando. Il comando è
aws sts get-caller-identity, lanciato nella stessa shell da cui parte l'agente, e la variabile da guardare èAWS_PROFILE. - Tieni il profilo di sviluppo separato da quello di produzione anche se sei da solo. La frase di AWS sul riuso dei permessi esistenti vale quanto valgono quei permessi, e su molte macchine il profilo predefinito è più largo di quanto ricordi chi l'ha creato.
- Decidi prima se l'agente arriva al deploy o si ferma al template. Se si ferma al template, il controllo torna a essere la pull request, che è un posto dove i controlli esistono già.
- Metti il limite di spesa sull'account, non nelle istruzioni. Un budget scritto nel prompt è un'intenzione, un budget configurato sull'account è un vincolo, e la differenza si vede solo il giorno in cui qualcosa gira in loop.
Perché il limite va messo fuori dall'agente
Il limite di spesa configurato sull'account, e non scritto nelle istruzioni, è il controllo che separa un agente sorvegliato da un agente lasciato solo. È la stessa lezione che vale quando si fa girare un agente di coding in automatico: quello che non è misurato dall'esterno del processo, dall'interno del processo non esiste. Chi sta valutando di portare un agente AI dentro un processo aziendale farebbe bene a partire da questa domanda invece che dalle capacità del modello.
Il pulsante di AWS è una buona notizia e va usato. Ma la mezz'ora che fa risparmiare andrebbe reinvestita nella cosa che il pulsante non fa, cioè decidere il perimetro, perché quella parte non la consegnerà mai nessun fornitore. Il testo integrale sta sul blog Compute di AWS, ed è la fonte da leggere prima di premere il pulsante.
Domande frequenti
Cos'è AWS Step Functions?
AWS Step Functions è il servizio di orchestrazione di flussi di lavoro di Amazon Web Services: descrive un processo come una macchina a stati, dove ogni passaggio chiama un servizio e il servizio decide cosa succede in caso di errore. I flussi si scrivono in Amazon States Language e si distinguono in due tipi di esecuzione, Standard ed Express. Serve tipicamente a incatenare funzioni serverless senza scrivere a mano la logica di coordinamento.
Un agente AI può fare il deploy in produzione da solo?
Tecnicamente sì, se le credenziali che trova nell'ambiente arrivano fino alla produzione. È esattamente per questo che la separazione dei profili conta più di qualsiasi impostazione dell'agente: un agente non ha un concetto proprio di ambiente di produzione, ha soltanto le chiavi che gli sono state lasciate a disposizione. La decisione se fermarsi al template o arrivare al deploy va presa fuori dall'agente.
Si può creare software senza saper programmare?
Con gli agenti di coding attuali si può arrivare a un software funzionante senza scrivere codice a mano, ma non senza saper leggere quello che l'agente produce. La parte che non si delega non è la scrittura, è il giudizio su cosa è accettabile mandare online: permessi, costi ricorrenti e comportamento in caso di errore restano decisioni di chi firma il progetto.
Come si torna indietro da una modifica fatta da un agente AI sull'infrastruttura?
Si torna indietro solo se la modifica è passata da uno strumento di infrastruttura come codice, per esempio AWS SAM o AWS CDK, perché in quel caso esiste un file versionato da cui ripartire. Le risorse create fuori da quel percorso, direttamente via API, non lasciano una traccia equivalente e vanno cercate a mano nell'account. È il motivo per cui conviene vincolare l'agente a lavorare solo attraverso i template, anche quando avrebbe i permessi per fare altro.