Gli agenti AI lavorano su file, accedono alla rete, usano applicazioni. Il problema è che senza limiti possono combinare guai seri. Microsoft ha capito che lasciare tutto in mano a un modello generativo equivale a dare le chiavi di casa a uno sconosciuto particolarmente ottimista.
La risposta si chiama Microsoft Execution Containers (MXC), ora disponibile pubblicamente. È un sistema di contenimento basato su policy che definisce cosa un agente può e non può fare, applicando queste regole a livello di sistema operativo. Non è l’agente a decidere i propri limiti: è il container che li impone dall’esterno.
Perché un agente non può essere il proprio sceriffo
Immaginate di chiedere a un coding agent di aggiornare un sito web. L’agente ha bisogno di accedere al repository, modificare file, testare il codice. Magari anche leggere la configurazione del server di produzione per capire come funziona il deployment. Tutto sensato.
Cosa succede se l’agente decide che modificare direttamente la configurazione del server è la via più veloce per completare il task? Dal suo punto di vista è una scelta ragionevole. Dal vostro, è un disastro in produzione.
Ecco perché serve un confine che l’agente non può attraversare nemmeno volendo. MXC crea esattamente questo: l’agente può leggere e scrivere il repository, leggere la configurazione, ma non toccare altro. Se prova a modificare il server di produzione, il container blocca l’operazione. Non importa cosa decida il modello, il plugin o lo strumento: la policy vince sempre.
Cosa fa davvero Microsoft Execution Containers
MXC è un layer di esecuzione basato su policy, pensato per codice non affidabile o workload generati dinamicamente. In scenari agentici, potete usarlo per contenere l’output generato dal modello, i plugin, gli strumenti, l’harness dell’agente o l’intero agente stesso.
Gli sviluppatori dichiarano le risorse di cui il workload ha bisogno — file, destinazioni di rete, comandi — e MXC applica il confine con il container appropriato. La policy resta fuori dal controllo dell’agente. Niente auto-privilege escalation.
MXC separa i requisiti del workload dai dettagli specifici della piattaforma. Gli sviluppatori lavorano con uno schema JSON unificato e un SDK multi-linguaggio, mentre MXC mappa i controlli richiesti ai backend disponibili su Windows, macOS o Linux. Stesso modello di contenimento ovunque, dal device locale al cloud.
Quattro livelli di isolamento, per quattro scenari diversi
Non tutti i workload sono uguali. Un coding agent che lavora su un repository ha bisogno di bassa latenza. Un agente che processa dati sensibili o esegue codice non verificato ha bisogno di isolamento più forte. MXC offre uno spettro di opzioni:
- Process container (Windows 11, macOS, Linux): contenimento leggero per workload reattivi, incluso codice generato dal modello. Usa AppContainer su Windows, Seatbelt su macOS, Bubblewrap su Linux.
- Session container (solo Windows 11): per agenti long-running e automazione che hanno bisogno di un desktop separato. Gira sotto un account Windows distinto, con desktop, clipboard, UI e input isolati dall’utente interattivo.
- WSL container (solo Windows 11): per toolchain Linux-first e workload che dipendono dall’ecosistema di sviluppo Linux.
- MicroVM (Windows 11 e Linux, sperimentale): per workload ad alto rischio che beneficiano di un confine virtualizzato hardware-enforced. Isolamento hardware e piena compatibilità con workload Linux.
Come si scrive una policy MXC
La policy MXC definisce il confine operativo dell’agente. Invece di dargli i pieni poteri dell’utente loggato, sviluppatori e IT definiscono un perimetro applicato dal sistema operativo.
Per lo scenario del sito web, una policy MXC potrebbe dare all’agente accesso in lettura e scrittura al repository locale e accesso a strumenti di sviluppo come Git, bloccando al contempo la cartella Documenti dell’utente, le connessioni di rete in entrata e in uscita, e l’accesso al desktop interattivo.
Le aree coperte dalla policy:
- Containment: l’ambiente di isolamento (process o session container).
- Process: comando, argomenti, directory di lavoro, variabili d’ambiente.
- File system: quali location l’agente può modificare, quali può solo leggere, quali sono off-limits.
- Network: connettività in entrata e uscita, incluso l’accesso ai servizi tramite loopback dell’host.
- User interface: se il workload può accedere o interagire con desktop e risorse UI.
Potete usare il vostro coding agent preferito per integrare l’SDK e generare una policy iniziale, poi revisionarla, testarla e affinarla.
Policy aziendale vs policy del workload
Gli sviluppatori dichiarano cosa serve ai loro agenti. Le organizzazioni possono applicare ulteriori restrizioni via policy di gestione, come quelle di Microsoft Intune. Lo stesso agente può così operare dentro confini enterprise diversi senza che lo sviluppatore debba codificare la security posture dell’organizzazione nell’app.
Intune policy sarà presto disponibile per gestire i process container MXC usati da agenti integrati su Windows 11. Gli amministratori IT controlleranno come Windows valuta le richieste di creazione container e quali confini di risorse vengono applicati.
Gli sviluppatori devono progettare i workload per operare dentro confini potenzialmente più restrittivi del default. Se la policy aziendale blocca una risorsa, l’agente dovrebbe spiegare che il task non può essere completato con i permessi disponibili, richiedere un’azione utente o amministrativa quando supportata, o scegliere un’alternativa sicura. Non fallire in silenzio.
Osservare prima di imporre
Scrivere una policy a privilegi minimi è difficile quando non sapete ancora ogni risorsa di cui il workload ha bisogno. Solo su Windows, i process container MXC producono un agent activity report che mostra quali risorse il workload ha tentato di usare, utile per costruire una policy least-privilege.
MXC supporta tre modalità operative:
- Enforcement: le operazioni concesse procedono, quelle fuori dal confine vengono bloccate. Nessun report di attività.
- Learning: applica la policy e registra gli accessi negati in un report JSON. Utile per diagnosticare failure e verificare che la policy conceda solo l’accesso necessario.
- Permissive: registra gli accessi che la policy avrebbe negato, ma lascia procedere l’operazione. Il workload si completa mentre raccogliete evidenze sulle risorse usate.
La modalità Permissive non bypassa altre restrizioni del sistema operativo o organizzative. Quando portate un agente in un container MXC per la prima volta, i denial rivelano dove il confine va aggiustato, permettendovi di concedere l’accesso richiesto senza espandere inutilmente la portata dell’agente.
Identità e attribuzione degli agenti
Il contenimento risponde a «cosa può fare un agente». L’identità aiuta a determinare «quale agente ha fatto cosa». In arrivo: Windows permetterà a Microsoft Entra di distinguere l’attività dell’agente da quella dell’utente in Microsoft Agent 365.
Questa separazione permetterà ai team di sicurezza di valutare il comportamento e il rischio di un agente indipendentemente dalla persona che usa il device. Se un agente viene compromesso o viola una policy, i controlli colpiranno l’accesso dell’agente senza bloccare quello del dipendente.
L’attribuzione a livello di agente migliora anche investigazione e governance. Gli amministratori potranno usare Agent 365 per capire quali agenti stanno girando, associare attività a un agente specifico, investigare comportamenti rischiosi e applicare policy a singoli agenti o gruppi, invece di affidarsi solo a contesto user-level o device-level.
Chi usa MXC oggi
NVIDIA ha integrato OpenShell in MXC, aggiungendo controlli policy per l’accesso degli agenti a file e servizi di inferenza, controlli di rete avanzati, gestione delle credenziali e auditing OCSF per le enterprise.
Supportano già MXC: GitHub Copilot, OpenClaw, OpenAI Codex, Replit, LM Studio, Unsloth AI. In arrivo il supporto di Anthropic Claude Code, Box, Egnyte, Heidi Health, Hermes Agent by Nous Research, Manus, Perplexity, Raycast, Simular.
GitHub Copilot, Codex e Replit mostrano come MXC regga workflow di sviluppo intensi. Un coding agent accede al repository, agli strumenti di sviluppo e ai comandi necessari per completare un task, ma non guadagna automaticamente accesso a file o destinazioni di rete non correlate. MXC preserva le capacità necessarie e blocca il resto.
