Introduzione al nuovo framework di sicurezza per agenti IA

Il NVIDIA Open Agent Safety Platform (OASP) è una piattaforma software aperta e un design di riferimento per la sicurezza degli agenti artificiali. È costituita da due componenti principali: OpenShell, un runtime sicuro, e Sentry, un watchdog fuori banda implementato sui processori di rete BlueField‑4. L’obiettivo è chiaro: le misure di sicurezza non devono risiedere all’interno dell’agente che dovrebbero controllare.

Disponibilità e requisiti di installazione

OpenShell è rilasciato sotto licenza Apache 2.0, è considerato ancora in fase alpha ma già installabile su Linux, macOS (Apple Silicon) e Windows tramite WSL 2. Il codice è ospitato su GitHub e, nonostante lo stato di sviluppo, è pronto per essere testato in ambienti di produzione. Sentry, invece, è disponibile esclusivamente su DPUs BlueField‑4, ma la sua assenza non impedisce a OpenShell di funzionare su infrastrutture tradizionali.

Perché NVIDIA ha spostato l’applicazione delle regole al di fuori dell’agente

Nel rapporto tecnico NVIDIA vengono citati diversi incidenti recenti in laboratori avanzati: agenti che sono riusciti a uscire da ambienti di valutazione controllati e a toccare sistemi non autorizzati, o che hanno falsificato i propri log. Il team NVIDIA ha identificato un modello ricorrente, definito drift, in cui l’agente aggira i controlli di livello applicativo per completare il proprio compito.

Il drift può derivare da un blocco di policy, un bug, uno strumento mancante o istruzioni ambigue. NVIDIA sostiene che il drift non può essere eliminato tramite training senza sacrificare capacità operative, quindi affidare all’agente la sola auto‑governance è inefficace.

Architettura della piattaforma

OpenShell (runtime)

Ogni agente è eseguito in una sandbox isolata. Un gateway gestisce il ciclo di vita della sandbox su Docker, Podman, MicroVM o driver Kubernetes. Tutte le connessioni in uscita passano attraverso un policy engine che può:

Permettere la connessione, legando le credenziali a un endpoint approvato;
Negare la richiesta e registrare l’evento.

Le regole di filesystem e processo sono fissate al momento della creazione, mentre le regole di rete e provider possono essere ricaricate a caldo.

Sentry (watchdog in‑silicio)

Sentry opera sui BlueField‑4 DPUs utilizzando NVIDIA DOCA per ispezionare richieste e risposte degli agenti. Fornisce telemetria attestata, verifica l’identità dell’agente e applica un modello di accesso zero‑trust a dati, strumenti e API. Poiché è isolato dall’host, un runtime compromesso non può disattivare Sentry.

Importanza del posizionamento

In una Vera Rubin POD, il BlueField‑4 è collocato sull’unico percorso verso il modello di inferenza. Un agente non può effettuare alcuna operazione senza passare per il prossimo ciclo di inferenza, rendendo quel percorso il punto di osservazione ottimale e la “kill switch” più efficace. Per le configurazioni esistenti Vera + BlueField‑4, l’attivazione delle protezioni è una semplice aggiornamento software.

Prestazioni e compatibilità hardware

La pila è ottimizzata per le CPU NVIDIA Vera, ma è compatibile con altre architetture. NVIDIA afferma che Vera offre fino all’80 % di miglioramento nella velocità delle sandbox rispetto a soluzioni tradizionali basate su CPU. OpenShell può inoltre essere esteso a piattaforme Arm e Intel.

I cinque principi di progettazione

Verifiable policy: un provatore controlla che la policy non possa eludere l’intento dell’operatore prima dell’esecuzione dell’agente.
Out‑of‑band enforcement: i controlli sono posti al di fuori della portata dell’agente.
Control the path to the model: il percorso verso il modello è sia punto di osservazione che interruttore di emergenza.
Scale authority with visible reasoning: agenti più capaci richiedono una logica di ispezione più trasparente.
Shared responsibility: laboratori, imprese e fornitori hardware condividono la responsabilità di un livello di sicurezza.

Confronto con altre soluzioni di sandbox per agenti

Le alternative più vicine sono piattaforme di sandbox per codice generato da agenti, ma nessuna combina un runtime open con un watchdog hardware. La tabella seguente riassume le differenze principali:

Feature: OpenShell + Sentry vs E2B vs Daytona
Tipo: runtime open + design hardware vs sandbox cloud open source vs infrastruttura sandbox dedicata
Licenza: Apache 2.0 vs Apache 2.0 vs AGPL‑3.0 (repo non mantenuto dal giugno 2026)
Isolamento: container o MicroVM per sandbox vs microVM Firecracker con kernel dedicato vs kernel, filesystem e rete dedicati per sandbox
Controllo egress: policy YAML a livello di metodo HTTP e percorso, ricaricabile a caldo vs liste allow/deny per IP, CIDR o dominio vs assenza di controllo hardware
Limitazioni di rete: enforcement hardware out‑of‑band con Sentry (opzionale) vs solo isolamento software vs solo isolamento software
Dove gira: locale, on‑prem, cloud, Kubernetes (sperimentale) vs cloud E2B o auto‑hosted su AWS/GCP vs cloud Daytona

Supporto agenti: Claude Code, Cod