NVIDIA OpenShell: cos'è, come si installa e quando serve

NVIDIA OpenShell è un runtime open source (licenza Apache 2.0) che chiude un agente AI come Claude Code, Codex o Copilot CLI in una sandbox isolata a livello kernel e decide, con una policy scritta in YAML, quali file, siti, API e credenziali può usare. Si installa con un comando su Linux, macOS con Apple Silicon e, in via sperimentale, Windows con WSL 2. Non serve una GPU NVIDIA. Al 4 novembre 2026 la documentazione ufficiale è alla versione 0.1.7, e dalla 0.1.0 l'agente non è più preinstallato: va portato con un'immagine tua, come spiego più sotto. Il 28 settembre 2026 NVIDIA lo ha reso disponibile a tutti come parte della nuova Open Agent Safety Platform, insieme a Sentry, il "guardiano" hardware.

Io lavoro ogni giorno con agenti di programmazione e con agenti che toccano dati di aziende. Il problema che OpenShell prova a risolvere lo conosco bene: un agente che vuole finire il compito a tutti i costi prima o poi cerca una scorciatoia. In questa guida ti spiego cos'è OpenShell, come si installa, come si scrive una policy e, soprattutto, se ha senso per te.

Cos'è NVIDIA OpenShell, in parole semplici

Pensa a NVIDIA OpenShell come a un recinto con un buttafuori. L'agente lavora dentro una sandbox. Ogni volta che prova a leggere un file, aprire una connessione o usare una chiave API, un componente esterno controlla la richiesta contro le regole che hai scritto tu.

Il punto chiave è che le regole non stanno dentro l'agente. Non sono un prompt del tipo "per favore non cancellare niente". Sono applicate dal runtime, fuori dalla portata del modello. Se l'agente trova un modo creativo per aggirare un controllo applicativo, qui si ferma comunque.

OpenShell controlla quattro livelli:

• Filesystem: l'agente legge e scrive solo nei percorsi autorizzati. Questa regola si fissa quando crei la sandbox.
• Rete: le connessioni in uscita non autorizzate vengono bloccate. Questa regola si può cambiare mentre la sandbox gira.
• Processi: niente escalation di privilegi né chiamate di sistema pericolose. Anche questa è fissata alla creazione.
• Credenziali: le chiavi API arrivano alla sandbox tramite i provider che colleghi tu. Nelle prime versioni c'era anche un instradamento delle chiamate al modello verso backend controllati, ma dalla 0.1.0 i comandi openshell inference sono stati rimossi: ogni sandbox chiama il fornitore collegato con il suo endpoint nativo.

Perché NVIDIA lo ha lanciato adesso

Settembre 2026 è stato il mese degli incidenti con gli agenti. Ne ho parlato anche nell'articolo sul quarto incidente di Claude nei test di sicurezza e in quello su Plugin4Shell, la falla zero-click di Claude Code e Codex. Il filo comune è sempre lo stesso: l'agente aggira i controlli messi a livello di applicazione per portare a termine il lavoro.

La risposta di NVIDIA è spostare le regole un piano più in basso. Il ragionamento è semplice: un agente che devia dal compito non può essere lui a sorvegliare se stesso. Quindi il controllo deve stare fuori, nel runtime e, nei data center, direttamente nell'hardware.

OpenShell e Sentry: le due parti della Open Agent Safety Platform

La piattaforma annunciata il 28 settembre 2026 ha due pezzi che si usano anche separatamente.

OpenShell, il runtime software

È la parte che puoi usare oggi sul tuo computer o sul tuo server. Gira con Docker, Podman o virtualizzazione dell'host. Registra le azioni dell'agente e applica le policy. È esteso anche a piattaforme Arm e Intel x86, non solo alla CPU Vera di NVIDIA.

Sentry, il guardiano hardware

Sentry gira sulle DPU BlueField-4, schede di rete specializzate che lavorano in modo indipendente dal processore principale. Osserva l'agente da un dominio separato e, se prova a uscire dai confini, lo mette in quarantena in pochi millisecondi. È pensato per data center e aziende grandi: una PMI italiana difficilmente lo userà direttamente, ma potrebbe trovarlo nei servizi cloud che già paga.

Tra gli oltre 100 partner ci sono Anthropic, Microsoft, Salesforce, SAP, Cisco, CrowdStrike, Red Hat e Hugging Face. Anthropic lo integra nei Claude Managed Agents, Salesforce lo collega a Slack per approvare o rifiutare le richieste di nuovi permessi direttamente in chat.

Quali agenti AI supporta NVIDIA OpenShell

OpenShell supporta questi agenti, ma dalla versione 0.1.0 nessuno è preinstallato: l'immagine di partenza è una Ubuntu minimale senza le CLI degli agenti. Per ognuno ti serve un'immagine che contenga la CLI e un provider con la chiave giusta. OpenClaw passa invece da NemoClaw, lo stack di NVIDIA pensato per lui.

• Claude Code: con un'immagine che contiene la CLI e la chiave ANTHROPIC_API_KEY passata come provider. Serve una chiave API della Console Anthropic, non l'abbonamento Pro o Max.
• Codex: con un'immagine che contiene la CLI e OPENAI_API_KEY.
• OpenCode: con un'immagine che contiene la CLI e chiave OpenAI o OpenRouter.
• GitHub Copilot CLI: con un'immagine che contiene la CLI e token GitHub.
• OpenClaw e Hermes Agent: tramite NemoClaw, con inference gestita.

Se usi OpenClaw in azienda, ti consiglio di rileggere anche cosa cambia con OpenClaw 2.0 e gli agenti condivisi in team: sessioni condivise e permessi per ruolo sono proprio il caso in cui un recinto esterno fa la differenza.

Come installare NVIDIA OpenShell

Il progetto è in fase alpha, pensato per "uno sviluppatore, un ambiente, un gateway". Al 4 novembre 2026 la documentazione è alla versione 0.1.7. Attenzione se hai provato le prime versioni: la 0.1.0 ha cambiato parecchie cose, e una installazione 0.0.x non si aggiorna sul posto, va rimossa prima di installare la nuova. Ecco i passaggi base.

1. Installa la CLI

Il metodo consigliato è lo script ufficiale:

curl -LsSf https://raw.githubusercontent.com/NVIDIA/OpenShell/main/install.sh | sh

Lo script installa l'ultima versione stabile. Su Linux c'è anche il pacchetto snap (sudo snap install openshell), e per i team il chart Helm per Kubernetes, dalla versione 1.29 in su. In locale ti serve Docker 28 o successivo, oppure Podman 5. Il vecchio uv tool install -U openshell che trovi in giro non installa più la CLI: su PyPI oggi c'è l'SDK Python.

2. Crea una sandbox con il tuo agente

openshell sandbox create --from registry.example.com/tuo-team/claude-agent:latest --provider claude-code -- claude

Dalla versione 0.1.0 il comando corto openshell sandbox create -- claude, che trovi ancora in molte guide, non basta più. L'immagine predefinita è una Ubuntu 24.04 minimale, senza Claude Code, Codex o Copilot CLI e con la rete chiusa. Quindi prima costruisci e pubblichi un'immagine che contiene la CLI del tuo agente, poi la passi con --from. La chiave la colleghi con --provider, perché il comando finale non la aggancia più da solo: con claude-code OpenShell legge ANTHROPIC_API_KEY dalla tua shell. Il comando dopo -- è il processo principale della sandbox: claude, codex, opencode o copilot.

3. Verifica che la rete sia chiusa

Di default l'accesso in uscita è minimo. Una chiamata verso un'API non autorizzata riceve un 403 dal proxy. È il comportamento che vuoi: tutto chiuso, poi apri solo il necessario.

4. Applica una policy

openshell policy set demo --policy policy.yaml --wait

Le regole di rete si aggiornano senza riavviare la sandbox. Filesystem e processi invece richiedono una sandbox nuova.

5. Controlla cosa fa l'agente

Con openshell logs demo --tail vedi i log in tempo reale. Quando l'agente chiede una regola nuova, la vedi con openshell rule get demo --status pending e la approvi o la rifiuti tu con openshell rule approve o openshell rule reject. Con openshell term apri una dashboard nel terminale con tutte le sandbox.

Cosa cambia con OpenShell 0.1

Se hai letto guide uscite a settembre, o hai provato le versioni 0.0.x, queste sono le differenze che ti fanno perdere più tempo:

• Niente agenti preinstallati. L'immagine di partenza non contiene le CLI degli agenti e blocca la rete. L'agente lo porti tu, in un'immagine costruita e pubblicata prima: --from non costruisce più un Dockerfile al volo.
• Le credenziali vanno collegate a mano con --provider. I profili si chiamano claude-code e github, non più claude e gh.
• Niente aggiornamento sul posto. Una installazione 0.0.x va rimossa prima di installare la 0.1. Esporta i profili dei provider prima di toglierla.
• Policy più severe. Ogni binario si scrive solo con il suo path, come nell'esempio qui sotto, i campi che il runtime non conosce bloccano la policy invece di essere ignorati, e le opzioni tls: terminate e tls: passthrough non esistono più.

È più lavoro all'inizio, ma la direzione è giusta: ogni cosa che l'agente può fare la decidi tu, anche quale immagine usa.

Un esempio di policy YAML spiegato

Questa è la policy di esempio che permette di leggere da GitHub ma non di scriverci:

network_policies:
  github_api:
    name: github-api-readonly
    endpoints:
      - host: api.github.com
        port: 443
        protocol: rest
        enforcement: enforce
        access: read-only
    binaries:
      - path: /usr/bin/curl

Cosa dice, riga per riga:

• solo il programma /usr/bin/curl può parlare con api.github.com;
• solo sulla porta 443;
• solo in lettura: una richiesta POST per aprire una issue riceve policy_denied.

È un livello di dettaglio che con un normale container non hai: non autorizzi "internet", autorizzi un programma verso un host con un tipo di operazione.

Le tre funzioni che mi interessano di più

Le credenziali non entrano mai nella sandbox

Le chiavi API vengono gestite come "provider": pacchetti di credenziali iniettati a runtime e mai scritti sul filesystem della sandbox. Il privacy router sostituisce la chiave vera fuori dal workload, e solo verso gli endpoint autorizzati. Dopo aver letto il threat report di Anthropic sulle API key rubate, questa per me è la funzione più utile di tutte.

L'agente può chiedere, ma non approvarsi da solo

Con il policy advisor attivo, quando l'agente è bloccato può proporre una modifica mirata della policy. La proposta resta in attesa di revisione umana. L'agente non può approvare la propria richiesta.

La verifica formale delle policy

Prima di applicare una modifica, il policy prover verifica con la logica formale se i nuovi permessi restano nei confini stabiliti. Il risultato dipende dal modello della policy, non da quanto è convincente la spiegazione dell'agente. Un limite dichiarato al lancio della 0.1.0: l'analisi tra più agenti che collaborano non c'era ancora, quindi prima di contarci controlla la versione che installi.

NVIDIA OpenShell o Docker Sandbox: quale scegliere

La domanda è legittima, perché pochi giorni fa ho scritto una guida a Docker Sandbox per isolare Claude Code e Codex. Il mio modo di vederla:

• Docker Sandbox è la scelta più semplice se lavori da solo e vuoi isolare l'agente dal tuo computer in pochi minuti, anche in cloud.
• OpenShell è più adatto quando ti servono regole fini su singoli host e programmi, credenziali che l'agente non vede mai, approvazioni umane e log verificabili. In pratica quando l'agente lavora su dati o sistemi di un'azienda.

Non sono alternativi per forza: OpenShell stesso può appoggiarsi a Docker come motore di virtualizzazione. Su Mac, prima di dare a un agente l'accesso completo al disco, leggi anche cosa cambia con Full Disk Access.

NVIDIA OpenShell serve davvero a una PMI?

Dipende da cosa fa l'agente. Se lo usi solo per scrivere codice sul tuo portatile, oggi OpenShell è probabilmente più di quanto ti serve, e l'alpha va messa in conto.

Se invece hai un agente che legge la posta, aggiorna il gestionale, risponde ai clienti o tocca il CRM, il discorso cambia. È esattamente il tipo di progetto che seguo quando imposto automazioni e agenti AI per le aziende. In questi casi mi pongo sempre tre domande:

• se l'agente sbaglia, cosa può cancellare o inviare?
• dove stanno le chiavi API e chi le può vedere?
• posso ricostruire dopo cosa ha fatto, azione per azione?

Se non hai una risposta chiara, NVIDIA OpenShell merita una prova. E vale anche come difesa contro attacchi come l'HalluSquatting, dove l'agente installa pacchetti inventati: con rete e filesystem chiusi, il danno resta nel recinto.

Limiti di NVIDIA OpenShell da sapere prima di provarlo

• È alpha: pensato per un singolo sviluppatore, il multi-tenant aziendale è ancora in sviluppo.
• Windows solo via WSL 2 con Docker Desktop, e in via sperimentale.
• Le policy della 0.1 sono più rigide: se hai policy scritte per la 0.0.x, ricontrollale prima di riusarle.
• Supporto GPU sperimentale: richiede driver NVIDIA e Container Toolkit.
• Telemetria attiva di default: raccoglie solo categorie operative anonime, non prompt né credenziali. Si disattiva con OPENSHELL_TELEMETRY_ENABLED=false.
• Sentry non è per tutti: richiede DPU BlueField-4, quindi hardware da data center.

In sintesi

NVIDIA OpenShell porta le regole di sicurezza fuori dall'agente AI e dentro il runtime. È gratuito e open source, e si prova in mezz'ora con Claude Code o Codex, il tempo di preparare l'immagine con la CLI dell'agente. Oggi è uno strumento per chi sviluppa o per chi porta agenti in produzione su dati aziendali. Se sei nel secondo gruppo, è il momento di capire come si scrive una policy, prima che l'agente trovi una scorciatoia al posto tuo.

Se vuoi un parere su come mettere in sicurezza un agente che hai già in azienda, scrivimi.

Leggi anche

• Docker Sandbox: isolare Claude Code e Codex, anche in cloud
• Plugin4Shell: la falla zero-click di Claude Code e Codex
• Anthropic, 4° incidente di Claude: cosa insegna sugli agenti
• Codex Security di OpenAI: cos'è e quanto costa
• Full Disk Access su Mac: cosa cambia con gli agenti AI
• Claude Code mods: cosa sono e i rischi