Agenti AI: permessi e sandbox con NVIDIA OpenShell

Come NVIDIA OpenShell controlla gli agenti AI

OpenShell è un runtime open source: l'ambiente che esegue un agente e ne controlla gli accessi. Opera al di sotto dell'agente, senza sostituirne il ragionamento o gli strumenti.

Immaginiamo un tecnico esterno al lavoro in un edificio. Gli si assegnano un laboratorio, l'accesso ad alcune stanze e il permesso di contattare determinati fornitori. Non gli si consegna il passepartout solo perché nell'incarico c'è scritto «fare attenzione». OpenShell fornisce questi confini agli agenti software.

La panoramica del runtime descrive restrizioni sul filesystem, controlli di rete, vincoli sui processi e protezione delle credenziali dei provider. Landlock è il meccanismo del kernel Linux che limita l'accesso ai file; seccomp limita le chiamate di sistema, cioè le richieste di basso livello che un programma invia al sistema operativo. Questi vincoli vengono applicati al di fuori del ragionamento dell'agente.

Il gateway gestisce sandbox e accessi. Un supervisore esterno alla sandbox verifica le richieste in uscita rispetto alla policy e fornisce le credenziali quando consentito. Il verificatore delle policy controlla che i permessi modellati rispettino i confini definiti. Sono controlli su ciò che un agente può fare, non una garanzia che il lavoro autorizzato sia corretto.

NVIDIA indica percorsi di utilizzo per Claude Code, Codex, GitHub Copilot CLI, Hermes, LangChain Deep Agents, OpenClaw e OpenCode, oltre ad agenti e immagini personalizzati. «Supportato» non significa che ogni strumento sia preinstallato: il carico di lavoro predefinito attuale usa un'immagine Ubuntu minimale senza le CLI degli agenti, ossia i programmi a riga di comando con cui si avviano gli agenti.

Per l'azienda, la novità è poter riutilizzare i permessi. Senza confini riutilizzabili, ogni nuovo workflow con agenti può richiedere di decidere nuovamente quali file, segreti e servizi esporre. Con questi confini, il team può includere tali decisioni nella configurazione del carico di lavoro e verificarne le modifiche. L'effetto va misurato nelle ore che gli ingegneri dedicano alla configurazione degli accessi e alle interruzioni: non esiste un dato universale verificato sul risparmio di tempo da citare.

Su quali sistemi funziona oggi?

Per scegliere l'host bisogna fare riferimento alla matrice di supporto attuale. Questa guida segue la documentazione contrassegnata v0.1.7, verificata l'8 novembre 2026.

WSL 2 esegue un ambiente Linux su Windows. MXC è un percorso di isolamento distinto, nativo per Windows. Non bisogna quindi considerare il «supporto Windows» come un unico metodo di installazione intercambiabile.

L'annuncio della collaborazione su Windows descrive l'arrivo di OpenShell su Windows tramite MXC. Questa direzione di sviluppo non rende oggi il percorso nativo una normale installazione stabile. La documentazione attuale specifica che i canali di rilascio standard non distribuiscono binari nativi per Windows.

Per una prima valutazione, conviene scegliere una configurazione supportata su Linux o Apple Silicon. La matrice di supporto specifica anche i requisiti del kernel e del runtime: Linux 6.2 ha introdotto l'ABI Landlock richiesta, ma la sola versione del kernel non basta. Il runtime deve superare i controlli previsti. Nel percorso macOS con Docker Desktop, queste funzionalità Linux operano nella sua macchina virtuale Linux. Non sono necessarie CPU NVIDIA Vera.

Installare la CLI e avviare il primo agente

Il punto di partenza è l'esempio con OpenCode documentato da NVIDIA. Rende evidenti i tre elementi necessari: un provider per l'accesso al servizio, un'immagine che contiene l'agente e una sandbox in cui eseguirlo. I passaggi derivano dalla documentazione; non costituiscono il resoconto di una prova locale.

1. Preparare l'host e installare OpenShell. Per il percorso Docker, occorre avere Docker Desktop in esecuzione oppure Docker Engine 28.0 o successivo. Sui sistemi Linux o macOS supportati, la guida all'installazione utilizza curl -LsSf https://raw.githubusercontent.com/NVIDIA/OpenShell/main/install.sh | sh. Esaminare lo script di installazione prima di eseguirlo. Installa la CLI, il verificatore delle policy e il gateway locale. Eseguire openshell status per verificare che la CLI raggiunga il gateway.

2. Configurare il servizio del modello. L'esempio usa OpenRouter. Impostare OPENROUTER_API_KEY nell'ambiente dell'host prima di creare il provider. Un profilo del provider descrive gli endpoint dei servizi e i percorsi degli eseguibili consentiti; il provider conserva le credenziali. Il profilo di esempio di NVIDIA permette a /usr/local/bin/opencode di raggiungere openrouter.ai.

3. Importare il profilo, creare il provider e avviare l'immagine. Eseguire sull'host questi comandi, nell'ordine indicato:

openshell profile import \
  --url https://raw.githubusercontent.com/NVIDIA/OpenShell/main/providers/openrouter.yaml
openshell provider create \
  --name openrouter --type openrouter --from-existing
openshell sandbox create \
  --name my-agent \
  --from ghcr.io/anomalyco/opencode:latest \
  --provider openrouter \
  -- opencode -m openrouter/nvidia/nemotron-3.5-lightning:free

L'immagine fornisce OpenCode; il comando dopo -- lo avvia come processo principale. La guida al primo agente usa questo modello gratuito senza richiedere crediti OpenRouter. È la scelta del modello per quell'esempio, non la promessa che l'uso di qualunque modello sia gratuito.

4. Esaminare le richieste di accesso dall'host. Quando un agente tenta di raggiungere una destinazione non approvata, OpenShell blocca la richiesta e prepara una proposta di regola circoscritta. Eseguire openshell rule get my-agent --status pending. Se una proposta corrisponde all'accesso previsto per l'incarico, approvare quella specifica proposta con openshell rule approve my-agent --chunk-id <chunk-id>, sostituendo il segnaposto con l'ID effettivo. La regola viene ricaricata e l'agente può riprovare.

5. Controllare i permessi effettivamente concessi. Eseguire openshell policy get my-agent --base, poi openshell policy get my-agent --full. Il primo comando mostra la policy di base; il secondo include le regole aggiunte dai provider. Esaminare i permessi effettivi prima di aggiungere un progetto reale o un servizio sensibile.

Al termine di una valutazione usa e getta, eliminare la sandbox con openshell sandbox delete my-agent.

Quali policy si possono modificare a caldo?

L'accesso alla rete può cambiare durante un'attività. Per modificare i confini del filesystem e dei processi occorre creare una nuova sandbox.

Anche le modifiche «a caldo» hanno conseguenze. Le nuove regole di rete chiudono le connessioni aperte con le regole precedenti, quindi i client devono riconnettersi. Registrare un nuovo servizio middleware esterno richiede la configurazione e il riavvio del gateway. Aggiungere un percorso del filesystem alla policy salvata non lo rende accessibile al carico di lavoro già in esecuzione; la rimozione di percorsi o la modifica delle impostazioni iniziali vengono rifiutate dopo l'avvio. La guida alla gestione delle policy chiarisce queste differenze.

C'è un'altra insidia: l'assenza di un file di policy non implica l'assenza di accesso. Una policy può provenire dall'immagine, da un'impostazione d'ambiente o da una policy globale del gateway. I provider collegati possono aggiungere regole di rete. Le regole di selezione della policy chiariscono inoltre che una policy globale sostituisce quella della sandbox: non è semplicemente un ulteriore livello restrittivo.

Una policy per agenti di programmazione facile da verificare

Prima di autorizzare un agente a pubblicare modifiche, assegnargli una directory di progetto scrivibile e un accesso alle API in sola lettura per correggere un bug.

Ecco una policy illustrativa per un'immagine di sviluppo già preparata, con il progetto in /workspace e curl installato in /usr/bin/curl. Salvarla come policy.yaml e passare --policy ./policy.yaml quando si crea una nuova sandbox. È un modello per quella disposizione dei file nell'immagine, non una sostituzione pronta all'uso per qualsiasi immagine di agente:

version: 1
filesystem_policy:
  include_workdir: false
  read_only: [/usr, /lib, /etc]
  read_write: [/workspace, /tmp]
landlock:
  compatibility: hard_requirement
network_policies:
  github_readonly:
    endpoints:
      - host: api.github.com
        port: 443
        protocol: rest
        enforcement: enforce
        access: read-only
    binaries:
      - path: /usr/bin/curl

L'agente può modificare il progetto e i file temporanei. La regola di rete consente all'eseguibile indicato di inviare richieste GET, HEAD e OPTIONS alle API di GitHub. Non concede accesso a Internet a programmi arbitrari, non autorizza il download di pacchetti e non consente il push con Git. Il provider del modello si configura separatamente.

Preparare le eventuali directory scrivibili necessarie all'immagine per lo stato dell'agente e aggiungerle in modo esplicito. Questi percorsi si riferiscono al filesystem della sandbox. Non bisogna presumere che una directory dell'host con un nome simile sia automaticamente disponibile. Inoltre, per i carichi di lavoro con accesso alla rete vengono aggiunti percorsi di base del filesystem: il breve YAML non implica quindi che il confine effettivo comprenda soltanto i percorsi elencati.

Due impostazioni meritano attenzione. hard_requirement impedisce l'avvio se le regole del filesystem definite dall'utente non possono essere applicate, anche se singoli percorsi mancanti o inaccessibili possono comunque essere ignorati. enforcement: enforce blocca le richieste ispezionate non consentite; la modalità predefinita dello schema, audit, registra le violazioni e permette quelle richieste. Consultare il riferimento dello schema delle policy prima di adattare il modello.

Verificare sia ciò che viene consentito sia ciò che viene rifiutato. Il tutorial sulle policy di rete di NVIDIA controlla che curl -s https://api.github.com/zen riesca con la regola di sola lettura, poi verifica che una richiesta POST venga bloccata. Ispezionare openshell logs my-agent --since 5m --source sandbox dall'host. Per il proprio progetto, verificare anche una scrittura prevista su file e un accesso a file esterno all'ambito consentito. L'avvio riuscito dell'agente non costituisce il test di accettazione di una policy di sicurezza.

Cinque workflow da provare per primi

I migliori impieghi iniziali hanno un incarico ben delimitato e una persona in grado di valutare il risultato. Eccoli ordinati per probabile valore operativo:

Nessuno di questi workflow rende corretto il codice generato o affidabile la diagnosi di un incidente. Il valore consiste nel limitare ciò che può accadere mentre l'agente lavora. Per una scelta più ampia degli strumenti, consultare I migliori strumenti di sicurezza per sandbox AI del 2026; per scegliere una piattaforma di esecuzione, Le migliori sandbox di codice per agenti AI del 2026.

Due opportunità da sviluppare intorno a OpenShell

L'opportunità più promettente è un kit per introdurre gli agenti di programmazione nel team. Il cliente è un responsabile di piattaforma che vuole rendere produttivi gli sviluppatori all'interno di un ambiente approvato. DataForSEO stima 1,300 ricerche mensili per “claude code sandbox” nel mercato restituito dalla query di questa esecuzione. Il dato segnala interesse per la configurazione, non 1,300 potenziali clienti; inoltre, alcuni utenti cercano la sandbox dell'agente stesso, non OpenShell.

La versione minima vendibile potrebbe supportare un agente e una configurazione host approvata: un'immagine preparata, una policy verificata, una checklist per configurare il provider e test ripetibili delle operazioni consentite e negate. Il prodotto da vendere è un'introduzione operativa nel team, con responsabilità chiare sugli aggiornamenti. Il problema è la manutenzione: percorsi delle immagini, comportamento degli agenti e interfacce sperimentali possono cambiare. Prima di costruire un prodotto in hosting, intervistare i responsabili di piattaforma su questo onere di manutenzione.

La seconda opportunità è un ambiente di revisione delle policy. I team di sicurezza potrebbero usarlo per capire cosa consente una policy effettiva, confrontare le modifiche e registrare le approvazioni. DataForSEO stima 480 ricerche mensili per “ai agent security”, con 70 per “ai agent security tools.” Sono query distinte che indicano una domanda ampia: non vanno sommate come se rappresentassero acquirenti unici.

Un MVP potrebbe importare policy di base ed effettive, evidenziare le destinazioni e i permessi sulle richieste aggiunti e allegare i risultati dei test a una scheda di revisione. Il problema è differenziarsi: OpenShell offre già analisi delle policy, proposte e log. Il prodotto deve migliorare il processo di revisione del team, anziché limitarsi a racchiudere comandi esistenti in una dashboard. Conviene partire dal kit di adozione, perché cliente e risultato da consegnare sono più facili da definire.

Quali problemi non risolve?

OpenShell limita gli accessi; non decide se un'azione consentita sia una buona scelta aziendale. Un agente autorizzato a scrivere nei file del progetto può comunque produrre una patch sbagliata. Una destinazione esterna approvata può comunque ricevere i dati che la policy permette di inviarle. L'accesso ai file e l'approvazione degli endpoint devono riflettere ciò che si intende effettivamente esporre.

Non sostituisce nemmeno i sistemi di identità, gli archivi dei segreti, il monitoraggio o la governance. L'annuncio dei controlli del runtime di NVIDIA colloca l'applicazione dei vincoli al di fuori del carico di lavoro dell'agente. È una parte del sistema circostante, non un motivo per eliminare il resto.

Il progetto dispone ora di versioni stabili destinate alla produzione entro la propria matrice di supporto: descrivere tutto OpenShell come una demo sperimentale sarebbe quindi fuorviante. I limiti sono più precisi: le interfacce sperimentali possono cambiare nelle versioni patch, il percorso Windows nativo resta in sviluppo e NVIDIA dichiara che il suo attuale profilo di qualificazione non copre l'intera policy di qualificazione dei rilasci. Fissare le versioni distribuite e validare l'esatta combinazione di carico di lavoro e host.

Da fare lunedì: chiedere al responsabile di piattaforma di scegliere un repository non sensibile e un agente. Installare su un host supportato, preparare l'immagine, definire gli accessi a file e rete, poi verificare un'operazione consentita e una bloccata. Registrare il tempo di configurazione e le ore che gli ingegneri dedicano alla gestione delle interruzioni nella prima settimana. Ampliare l'uso solo quando il team sa spiegare ogni permesso concesso.

Per integrare questi controlli nel workflow del team, possiamo aiutarvi a predisporre i controlli per la produzione.