Il 7 ottobre 2026 GitHub ha reso generalmente disponibile il sandboxing locale per Copilot CLI, l'app Copilot e VS Code, permettendo l'esecuzione di workflow agentici in ambienti isolati e sicuri.
Il 7 ottobre 2026 GitHub ha annunciato la disponibilità generale del sandboxing locale per GitHub Copilot, una funzionalità integrata in GitHub Copilot CLI, nell'app dedicata e nelle sessioni di VS Code che utilizzano Agent Host. Questa innovazione introduce un confine di esecuzione sicuro per i cosiddetti workflow agentici, ovvero quei processi in cui l'intelligenza artificiale non si limita a suggerire codice, ma agisce autonomamente eseguendo comandi e interagendo con il sistema operativo dell'utente. L'obiettivo primario è permettere agli sviluppatori di delegare task complessi all'AI senza esporre l'intera macchina a rischi di sicurezza derivanti da comandi potenzialmente imprevisti o dannosi. [1]
L'introduzione di questo sistema cambia radicalmente l'approccio all'automazione assistita: mentre in precedenza l'esecuzione di script suggeriti dall'AI richiedeva una supervisione manuale costante e un rischio intrinseco di accesso a file sensibili, ora è possibile definire un perimetro operativo rigido. Questo significa che l'agente di Copilot può operare in un ambiente controllato dove le capacità di sistema sono limitate preventivamente. Tale funzionalità è inclusa nell'offerta di GitHub Copilot senza costi aggiuntivi, rendendola accessibile a tutti gli utenti che utilizzano gli strumenti supportati, facilitando l'adozione di flussi di lavoro più autonomi e meno dipendenti dall'intervento umano per ogni singola operazione di sistema. [1]
Il cuore tecnologico del sandboxing locale è rappresentato dal Microsoft eXecution Container (MXC). Questo componente agisce come un traduttore universale: prende una policy di sandbox comune, definita a livello di utente o di organizzazione, e la converte in controlli nativi specifici per il sistema operativo in uso, che sia Windows, macOS o Linux. Attraverso MXC, Copilot può limitare l'accesso del filesystem, impedendo all'agente di leggere o modificare directory non autorizzate, e restringere l'accesso alla rete locale o internet. Inoltre, il sistema gestisce in modo granulare l'accesso alle credenziali di Git e del GitHub CLI, evitando che l'AI possa utilizzare token di accesso in contesti non previsti o non sicuri. [1]
Un aspetto fondamentale di questa architettura è la separazione tra l'esecuzione del modello e l'isolamento degli strumenti. Le policy di sandboxing si applicano esclusivamente all'esecuzione dei tool e dei comandi, indipendentemente dal modello linguistico che Copilot sta utilizzando in quel momento. Questo approccio garantisce che la sicurezza non dipenda dalla 'bontà' o dalla precisione del modello AI, ma da un vincolo infrastrutturale esterno. In termini pratici, se un modello suggerisse un comando per cancellare una directory di sistema, il sandbox lo bloccherebbe a livello di sistema operativo perché tale azione violerebbe le policy di accesso definite, indipendentemente dalla logica generata dall'intelligenza artificiale. [1]
Meccanismo di isolamento dei workflow agentici in GitHub Copilot
Per le aziende, GitHub ha implementato strumenti di governance che permettono di imporre il sandboxing a livello globale. Attraverso impostazioni gestite dal server, tramite MDM (Mobile Device Management) o file di configurazione, le organizzazioni possono richiedere l'attivazione obbligatoria del sandboxing e definire policy che i singoli sviluppatori non possono indebolire. Esiste inoltre un meccanismo di 'fail-closed': se le impostazioni aziendali richiedono il sandboxing e questo non è disponibile o non può essere applicato correttamente sul dispositivo, il sistema blocca completamente le richieste al modello e l'esecuzione di qualsiasi tool per quella sessione, impedendo che l'agente operi in modalità non protetta. [1][2]
Questa struttura di controllo è essenziale per le aziende che operano in settori regolamentati, dove l'esecuzione di codice generato da AI su macchine aziendali potrebbe violare le norme di compliance. La possibilità di centralizzare le policy significa che un amministratore può decidere, ad esempio, che nessun agente Copilot possa mai accedere alle credenziali SSH o a specifiche cartelle di configurazione di rete su nessun laptop aziendale. Il rischio di errore umano, come un developer che disattiva accidentalmente le protezioni per velocizzare un test, viene così mitigato da un'impostazione server-side che prevale sulle preferenze locali, garantendo un livello di sicurezza uniforme in tutto il parco macchine. [2]
Oltre alla soluzione locale, GitHub offre il cloud sandboxing, che permette di eseguire sessioni all'interno di ambienti Linux effimeri e completamente isolati, ospitati su Azure Container Apps Sandboxes. A differenza del sandboxing locale, che protegge la macchina dell'utente, il cloud sandboxing sposta l'intera esecuzione fuori dal dispositivo fisico. Questo permette di mantenere l'ambiente locale leggero e di riprendere le sessioni su qualsiasi dispositivo, poiché lo stato della sessione è salvato nell'infrastruttura di GitHub. Per avviare una sessione cloud tramite CLI è necessario utilizzare il comando 'copilot --cloud --experimental', poiché questa funzione è attualmente in fase sperimentale. [2]
La scelta tra le due modalità dipende dalle esigenze di latenza e di persistenza. Il sandboxing locale è ideale per chi lavora su file locali e necessita di prestazioni immediate senza dipendere dalla connessione cloud per l'esecuzione dei tool. Al contrario, il cloud sandboxing è preferibile per workflow che richiedono ambienti Linux standardizzati o per chi desidera una separazione totale tra il codice eseguito dall'AI e il proprio sistema operativo. Un limite importante del cloud sandboxing è che è disponibile solo per sessioni interattive della CLI; non può essere combinato con opzioni di esecuzione programmatica, limitando di fatto il suo uso a interazioni guidate dall'utente in tempo reale. [2]
Nonostante la disponibilità generale, esistono vincoli tecnici legati all'hardware e al software. Se un host non supporta nativamente le funzionalità richieste per il sandboxing locale, l'app di GitHub Copilot potrebbe avviare la sessione normalmente, ma ogni tentativo di lanciare comandi shell o processi sandboxed fallirà, riportando un errore di mancanza di supporto sulla piattaforma. Inoltre, per quanto riguarda il cloud sandboxing, l'accesso dipende dall'abilitazione nelle impostazioni dell'organizzazione o dell'impresa, essendo disabilitato di default. Questo significa che l'utente finale potrebbe non avere accesso a queste funzioni se l'amministratore non le ha esplicitamente attivate. [2]
L'utente deve essere consapevole che l'implementazione del sandboxing non è invisibile: l'uso di tool come MCP (Model Context Protocol) o language server locali richiede che tali servizi supportino esplicitamente il sandboxing per poter essere inclusi nel perimetro di sicurezza. Se un tool non è compatibile, l'utente dovrà scegliere tra l'esecuzione non protetta (se permessa dalle policy) o l'impossibilità di utilizzare quel tool specifico. Questo crea una dipendenza tra l'ecosistema dei tool di sviluppo e l'implementazione di MXC, suggerendo che l'adozione completa del sandboxing richiederà un aggiornamento graduale di tutti i servizi di supporto utilizzati durante lo sviluppo. [1]
Per valutare se adottare il sandboxing locale, un professionista dovrebbe considerare il livello di autonomia che desidera concedere all'agente AI. Un esempio illustrativo riguarda l'automazione della pulizia di un progetto: un utente potrebbe configurare una policy che permette a Copilot di leggere e scrivere solo all'interno della cartella /tmp/project-cleanup, vietando l'accesso a /etc o alle cartelle utente. Prima di procedere, l'utente deve verificare che il proprio sistema operativo sia supportato da MXC e che l'IDE sia aggiornato. Se l'obiettivo è testare script potenzialmente instabili, il criterio di scelta dovrebbe pendere verso il cloud sandboxing per isolare completamente l'esecuzione dalla macchina fisica. [1][2]
In sintesi, l'adozione è consigliata per chi utilizza intensamente le funzionalità agentiche di Copilot e desidera ridurre il rischio di 'allucinazioni operative', ovvero casi in cui l'AI esegue comandi distruttivi per errore. Chi invece utilizza Copilot principalmente per il completamento del codice (autocomplete) senza l'uso di agenti che eseguono comandi shell troverà meno valore immediato in queste funzioni. La transizione verso un modello di sviluppo 'sandbox-first' permette di scalare l'automazione senza compromettere l'integrità del sistema, a patto di accettare una configurazione iniziale più rigorosa delle policy di accesso. [1]
GitHub ha annunciato il 6 ottobre 2026 un aggiornamento per gli IDE volto a correggere un errore di attribuzione dei dati relativi agli agenti, che causava una sottostima delle linee di codice e dell'attività nei report di utilizzo.
Rilasciato il 6 ottobre 2026, Gemini Nano Banana 2.1 introduce miglioramenti nella qualità visiva, nel rendering del testo e nel supporto per formati panoramici, sostituendo il modello Nano Banana 2.
Mistral Large 4 arriva in public preview: architettura MoE, testo e immagini, risultati sul coding e pesi attesi a fine ottobre. Analizziamo specifiche, divergenze nelle fonti e criteri per provarlo.
Parliamone
Hai un’esperienza da condividere o una domanda? Scrivi un commento pertinente, senza pubblicità o link.