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. 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.
- Inference: le chiamate al modello possono essere reindirizzate verso backend controllati. Si può riconfigurare a runtime.
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
Alcuni agenti funzionano subito, altri passano da NemoClaw, lo stack di NVIDIA pensato per OpenClaw.
- Claude Code: funziona subito, con
ANTHROPIC_API_KEY. - Codex: funziona subito, con
OPENAI_API_KEY. - OpenCode: funziona subito, con chiave OpenAI o OpenRouter.
- GitHub Copilot CLI: funziona subito, con 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, versione 0.1.x, pensato per "uno sviluppatore, un ambiente, un gateway". Aspettati qualche spigolo. 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 | shIn alternativa, se usi uv: uv tool install -U openshell. Esiste anche un chart Helm per Kubernetes, ancora sperimentale.
2. Crea una sandbox con il tuo agente
openshell sandbox create -- claudeAl posto di claude puoi scrivere codex, opencode o copilot. La sandbox parte con Python 3.14, Node 22, git e gli strumenti di rete di base.
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 --waitLe 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. Con openshell term apri una dashboard nel terminale con tutte le sandbox.
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/curlCosa dice, riga per riga:
- solo il programma
/usr/bin/curlpuò parlare conapi.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: nella 0.1.0 l'analisi tra più agenti che collaborano non c'è ancora.
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.
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, e in via sperimentale.
- 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, open source e si prova in cinque minuti con Claude Code o Codex. 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.
