Il problema: agenti AI con troppi permessi

Gli agenti AI stanno entrando sempre più nei flussi di lavoro di sviluppo e amministrazione: scrivono codice, eseguono script, leggono configurazioni, chiamano API esterne. Il problema è che, nella maggior parte dei casi, un agente opera con gli stessi privilegi dell’utente che lo ha avviato. Un agente di coding che deve solo leggere la configurazione di un server potrebbe, per un errore di pianificazione o per un prompt injection, finire per modificare impostazioni di produzione o cancellare file che non dovrebbe nemmeno vedere.

Microsoft ha affrontato questo problema con Microsoft Execution Containers (MXC), un progetto open source (licenza MIT) ora disponibile in General Availability, pensato per eseguire carichi di lavoro non attendibili — output di modelli, plugin, tool chiamati da un agente — dentro confini di sicurezza applicati da policy, non lasciati all’autodisciplina del modello.

Cos’è MXC e come è strutturato

MXC non è un singolo sandbox, ma un livello di abstrazione che unifica diversi backend di containment dietro un’unica API, con SDK tipizzati per Rust, .NET e Node.js. L’applicazione che ospita l’agente specifica il tipo di container, le regole di contenimento e il comando da eseguire; MXC valida la richiesta e avvia il workload nel container scelto.

I backend disponibili variano per piattaforma:

• Windows 11: ProcessContainer (predefinito), Windows Sandbox, WSLC, microVM (sperimentale, basato su Nanovix), Hyperlight (sperimentale), IsolationSession per sessioni Windows isolate.
• Linux: Bubblewrap (predefinito), LXC, microVM, Hyperlight.
• macOS: Seatbelt (predefinito, unico backend disponibile).

Questo significa che lo stesso agente può girare in un container di processo leggero per compiti a basso rischio, oppure in una microVM con isolamento hardware quando il workload è più delicato — ad esempio quando esegue codice generato da un modello e mai eseguito prima.

Policy: filesystem, rete e interfaccia utente

Le policy si definiscono in JSON e coprono tre aree principali:

• Filesystem: percorsi accessibili in sola lettura, percorsi in lettura/scrittura, percorsi esplicitamente negati.
• Rete: comportamento di default (tipicamente “deny”), destinazioni consentite, supporto per proxy in uscita.
• UI: controllo su clipboard, accesso al display e interazione con l’interfaccia grafica, rilevante soprattutto per gli agenti che operano in una sessione Windows isolata.

Un esempio illustrativo, in stile SDK Node.js, di come potrebbe essere definita una richiesta di container per un agente che deve compilare un progetto senza accesso libero alla rete o ai file dell’utente:

import { spawn } from '@microsoft/mxc-sdk/v1';

const request = {
  container: 'process',
  command: ['node', 'build-agent.js'],
  filesystem: {
    readOnly: ['C:\\repos\\progetto\\src'],
    readWrite: ['C:\\repos\\progetto\\dist'],
    deny: ['C:\\Users\\*\\Documents', 'C:\\Users\\*\\Desktop']
  },
  network: {
    outbound: 'deny',
    allow: ['registry.npmjs.org:443']
  },
  timeoutMs: 30000
};

const result = await spawn(request);
console.log(result.exitCode, result.stdout);

Chi non vuole integrare l’SDK direttamente nell’applicazione può usare gli eseguibili nativi della piattaforma (ad esempio wxc-exec.exe su Windows), che accettano la stessa richiesta in formato JSON da riga di comando.

Diagnostica e modalità di apprendimento

Definire policy troppo restrittive rischia di bloccare attività legittime; policy troppo permissive vanificano lo scopo del sandbox. Per questo MXC offre due strumenti operativi:

# Esegue il container con output diagnostico dettagliato
wxc-exec.exe --debug config.json

# Registra tutti gli accessi effettuati dal workload, utile
# per costruire una policy realistica prima di applicarla
wxc-exec.exe --audit policy.json

La modalità --audit è pensata esplicitamente per la fase di tuning delle policy: osserva il comportamento reale dell’agente e segnala quali risorse tenta di usare. È importante sapere che in questa modalità il sandboxing è di fatto disattivato, quindi va eseguita solo con codice che si controlla, mai con workload realmente non attendibili.

Il ciclo di vita di un container persistente segue gli stati tipici provision → start → execute → stop → deprovision, utile per scenari in cui lo stesso agente esegue più task in sequenza senza il costo di ricreare l’ambiente ogni volta.

Integrazione nell’ecosistema Microsoft

MXC non vive isolato: Microsoft ha annunciato che la gestione centralizzata delle policy sui process container Windows 11 arriverà tramite Microsoft Intune, così i reparti IT potranno applicare regole di governance a livello di organizzazione invece di lasciare la configurazione al singolo sviluppatore. In prospettiva, anche Microsoft Entra e Microsoft Agent 365 dovrebbero fornire identità dedicate per gli agenti, distinte da quelle degli utenti umani, per poterne tracciare le azioni separatamente.