Gli agenti basati sull’intelligenza artificiale stanno rapidamente passando dalla semplice generazione di testo alla capacità di eseguire codice, leggere e modificare file, utilizzare API, installare pacchetti e interagire con servizi esterni.
È proprio questo il loro punto di forza, ma anche uno dei principali problemi di sicurezza.
Se concediamo a un agente AI accesso alla shell del nostro computer, al filesystem, alle credenziali e a Internet, stiamo sostanzialmente dando a un software autonomo la possibilità di operare all’interno della nostra infrastruttura.
È in questo contesto che si inserisce NVIDIA OpenShell, un progetto open source progettato per fornire un ambiente di esecuzione isolato e controllato per gli agenti AI.
Il progetto è disponibile su GitHub con licenza Apache 2.0.
Il problema: un agente AI può fare molto più di una chatbot
Un normale chatbot può limitarsi a rispondere a una domanda.
Un agente, invece, può ricevere un obiettivo e utilizzare strumenti per raggiungerlo.
Per esempio:
Questa autonomia introduce una superficie di attacco completamente diversa.
Un agente compromesso, un prompt malevolo contenuto in un repository o semplicemente una policy troppo permissiva potrebbero consentire operazioni non desiderate.
La domanda quindi non è più soltanto:
“Quanto è intelligente il modello?”
ma anche:
“Che cosa gli permettiamo concretamente di fare?”
OpenShell: il modello non deve avere accesso diretto al sistema
OpenShell affronta il problema creando una sandbox nella quale viene eseguito l’agente.
L’idea è abbastanza semplice:
L’agente non viene quindi lasciato libero di interagire direttamente con tutto il sistema.
OpenShell applica policy che stabiliscono quali risorse possono essere utilizzate.
Il progetto utilizza diversi livelli di isolamento e controllo, tra cui filesystem, processi, rete e accesso ai provider.
Policy dichiarative
Uno degli aspetti più interessanti è il modello basato sulle policy dichiarative.
Invece di affidarsi esclusivamente alle istruzioni contenute nel prompt, l’amministratore può definire ciò che l’agente è autorizzato a fare.
Per esempio, una policy può stabilire:
- quali directory sono accessibili;
- quali operazioni sul filesystem sono consentite;
- quali processi possono essere eseguiti;
- quali destinazioni di rete sono raggiungibili;
- quali API possono essere utilizzate;
- quali credenziali possono essere associate a determinati endpoint.
Le policy vengono definite attraverso configurazioni YAML e OpenShell le applica a livello del runtime.
Questo porta a un concetto importante:
Il prompt dice all’agente cosa dovrebbe fare. La policy stabilisce cosa può effettivamente fare.
Sono due livelli di controllo completamente differenti.
Anche la rete viene controllata
Uno degli aspetti più interessanti di OpenShell riguarda l’accesso alla rete.
Una sandbox parte con un accesso esterno fortemente limitato. Le connessioni in uscita possono essere autorizzate attraverso policy che possono arrivare a controllare anche il metodo HTTP e il percorso richiesto.
In pratica, non è necessariamente sufficiente dire:
"puoi raggiungere github.com"
La policy può arrivare a distinguere tra operazioni consentite e non consentite.
Ad esempio:
GET /repos/example/project
→ consentito
POST /repos/example/project/issues
→ negato
La documentazione di OpenShell mostra proprio questo tipo di controllo durante il quickstart del progetto.
Questo è particolarmente interessante per gli agenti che lavorano con repository Git, API SaaS e servizi cloud.
Le credenziali non vengono semplicemente consegnate all’agente
C’è poi un altro problema molto importante: le API key.
Un agente che dispone direttamente di una chiave API potrebbe potenzialmente utilizzarla per operazioni diverse da quelle previste.
OpenShell introduce il concetto di provider.
Le credenziali vengono associate a provider ed endpoint autorizzati e vengono rese disponibili all’agente solo quando la richiesta soddisfa le regole previste dalla policy.
L’architettura diventa quindi:
L’obiettivo è evitare che l’agente debba conoscere direttamente tutte le credenziali necessarie per lavorare.
Un’architettura a più livelli
OpenShell implementa una strategia di defense in depth.
I principali domini di protezione sono:
| Livello | Funzione |
|---|---|
| Filesystem | Limita lettura e scrittura |
| Processi | Riduce privilegi e capacità del processo |
| Network | Controlla le connessioni in uscita |
| Provider | Gestisce endpoint e credenziali |
| Sandbox | Isola l’ambiente dell’agente |
A livello Linux vengono utilizzati meccanismi come Landlock, seccomp, no_new_privs e processi senza capacità privilegiate.
Questo è importante perché la sicurezza non dipende da una singola barriera.
Se una policy di rete viene aggirata, ad esempio, esistono comunque altri livelli di isolamento.
E c’è anche un policy prover
Una caratteristica particolarmente interessante delle versioni attuali di OpenShell è il controllo delle modifiche alle policy.
Il progetto utilizza un meccanismo di formal verification per verificare cosa potrebbe essere consentito da una modifica prima che venga applicata.
L’obiettivo è individuare, per esempio, se una nuova policy concede inavvertitamente accesso a un nuovo host o a un endpoint con credenziali.
È un approccio significativo perché sposta parte della sicurezza:
Non è legato a un solo agente
OpenShell non è un modello AI.
È un runtime nel quale possono essere eseguiti diversi agenti.
La documentazione attuale indica il supporto per strumenti come:
- Claude Code
- OpenCode
- Codex
- GitHub Copilot CLI
e sono disponibili anche integrazioni/community workflow per altri agenti, compreso Ollama.
Questo rende il progetto interessante anche in scenari self-hosted.
L’architettura può infatti separare:
Il modello può quindi cambiare senza dover ripensare necessariamente tutta l’infrastruttura di sicurezza.
Docker, Podman, MicroVM e Kubernetes
OpenShell non è limitato a un singolo tipo di infrastruttura.
Il gateway può utilizzare diversi backend di esecuzione, tra cui:
- Docker
- Podman
- MicroVM
- Kubernetes
Il progetto può quindi essere utilizzato sia in scenari locali sia in infrastrutture più strutturate.
È inoltre disponibile un SDK per diversi linguaggi, tra cui Python, TypeScript, Go e Rust.
Perché è interessante per l’AI locale
Per chi utilizza modelli locali, il concetto è particolarmente interessante.
Immaginiamo un server con:
L’LLM può essere completamente locale, mentre l’agente può essere confinato in una sandbox con accesso soltanto alle risorse necessarie.
Questo permette di ragionare su architetture nelle quali modello, dati e agente possono essere mantenuti all’interno della propria infrastruttura, senza concedere all’agente accesso indiscriminato al server.
Un esempio concreto
Immaginiamo un agente incaricato di analizzare un progetto software.
Potremmo concedergli:
/project
READ + WRITE
/tmp
READ + WRITE
github.com
GET
registry.npmjs.org
GET
ma impedire:
/home
DENY
/etc
DENY
database-server.local
DENY
POST github.com
DENY
L’agente rimane quindi operativo, ma all’interno di un perimetro definito.
È un concetto fondamentale per l’evoluzione degli agenti AI:
autonomia non significa necessariamente accesso illimitato.
OpenShell è open source
Il progetto è distribuito con licenza Apache 2.0 ed è sviluppato pubblicamente su GitHub.
Il repository sta inoltre evolvendo rapidamente e comprende CLI, gateway, policy engine, SDK e componenti per la gestione delle sandbox.
La documentazione ufficiale è disponibile qui:
Documentazione NVIDIA OpenShell
Il vero significato di OpenShell
La parte più interessante di OpenShell non è semplicemente la possibilità di eseguire Claude Code o Codex dentro un container.
Il punto più importante è architetturale.
Con l’aumento dell’autonomia degli agenti, la sicurezza dell’AI non può più essere affrontata soltanto a livello del modello.
Servono almeno tre livelli:
È proprio quest’ultimo livello che progetti come OpenShell stanno cercando di rendere una componente standard dell’infrastruttura AI.
E questa potrebbe essere una delle evoluzioni più importanti dell’AI agentica nei prossimi anni:
non soltanto modelli più intelligenti, ma agenti sempre più autonomi che operano all’interno di ambienti verificabili, isolati e controllabili.
Per chi sta costruendo infrastrutture AI locali, sistemi RAG, coding agent o veri e propri AI agent autonomi, OpenShell è quindi un progetto da seguire con particolare attenzione.
