Isolare un agente di intelligenza artificiale: dove conviene mettere il limite
Un agente isolato è un agente che può leggere un file, avviare un processo o aprire una connessione di rete soltanto se una regola scritta fuori da lui lo consente. Fino a pochi giorni fa, isolare un agente di intelligenza artificiale voleva dire scegliere fra due strumenti imperfetti: una lista di permessi che è l'agente stesso a far rispettare, oppure un container, che separa la macchina ma non sa dire se un comando è giusto o sbagliato. Il 28 settembre 2026 NVIDIA ha pubblicato sul proprio blog per sviluppatori la Open Agent Safety Platform, e dentro c'è il pezzo che sposta quel limite un piano più in basso.
Cosa ha pubblicato NVIDIA il 28 settembre
OpenShell è un runtime open source con licenza Apache 2.0 che esegue agenti autonomi in ambienti isolati con isolamento a livello di kernel, e la descrizione che il repository dà di sé è una riga sola: "OpenShell is the safe, private runtime for fleets of autonomous AI agents". La differenza tecnica sta in come applica le regole. Secondo la documentazione pubblicata su github.com/NVIDIA/OpenShell, OpenShell strumenta il kernel per applicare la policy a ogni accesso a file, a ogni chiamata di sistema e a ogni connessione di rete mentre l'agente lavora. Le policy coprono file, rete, strumenti, processi e credenziali, e le credenziali vengono iniettate solo verso endpoint approvati.
Il secondo pezzo, quello che richiede hardware
Accanto a OpenShell, l'annuncio di NVIDIA del 28 settembre 2026 comprende NVIDIA Sentry, che porta lo stesso controllo dentro l'hardware BlueField-4 usando NVIDIA DOCA e mette in relazione fra loro le interazioni dell'agente, le decisioni di policy e gli accessi a strumenti e dati. Sentry richiede quell'hardware, OpenShell no. Il runtime open source gira su Linux, su macOS con Apple Silicon e in via sperimentale su Windows con WSL 2, e ha bisogno di Docker, Podman o della virtualizzazione dell'host. Il repository è alla versione 0.1.0 e ha superato le diecimila stelle.
Perché un limite scritto nel prompt non è un limite
Un limite scritto nel prompt è una richiesta, non un vincolo, perché lo applica lo stesso modello a cui si sta chiedendo di rispettarlo. Questa è la parte scomoda, e conviene dirla con un esempio che chiunque può aprire, perché sta in questo repository. La routine che scrive gli articoli di attualità di questo blog, quella descritta in come far girare Claude Code in automatico, tiene le proprie regole in automazione-blog/cloud-agent/prompt-articolo-notizie.md, e una di quelle regole dice "Non tocchi nessun file fuori da content/blog/". Funziona. Ma funziona perché il modello decide di seguirla, non perché qualcosa gliela impedisca.
Il limite che regge sta nell'architettura, non nel testo
Il repository di questo sito contiene anche la scelta opposta, e quella regge da sola. In automazione-blog/README.md è scritto che il cloud agent non entra mai nella VPS via SSH e chiama solo un endpoint HTTP protetto da token, e che la VPS "espone una sola finestrella, niente altro". Quel limite non sta nel prompt, sta nell'architettura: nessuna riga di testo può convincerlo a spostarsi. È la stessa differenza che passa fra chiedere a un agente di non leggere una cartella e fare in modo che quella cartella non esista dal suo punto di vista, ed è il motivo per cui quali permessi dare agli strumenti AI in azienda è una domanda di progettazione e non di prompt.
Dove si mette il limite quando un agente AI esegue comandi
Il limite si può mettere a quattro livelli diversi, e più scende più diventa difficile da aggirare e più costa da configurare. La tabella serve a scegliere, non a ordinare dal peggiore al migliore: i primi due livelli restano utili, semplicemente non sono contenimento.
| Dove sta il limite | Chi lo applica | Cosa non ferma |
|---|---|---|
| Regola nel prompt | il modello stesso | un comando che il modello giudica utile |
| Permessi dello strumento | l'agente, prima di eseguire | quello che parte da un processo figlio |
| Container | il runtime del container | l'uso delle credenziali che il container ha |
| Kernel, con OpenShell | il sistema operativo, a ogni chiamata | quello che la policy consente per iscritto |
La colonna che conta è l'ultima, non la prima. Un agente di coding che ha bisogno di eseguire i test ha bisogno di eseguire processi, quindi il permesso "può lanciare comandi" gli va dato comunque: la domanda utile non è se darglielo, è cosa resta raggiungibile dopo averglielo dato. Su questo ho scritto cosa cambia quando si prova a far lavorare più agenti sullo stesso progetto, dove il problema si moltiplica per il numero di sessioni aperte.
Isolare un agente di intelligenza artificiale: cosa fare oggi
La prova più rapida costa due comandi, e il progetto li documenta così:
Il primo comando merita un commento, perché scaricare uno script e passarlo direttamente alla shell è esattamente il gesto che un runtime di sicurezza dovrebbe scoraggiare. Chi ha un minimo di disciplina lo scarica, lo legge e poi lo esegue: sono trenta secondi in più e sono coerenti con il motivo per cui si sta installando quel programma.
Le tre cose che valgono anche senza installare niente
Tre controlli su un agente che esegue comandi si possono fare oggi, senza installare nessun runtime. Il primo è guardare quali credenziali sono raggiungibili dal processo che ospita l'agente, non quali gli sono state passate: sono due insiemi diversi e il secondo è quasi sempre più piccolo del primo. Il secondo controllo è scrivere la policy prima di scrivere il prompt, perché è l'unica delle due che il modello non può interpretare. Il terzo è decidere in anticipo cosa succede quando la policy nega qualcosa: un agente che si blocca in silenzio a metà di un lavoro è un problema diverso da un agente che chiede il permesso, e va deciso adesso, non la prima volta che capita.
A che livello conviene fermarsi
Per chi sta valutando di portare un agente dentro processi aziendali veri, questo è il punto in cui conviene fermarsi a progettare invece di aggiungere regole al prompt, ed è la prima cosa che guardo quando qualcuno mi chiede un progetto di sviluppo di agenti AI su misura: è la differenza fra un prototipo che gira e una cosa che si può lasciare accesa. Se il tema è il controllo a posteriori invece del contenimento, resta valido quello che ha pubblicato Uber sul sistema con cui controlla i propri agenti, che risolve l'altra metà del problema.
Il livello giusto a cui mettere il limite è il più basso che si riesce a mantenere. Un vincolo nel kernel che nessuno sa configurare è peggio di un permesso ben scelto nello strumento, ma un permesso nello strumento raccontato come se fosse contenimento è la cosa peggiore delle tre, perché produce fiducia senza produrre sicurezza.
Domande frequenti
Quali sono i rischi dell'intelligenza artificiale in azienda?
I rischi cambiano natura quando l'intelligenza artificiale passa dal produrre testo all'eseguire azioni. Un assistente che scrive una bozza sbagliata costa una rilettura, mentre un agente che esegue comandi vale esattamente quanto vale l'accesso più ampio che gli è stato concesso. Il rischio principale in azienda non è che il modello dica una cosa falsa, è che faccia una cosa vera su un sistema di produzione.
Con quali agenti AI si può usare OpenShell?
La documentazione di OpenShell cita il supporto al framework di agenti OpenCode usato con i modelli di OpenRouter, e il progetto si può aggiungere a un agente come skill con il comando npx skills add NVIDIA/OpenShell. Essendo un runtime che applica le regole a livello di sistema operativo e non dentro l'agente, il vincolo non è quale agente si usa ma quale sistema operativo lo ospita.
OpenShell sostituisce i permessi di uno strumento come Claude Code?
No, lavorano a due livelli diversi e servono entrambi. I permessi di uno strumento di coding decidono cosa l'agente prova a fare e quando si fermerà a chiedere, mentre un runtime come OpenShell decide cosa il sistema operativo gli lascia fare a prescindere da quello che l'agente ha deciso. Togliere il primo livello rende l'agente scomodo da usare, togliere il secondo lo rende semplicemente non contenuto.
OpenShell si può usare in un prodotto commerciale?
Sì. La licenza dichiarata nel repository github.com/NVIDIA/OpenShell è Apache 2.0, che permette l'uso commerciale e la modifica del codice, con l'obbligo di mantenere le attribuzioni e di segnalare le modifiche. Resta da valutare a parte la versione: il repository è alla 0.1.0, quindi le interfacce possono ancora cambiare.