Microsoft rende disponibili i contenitori che limitano gli agenti AI

Microsoft rende disponibili i suoi Execution Containers, un livello di contenimento che permette a sviluppatori e amministratori di stabilire quali file e destinazioni di rete un agente AI può usare. La regola decisiva è che i permessi vengono fissati fuori dal modello e applicati durante l’esecuzione: l’agente non dovrebbe poterli ampliare da solo per completare un compito.

La novità, annunciata il 7 ottobre, affronta un problema concreto per chi collega agenti a codice e strumenti aziendali: concedere accesso può accelerare il lavoro, ma un’azione sbagliata può propagarsi ai sistemi a cui l’agente è collegato. Microsoft propone un confine tecnico da configurare prima dell’avvio.

Che cosa è successo

Microsoft Execution Containers, o MXC, è descritto come uno strato di esecuzione basato su policy per codice non attendibile e processi generati dinamicamente. Un team può dichiarare le risorse richieste da un’attività, come cartelle e destinazioni di rete; la piattaforma applica le restrizioni tramite il contenitore appropriato. Microsoft indica supporto per scenari locali e cloud e disponibilità generale anche per Windows 365.

L’esempio dell’azienda è un agente di programmazione che deve aggiornare un sito. Può leggere e modificare il repository e consultare la configurazione del server, ma non dovrebbe poterla cambiare se quel permesso non è stato concesso. Il confine vale per il carico di lavoro contenuto e mira a impedire che l’agente o il codice generato aggirino la policy per ottenere accesso aggiuntivo.

Il controllo dei permessi e l’identificazione dell’agente sono però due funzioni diverse. Microsoft dice che l’integrazione con Entra per distinguere le azioni dell’agente da quelle dell’utente e l’estensione dei controlli Agent 365 ai dispositivi locali arriveranno in futuro. Quindi MXC è disponibile, mentre attribuzione e gestione centralizzata degli agenti locali sono indicate come funzionalità prossime.

Neowin ha riportato l’annuncio e descritto il modello come un livello basato su policy che restringe file, rete, processi e accesso al sistema. Il resoconto indipendente conferma la disponibilità generale, ma non costituisce una prova di sicurezza per ogni configurazione o ambiente operativo.

Il punto che rischia di passare inosservato

Un contenitore riduce ciò che un errore può raggiungere; non dimostra che le istruzioni dell’agente siano corrette, che il codice prodotto sia sicuro o che i dati esposti all’interno del perimetro siano appropriati. Anche una policy troppo ampia può consentire danni. La qualità dipende da come l’organizzazione traduce il compito in permessi minimi e da come controlla i risultati.

La parola contenitore può far pensare a una protezione pronta all’uso. In realtà serve integrare MXC nel flusso di lavoro, definire risorse e livelli di isolamento e verificare che i permessi siano compatibili con dipendenze, strumenti e rete necessari. Se un agente necessita di accesso ampio per funzionare, il rischio non scompare: deve essere valutato e gestito esplicitamente.

Un agente può essere utile solo entro permessi che l’organizzazione può spiegare e verificare.

Che cosa cambia per imprese e professionisti

Per una software house o una PMI che prova agenti di coding, MXC può offrire un punto di partenza per confinare l’accesso al repository di test, bloccare destinazioni di rete non necessarie e impedire modifiche a file sensibili. Il primo progetto pilota dovrebbe usare un ambiente non produttivo e un elenco esplicito di operazioni consentite.

Per responsabili IT e consulenti, l’attività principale resta progettare la policy: quali cartelle può leggere l’agente, dove può scrivere, quali servizi può contattare e chi approva gli aggiornamenti. Serve anche registrare le operazioni rilevanti e predisporre un modo per interrompere il processo. La disponibilità tecnica non sostituisce un’analisi dei rischi né una verifica dei requisiti legali e contrattuali.

Che cosa osservare adesso

Da seguire sono la documentazione di configurazione, le differenze tra i sistemi di contenimento sottostanti e i tempi effettivi delle funzioni Entra e Agent 365 annunciate come future. Prima di adottarlo, un team dovrebbe provare anche tentativi di accesso negato, richieste malevole contenute nei file e interruzioni di rete.

Il criterio di valutazione è concreto: l’agente completa il compito previsto e si ferma quando tenta un’azione fuori perimetro? Solo test ripetibili su ambienti reali possono mostrare se il confine resta efficace nelle condizioni operative dell’organizzazione.

Per approfondire

Per il contesto ANPAI: Come definire confini e controlli per gli agenti AI

Le fonti

Microsoft Windows Developer Blog — Microsoft Execution Containers, 7 ottobre 2026 · Neowin — Microsoft Execution Containers (MXC) hits general availability, 7 ottobre 2026

Questa analisi della redazione ANPAI aiuta a leggere fatti e conseguenze operative. Non sostituisce una valutazione tecnica o legale riferita a un caso specifico.