Gli agenti AI sono incredibilmente utili. Troppo, forse. Perché quando un agente può accedere ai tuoi file, alla rete, alle applicazioni — a tutto — la domanda diventa: cosa potrebbe andare storto? Parecchio.
Microsoft ha deciso di non lasciarti scegliere tra accesso totale con le dita incrociate o blocco totale e addio produttività. La soluzione si chiama Microsoft Execution Containers (MXC), ed è ora disponibile per tutti.
Il problema: un agente non può essere il suo stesso poliziotto
Immagina di chiedere a un agente di coding di aggiornare un sito web. L’agente ha bisogno di leggere e scrivere nel repository, accedere agli strumenti di sviluppo, magari dare un’occhiata alla configurazione del server di produzione. Quello che non dovrebbe fare è modificare quella configurazione. Eppure, dal punto di vista dell’agente, cambiare direttamente il server potrebbe sembrare il modo più rapido per completare il task. Risultato: sito in produzione rotto.
Un agente non può decidere da solo cosa può o non può fare. Serve un confine definito dall’esterno e fatto rispettare dal sistema operativo, non dal modello AI.
Cosa fa MXC (e perché è diverso)
MXC è un layer di esecuzione basato su policy. Dichiari quali risorse può usare un agente — file, destinazioni di rete, strumenti — e MXC fa rispettare quei limiti. L’agente non può darsi permessi da solo, non può decidere di superare il confine. Se prova a modificare la configurazione del server nell’esempio di prima, il container blocca l’operazione.
Gli sviluppatori non devono gestire i dettagli specifici della piattaforma. MXC usa uno schema JSON unificato e un SDK multi-linguaggio. Funziona su Windows, macOS, Linux. La stessa policy si applica ovunque giri l’agente, dal laptop locale al cloud.
I livelli di isolamento: non tutti i container sono uguali
Non tutti i workload hanno bisogno dello stesso livello di separazione. Un agente che lavora su un repository di codice ha bisogno di velocità. Uno che processa dati sensibili o esegue codice sospetto ha bisogno di isolamento rinforzato. MXC offre uno spettro di opzioni.
Process container: leggero, disponibile su Windows 11, macOS e Linux. Usa il sandbox nativo della piattaforma (AppContainer su Windows, Seatbelt su macOS, Bubblewrap su Linux). Perfetto per codice generato dai modelli e tool execution dove conta la reattività.
Session container: solo su Windows 11. L’agente gira in una sessione separata del sistema operativo, con la propria identità locale, desktop isolato, clipboard, UI, input. Ideale per agenti long-running o automazioni che hanno bisogno di una separazione più netta dall’utente interattivo.
WSL container: solo Windows 11. Per toolchain Linux-first e workload che dipendono dall’ecosistema di sviluppo Linux. Usa WSL come ambiente di esecuzione.
MicroVM: sperimentale, su Windows 11 e Linux. Isolamento hardware rinforzato per workload ad alto rischio. Virtualizzazione completa, compatibilità Linux totale.
Le policy: cosa controlla MXC
MXC ti permette di definire confini precisi. Nell’esempio del sito web, potresti dare all’agente accesso in lettura e scrittura al repository locale e agli strumenti di sviluppo, bloccando l’accesso alla cartella Documenti dell’utente, alle connessioni di rete in entrata e in uscita, e al desktop interattivo.
Le aree che puoi controllare: Containment (quale tipo di container), Process (comando, argomenti, directory di lavoro), File system (cosa può modificare, cosa può solo leggere, cosa è off-limits), Network (connettività in e out, incluso loopback), User interface (accesso al desktop e risorse UI).
Per integrare MXC puoi usare il tuo agente di coding preferito per scrivere una policy iniziale con l’SDK, poi rifinirla con i test.
Policy dell’organizzazione: quando l’IT deve dire la sua
Gli sviluppatori dichiarano le risorse di cui i loro agenti potrebbero aver bisogno. Le organizzazioni possono aggiungere vincoli ulteriori tramite policy di gestione, come quelle di Microsoft Intune — presto disponibili per i process container MXC su Windows 11.
Lo stesso agente può operare dentro confini enterprise diversi senza che lo sviluppatore riscriva tutto. Se una policy blocca una risorsa, l’agente dovrebbe spiegare che il task non può essere completato con i permessi disponibili, chiedere un’azione all’utente o all’amministratore quando supportato, o scegliere un’alternativa sicura. Non deve fallire silenziosamente.
Learning mode: capire cosa serve prima di bloccare tutto
Scrivere una policy a privilegio minimo è difficile quando non sai ancora quali risorse userà davvero l’agente. Solo su Windows, i process container MXC possono produrre un activity report che mostra quali risorse il workload ha tentato di usare — utile per costruire policy precise.
MXC supporta tre modalità operative:
Enforcement: applica la policy senza report. L’accesso consentito passa, quello negato viene bloccato.
Learning: fa rispettare la policy e registra ogni tentativo di accesso negato in un report JSON. Puoi riprodurre i fallimenti e capire cosa manca.
Permissive: registra cosa la policy avrebbe bloccato, ma lascia passare l’operazione. Utile mentre scrivi la policy, per vedere cosa usa davvero il workload senza bloccarlo subito.
Quando porti un agente in un container MXC per la prima volta, la policy probabilmente bloccherà qualcosa di legittimo. Quelle negazioni ti mostrano dove aggiustare il confine.
Identità: chi ha fatto cosa
Il containment risponde a cosa può fare un agente. L’identità risponde a quale agente ha fatto una cosa. Presto Windows permetterà a Microsoft Entra di distinguere l’attività dell’agente da quella dell’utente in Microsoft Agent 365.
Questa separazione consente ai team di sicurezza di valutare comportamento e rischio di un agente indipendentemente dalla persona che usa il device. Se un agente viene compromesso o viola una policy, i controlli di sicurezza colpiscono l’accesso dell’agente senza bloccare quello del dipendente.
L’attribuzione a livello di agente migliora anche indagini e governance. Gli amministratori potranno usare Agent 365 per capire quali agenti stanno girando, associare attività a uno specifico agente, investigare comportamenti rischiosi e applicare policy a singoli agenti o gruppi, invece di affidarsi solo al contesto utente o device.
Chi usa già MXC
NVIDIA ha integrato OpenShell in MXC. GitHub Copilot, OpenClaw, OpenAI Codex, Replit, LM Studio e Unsloth AI supportano già MXC. In arrivo: Anthropic Claude Code, Box, Egnyte, Heidi Health, Hermes Agent by Nous Research, Manus, Perplexity, Raycast, Simular.
GitHub Copilot, Codex e Replit mostrano come MXC supporti workflow di sviluppo esigenti. Un agente di coding ha bisogno del repository, degli strumenti e dei comandi per completare il task. Non ha bisogno di accesso automatico a file o destinazioni di rete non correlate. MXC preserva le capacità necessarie e blocca l’accesso al resto del sistema.
Più dettagli su come GitHub Copilot usa MXC nel blog post ufficiale.
