Software e app
Microsoft ha annunciato che Microsoft Execution Containers (MXC), il livello che isola gli agenti IA e ne limita le azioni tramite policy, è disponibile per tutti. Lo spiega il blog Windows Developer di Microsoft nel post del 7 ottobre firmato da Logan Iyer. Sviluppatori e amministratori IT decidono quali file e quali destinazioni di rete l’agente può usare, e MXC applica i limiti mentre l’agente gira.
Perché i limiti di un agente vanno imposti dall’esterno
Secondo Microsoft, chi usa gli agenti oggi sembra avere due sole scelte: dare accesso illimitato o bloccarli, perdendone i vantaggi. L’azienda sostiene che nessuna delle due sia accettabile e per questo lavora su tre capacità della piattaforma: contenimento, identità e gestibilità. MXC è il livello di contenimento.
L’esempio portato da Microsoft è un agente di programmazione incaricato di aggiornare un sito web. Deve leggere e scrivere nel repository e usare gli strumenti di build, può leggere la configurazione del server di produzione ma non modificarla. Senza un confine imposto dall’esterno, l’agente potrebbe ritenere che toccare quella configurazione sia la via più rapida e rompere il sito.
Come funziona MXC
MXC è un livello di esecuzione guidato da policy per codice non fidato o carichi generati dinamicamente. Gli sviluppatori possono contenere l’output del modello, i plugin, gli strumenti, l’harness dell’agente o l’intero agente. La policy resta fuori dal controllo del carico di lavoro, quindi l’agente o il codice generato non possono concedersi accessi aggiuntivi.
Gli sviluppatori usano uno schema di configurazione JSON unico e un SDK multi-linguaggio. MXC traduce poi i controlli richiesti nei backend scelti su Windows, macOS o Linux. Con il supporto di Windows 365, anch’esso disponibile per tutti, gli agenti possono girare anche sui Cloud PC.
I quattro livelli di contenimento
Microsoft offre diversi livelli di isolamento, da scegliere in base al carico di lavoro. Ogni backend ha proprietà di sicurezza distinte e va valutato per l’uso previsto.
| Backend | Disponibilità | Caratteristiche |
|---|---|---|
| Process container | Windows 11, macOS, Linux | Contenimento leggero: AppContainer su Windows, Seatbelt su macOS, Bubblewrap su Linux |
| Session container | Solo Windows 11 | Account e sessione Windows distinti, con desktop, appunti, interfaccia e input separati dall’utente |
| WSL container (WSLc) | Solo Windows 11 | Ambiente di esecuzione Linux tramite WSL, per toolchain Linux-first |
| MicroVM | Windows 11 e Linux, sperimentale | Isolamento imposto dall’hardware e piena compatibilità con i carichi Linux |
Cosa controlla una policy
La policy copre cinque aree:
- contenimento: l’ambiente di isolamento, per esempio un container di processo o di sessione;
- processo: comando, argomenti, directory di lavoro e ambiente con cui parte il carico;
- file system: percorsi modificabili, percorsi solo leggibili e percorsi inaccessibili;
- rete: connessioni in entrata e in uscita, compreso l’uso dell’interfaccia di loopback dell’host;
- interfaccia utente: se il carico può accedere al desktop e alle risorse grafiche collegate.
Nell’esempio del sito web, un agente potrebbe avere accesso al repository e a strumenti come Git, senza poter raggiungere la cartella Documenti, la rete o il desktop interattivo. Le organizzazioni possono aggiungere vincoli con policy di gestione come Microsoft Intune. Secondo Microsoft, le policy Intune per i process container su Windows 11 arriveranno a breve.
Tre modalità per scrivere una policy a privilegi minimi
Solo su Windows, i process container possono produrre un report JSON dell’attività con le risorse che il carico ha tentato di usare. Serve a scrivere una policy a privilegi minimi senza conoscere in anticipo ogni risorsa necessaria.
- Enforcement: applica la policy di produzione, blocca ciò che non è concesso e non genera report.
- Learning: continua a bloccare gli accessi non concessi e li registra nel report, per diagnosticare i fallimenti.
- Permissive: consente gli accessi che la policy negherebbe e li registra, senza aggirare altre restrizioni del sistema o dell’organizzazione. Serve a osservare l’attività dell’agente senza applicare la policy.
Il README nel repository MXC su GitHub descrive invece uno strumento distinto, la modalità di audit da riga di comando (--audit), e avverte che spegne tutta la sicurezza della sandbox per il carico analizzato e non va mai usata per eseguire codice non fidato.
Microsoft indica anche che un agente bloccato da una policy dovrebbe spiegare che il compito non è completabile con i permessi disponibili, chiedere un intervento o scegliere un’alternativa sicura, senza fallire in silenzio.
Identità degli agenti e chi supporta MXC
Windows permetterà presto a Microsoft Entra di distinguere l’attività di un agente da quella dell’utente in Microsoft Agent 365. Se un agente viene compromesso, i controlli potranno colpire il suo accesso alle risorse senza bloccare quello del dipendente. Anche i controlli di Agent 365 saranno estesi agli agenti locali per gestire i container MXC.
Secondo Microsoft, NVIDIA ha integrato OpenShell in MXC, aggiungendo controlli su file e servizi di inferenza, rete avanzata, gestione delle credenziali e audit OCSF per le aziende. Supportano già MXC GitHub Copilot, OpenClaw, OpenAI Codex, Replit, LM Studio e Unsloth AI. Tra i prossimi figurano Anthropic Claude Code, Box, Egnyte, Manus, Perplexity e Raycast.
SDK, schema di configurazione, documentazione ed esempi sono nel repository MXC su GitHub, dove si possono aprire segnalazioni. Dalla documentazione del repository, l’SDK è disponibile per Rust, .NET e Node.
