Un coding agent è sicuro quanto il codice che scrive?

Da anni, una delle principali domande nello sviluppo software è: il codice è sicuro?

Gli sviluppatori analizzano le vulnerabilità, verificano le dipendenze, testano le applicazioni e stabiliscono quali utenti possono accedere alle diverse parti di un sistema.

Ma l’introduzione dei coding agent nel processo di sviluppo sta sollevando un’altra domanda.

L’agente che scrive ed esegue il codice è sicuro quanto il software che stiamo cercando di costruire?

Questa domanda diventa sempre più importante man mano che gli agenti AI passano dal suggerire poche righe di codice all’eseguire azioni reali all’interno degli ambienti di sviluppo.

Un coding agent può leggere file, modificare codice, eseguire comandi, installare dipendenze, utilizzare strumenti e, in determinate configurazioni, comunicare con servizi attraverso la rete.

A questo punto, la sicurezza non riguarda più soltanto il codice prodotto dall’AI.

Riguarda anche l’ambiente in cui l’AI è autorizzata a operare.

Dall’assistente che suggerisce codice all’agente che esegue comandi

La prima generazione di strumenti AI per la programmazione funzionava principalmente come un sistema di suggerimenti.

Lo sviluppatore scriveva il codice e il modello proponeva funzioni, frammenti di codice o possibili soluzioni.

I coding agent stanno cambiando questo modello.

Un agente può ricevere un’attività, analizzare il repository, identificare i file che devono essere modificati, modificare il codice ed eseguire strumenti per verificare il risultato.

GitHub descrive questa evoluzione di Copilot, che passa dall’essere un assistente all’interno dell’editor a diventare un partner di sviluppo capace di utilizzare strumenti, eseguire comandi e modificare file.

Più azioni un agente è in grado di eseguire, più diventa importante una domanda: a cosa è autorizzato ad accedere?

Un errore in una risposta testuale può essere corretto prima che venga utilizzata.

Un comando eseguito in un sistema reale può avere conseguenze immediate.

Un coding agent deve essere trattato come un utente del sistema

Dal punto di vista architetturale, un coding agent non dovrebbe essere considerato soltanto un modello AI.

Sta diventando un attore attivo all’interno del sistema.

Se può leggere il file system, utilizzare il terminale e comunicare attraverso la rete, dispone di una superficie di accesso che deve essere controllata.

Questo approccio è simile al modo in cui i sistemi moderni gestiscono utenti e servizi.

Un’applicazione non dovrebbe concedere a ogni utente l’accesso a tutte le risorse. Allo stesso modo, un coding agent non dovrebbe avere automaticamente accesso a un intero computer semplicemente perché deve modificare un repository.

Il principio diventa semplice:

L’agente dovrebbe avere soltanto gli accessi necessari per completare l’attività.

Si tratta di un’applicazione diretta del principio del privilegio minimo allo sviluppo basato sull’AI.

La sandbox sta diventando il nuovo confine della sicurezza

Il 2 giugno 2026, GitHub ha presentato in public preview sandbox cloud e locali per GitHub Copilot.

L’obiettivo è consentire alle azioni di Copilot di essere eseguite all’interno di ambienti isolati, invece di concedere all’agente un accesso illimitato al sistema su cui lavora lo sviluppatore.

In una sandbox locale, i comandi e gli strumenti eseguiti dall’agente possono avere un accesso limitato al file system, alla rete e alle funzionalità del sistema.

Una sandbox cloud compie un ulteriore passo avanti, spostando la sessione in un ambiente Linux temporaneo e isolato, ospitato da GitHub.

Questo crea un’importante separazione architetturale.

Invece di consentire al coding agent di eseguire ogni azione direttamente sul sistema principale, viene collocato all’interno di un confine nel quale è possibile definire quali risorse può utilizzare.

In questo modo, la sandbox non è semplicemente una funzionalità di sicurezza aggiuntiva.

Sta diventando il livello di esecuzione dei coding agent.

Il file system è uno dei confini più importanti

Un coding agent che lavora su un progetto deve poter leggere e modificare i file.

Ma questo non significa che debba essere in grado di leggere ogni file presente sul dispositivo dello sviluppatore.

L’attuale documentazione di GitHub consente di configurare l’accesso della sandbox al file system in base a percorsi specifici. Alcune aree possono essere accessibili in lettura e scrittura, altre soltanto in lettura, mentre altre ancora possono essere completamente bloccate.

Questo permette di creare un modello molto più controllato.

L’agente può accedere al repository su cui deve lavorare senza necessariamente avere la stessa libertà nel resto del sistema.

Questa distinzione diventa particolarmente importante quando il dispositivo dello sviluppatore contiene altri progetti, configurazioni, credenziali o dati che non hanno alcuna relazione con l’attività dell’agente.

La rete crea un altro problema: l’esfiltrazione dei dati

Il file system controlla ciò che l’agente può leggere o modificare.

La rete controlla dove può inviare le informazioni.

Un coding agent può avere motivi legittimi per accedere a Internet. Potrebbe aver bisogno di scaricare una dipendenza, contattare un registro di pacchetti o utilizzare un servizio necessario durante il processo di sviluppo.

Ma un accesso illimitato alla rete crea anche dei rischi.

GitHub collega le restrizioni dell’accesso a Internet alla gestione del rischio di esfiltrazione dei dati. Un comportamento imprevisto dell’agente o istruzioni malevole possono creare situazioni in cui il codice o altre informazioni sensibili vengono inviati, o si tenta di inviarli, verso una destinazione esterna.

Per questo motivo, l’agente cloud di Copilot utilizza un firewall per limitare l’accesso a Internet e le organizzazioni possono controllare quali destinazioni sono consentite.

Questo sposta la sicurezza dalla domanda:

“Ci fidiamo del modello?”

verso una domanda più pratica:

“Anche se il modello commette un errore, cosa gli consente di fare l’infrastruttura?”

La prompt injection non è più soltanto un problema dei chatbot

Un altro rischio emerge quando gli agenti ricevono istruzioni da contenuti che non sono completamente controllati dallo sviluppatore.

GitHub avverte che i contenuti presenti nelle issue o nei commenti possono essere utilizzati per tentare attacchi di prompt injection contro l’agente cloud.

Questo aspetto è particolarmente importante per i coding agent, perché non producono soltanto testo.

Possono eseguire azioni.

In un sistema AI tradizionale, un’istruzione malevola può influenzare la risposta del modello.

In un sistema dotato di strumenti, lo stesso problema può tentare di influenzare i comandi eseguiti dall’agente, i file che legge o i servizi con cui comunica.

La protezione, quindi, non può dipendere esclusivamente dalla capacità del modello di distinguere le istruzioni sicure da quelle pericolose.

Devono esistere limiti tecnici esterni al modello.

Le credenziali devono essere considerate un privilegio, non un’impostazione predefinita

Le credenziali sono tra le risorse più sensibili che possono essere affidate a un coding agent.

Se un agente può utilizzare Git o GitHub CLI con l’identità dello sviluppatore, potrebbe essere in grado di eseguire azioni che vanno oltre la semplice modifica di un file locale.

Per questo motivo, la configurazione della sandbox dovrebbe determinare non soltanto l’accesso ai file e alla rete, ma anche quali credenziali sono disponibili durante l’esecuzione.

Questo è un altro motivo per cui i coding agent dovrebbero essere trattati come identità operative all’interno dell’architettura.

La domanda non dovrebbe essere soltanto “cosa sa l’agente?”, ma:

Cosa può fare l’agente con l’identità che gli abbiamo assegnato?

Una sandbox riduce il rischio, ma non lo elimina

L’isolamento rappresenta un importante livello di sicurezza, ma non dovrebbe essere considerato una garanzia assoluta.

La stessa documentazione di GitHub evidenzia i limiti del firewall e avverte che attacchi sofisticati potrebbero tentare di aggirare queste protezioni.

Allo stesso modo, un coding agent può generare codice che appare corretto ma contiene errori funzionali o vulnerabilità di sicurezza.

Questo significa che esistono due problemi distinti.

Il primo riguarda la sicurezza del codice prodotto dall’agente.

Il secondo riguarda la sicurezza delle azioni eseguite dall’agente durante la produzione di quel codice.

La sandbox contribuisce principalmente ad affrontare il secondo problema.

La code review, i test, l’analisi statica e i controlli di sicurezza rimangono necessari per affrontare il primo.

La supervisione umana rimane parte del modello di sicurezza

L’autonomia dei coding agent non dovrebbe significare assenza di supervisione umana.

GitHub raccomanda di verificare l’output prodotto da un agente prima di integrarlo nella codebase principale e applica ulteriori restrizioni all’agente cloud.

Ad esempio, l’agente dispone di un accesso limitato al repository, non può effettuare il push delle modifiche direttamente sul branch principale e determinati workflow richiedono l’approvazione umana prima di poter essere eseguiti.

Queste misure dimostrano un principio più ampio per l’architettura dei sistemi AI:

L’autonomia deve aumentare insieme al controllo.

Più azioni un agente può eseguire, più devono essere chiari i suoi limiti, le autorizzazioni, la tracciabilità e i punti in cui è richiesta l’approvazione umana.

La sicurezza dei coding agent sta diventando un problema architetturale

Per ALSoft, lo sviluppo con coding agent dovrebbe essere considerato un cambiamento architetturale, non semplicemente l’adozione di un nuovo strumento di produttività.

Nel momento in cui un sistema AI può utilizzare il terminale, modificare file, comunicare attraverso la rete e operare con credenziali, diventa una componente attiva del modello di sicurezza del sistema.

Questo significa che i team dovrebbero definire i limiti di accesso prima di definire il livello di autonomia.

Come afferma Ermal Beqiri, fondatore di ALSoft:

“Un coding agent non diventa sicuro semplicemente perché il modello è avanzato. La sicurezza inizia dai limiti che costruiamo intorno ad esso: ciò che può leggere, ciò che può modificare, con quali destinazioni può comunicare e quali azioni richiedono l’approvazione umana. Più l’AI diventa autonoma, più diventa importante l’architettura che controlla questa autonomia.”

I coding agent stanno cambiando il modo in cui viene sviluppato il software.

Ma il passaggio dal suggerimento di codice all’esecuzione autonoma comporta anche un cambiamento nel modo in cui deve essere affrontata la sicurezza.

Non è più sufficiente controllare soltanto il codice prodotto dall’AI.

Dobbiamo controllare anche l’ambiente in cui l’AI opera.

Il file system, la rete, le credenziali, la sandbox, le politiche di accesso e l’approvazione umana stanno diventando componenti della stessa architettura di sicurezza.

In questo modello, un coding agent non dovrebbe essere considerato un processo di cui fidarsi automaticamente.

Dovrebbe essere trattato come un componente con privilegi limitati, comportamento osservabile e azioni controllabili.

Perché nello sviluppo software basato sull’AI, la prossima domanda sulla sicurezza non sarà soltanto:

“Il codice è sicuro?”

Ma anche:

“L’agente che lo ha costruito era sicuro?”