Il punto interessante della nuova NVIDIA Open Agent Safety Platform non è l’ennesimo prodotto “AI security”. È il cambio di principio: quando un agente può leggere file, usare credenziali, chiamare API ed eseguire comandi, non basta chiedergli di comportarsi bene. I controlli devono vivere fuori dal modello e, nei casi più sensibili, perfino fuori dall’host che lo esegue.
AGENT SECURITY / TRUST BOUNDARY
Un agente utile ha bisogno di potere. Un agente sicuro non dovrebbe possederlo senza limiti.
Filesystem, rete, API, secret e tool trasformano l’AI da “motore di risposta” a workload operativo. OpenShell prova a creare il recinto software; Sentry aggiunge un secondo piano di controllo out-of-band su BlueField-4.
FILES
API
SECRETS
SHELL
MCP / TOOLS
La notizia, in breve
Il 28 settembre 2026 NVIDIA ha annunciato Open Agent Safety Platform, un’architettura composta da software open source e da un reference design hardware. I due nomi da ricordare sono OpenShell e Sentry.
- OpenShell è un runtime open source per eseguire agenti in sandbox con policy su filesystem, rete, processi, inference e credenziali.
- Sentry è un reference system design che usa BlueField-4 DPU come watchdog out-of-band, con l’obiettivo di monitorare ed eventualmente mettere in quarantena un agente da un dominio separato dall’host.
NVIDIA dichiara che Sentry può fermare un agente che esce dai limiti assegnati nell’ordine dei millisecondi e che OpenShell può essere esteso anche a piattaforme compute di terze parti. Il punto, quindi, non è “serve hardware NVIDIA per mettere in sicurezza un agente”: OpenShell e Sentry sono due livelli distinti.
La lettura MarFedLab: stiamo applicando agli agenti AI un concetto che in infrastruttura conosciamo bene da anni: il workload non deve essere anche il custode dei propri limiti.
Da chatbot a workload operativo: quando cambia davvero il rischio?
Il rischio cresce soprattutto con l’autonomia e con il numero di risorse che l’agente può raggiungere. Non tutti i sistemi AI hanno lo stesso profilo operativo. Prova a spostarti lungo lo spettro:
INTERACTIVE / AUTONOMY
Quanto potere stai realmente dando all’AI?
Clicca sui quattro modelli. Più autonomia significa più capacità, ma anche più superfici che devono essere governate.
Copilotcontesto + suggerimenti
Agenttool + API + identity
Autonomous Agentgoal + planning + retry
Filesystem, shell, browser, API, tool e accesso a dati fanno salire il blast radius.
Più l’agente agisce senza conferma umana, più servono policy runtime, identità separate e telemetria.
Un chatbot tradizionale può certamente produrre una risposta sbagliata o gestire male un dato. Un agente, invece, può trasformare la decisione in azione reale. Può modificare codice, invocare una API, installare un pacchetto, interrogare una base dati o usare una credenziale. È questo passaggio che rende i guardrail puramente applicativi insufficienti come unico livello di sicurezza.
“Non farlo” non è una security policy
Dire nel system prompt “non leggere file sensibili” non equivale a impedire al processo di leggerli. È la stessa differenza che c’è tra scrivere un cartello “accesso vietato” e applicare davvero un ACL.
OpenShell porta il controllo sotto il livello conversazionale. La documentazione NVIDIA descrive un modello di defense in depth basato su filesystem isolation, network policy, process restriction, inference routing e credential mediation. Per il filesystem viene usato Landlock; per le syscall entra in gioco seccomp; l’egress può essere consentito solo verso destinazioni dichiarate.
EXPLORE / OPENSHELL
Apri i quattro layer di controllo
Non sono “consigli” dati al modello: sono confini applicati al workload.
Mettiamo alla prova la sandbox
La maniera più semplice per capire il modello è simulare richieste diverse. Il laboratorio qui sotto è concettuale: non sta eseguendo OpenShell realmente, ma replica il flusso logico descritto nella documentazione. Clicca un’azione e guarda dove viene permessa o bloccata.
SIMULATOR / POLICY ENFORCEMENT
Prova a far uscire l’agente dal recinto
Ogni azione attraversa Agent → Runtime → Policy → Resource.
Il percorso verrà evidenziato passo per passo.
Questo è il pezzo che trovo più interessante: un prompt injection può anche riuscire a convincere il modello, ma convincere il modello non equivale automaticamente a convincere il kernel o il policy engine. Se il file non è leggibile e la destinazione non è raggiungibile, il blast radius si riduce anche in presenza di una decisione sbagliata.
Default deny sulla rete: l’agente non dovrebbe avere Internet “perché sì”
Nella policy di fallback documentata da NVIDIA non sono definite destinazioni di rete: l’egress viene quindi negato finché non viene esplicitamente autorizzato. Le regole possono associare endpoint e binario, e per traffico REST possono arrivare a distinguere metodi e path.
È un dettaglio importante. Una regola del tipo “puoi raggiungere GitHub” è molto diversa da una regola del tipo “curl può fare richieste read-only verso specifici path di api.github.com”. È la traduzione in ambito agentico del principio del minimo privilegio.
Le credenziali: accesso al servizio senza consegnare il segreto
Uno degli errori più rischiosi è mettere API key, token o credenziali persistenti direttamente nell’ambiente dell’agente. Se il processo può leggere il secret, una prompt injection o un tool malevolo può potenzialmente farlo uscire.
OpenShell utilizza provider e binding delle credenziali per separare l’accesso logico dal possesso del valore reale. La documentazione corrente descrive placeholder opachi e risoluzione delle credenziali solo verso endpoint autorizzati.
ANIMATION / CREDENTIAL BOUNDARY
L’agente usa l’API. Ma non deve necessariamente vedere la chiave.
Avvia il flusso per vedere dove entra la credenziale.
Il vantaggio concettuale è enorme: dare a un agente la capacità di usare un servizio non deve equivalere a dargli il secret del servizio. È lo stesso motivo per cui in cloud preferiamo workload identity e token temporanei rispetto a chiavi statiche sparse nei file di configurazione.
Fin qui siamo nel software. Ma cosa succede se non mi fido più dell’host?
Ed è qui che entra Sentry. NVIDIA lo descrive come un watchdog out-of-band eseguito su BlueField-4 DPU. Il punto non è soltanto accelerare rete o storage: è creare un trust domain separato dall’host dove vive l’agente.
Secondo il reference design, Sentry usa DOCA per osservare richieste e risposte, raccogliere telemetria attestata, verificare identità e applicare policy zero-trust su dati, tool, API e servizi. NVIDIA parla esplicitamente di enforcement “in silicon” e di quarantena dell’agente se supera i limiti stabiliti.
SIMULATOR / OUT-OF-BAND
Software boundary o trust domain separato?
Il test assume volutamente un host già compromesso. Serve a mostrare il valore del secondo piano di controllo, non a sostenere che OpenShell venga normalmente bypassato.
Cos’è una DPU, detta in modo semplice?
Per chi viene dal mondo vSphere, network e security, penserei alla DPU come a un computer infrastrutturale dentro il server, con risorse e software propri, capace di gestire funzioni che non vogliamo lasciare completamente al sistema operativo principale. BlueField è la famiglia DPU NVIDIA; DOCA è il framework software che espone le capacità programmabili della piattaforma.
Nel modello Sentry questa separazione diventa una proprietà di sicurezza: il watchdog può stare in un dominio che il workload non controlla. Il concetto ricorda altre trust boundary che usiamo da anni: hypervisor vs guest, HSM vs applicazione, management plane separato vs workload plane.
Il concetto più importante: enforcement indipendente
NVIDIA insiste su un’idea che, al di là del vendor, trovo corretta: i controlli più importanti devono vivere dove l’agente non può semplicemente modificarli o persuaderli.
È un principio molto diverso dal solo “alignment” del modello. L’agente può essere addestrato bene e avere ottime istruzioni; ma quando opera in un ambiente enterprise, sicurezza e compliance richiedono anche meccanismi verificabili e indipendenti.
INTERACTIVE / AGENT DRIFT
Non serve un hacker per uscire dal percorso previsto
Seleziona una causa. Il rischio può nascere anche da obiettivi ambigui, retry o workaround autonomi.
Il percorso si accenderà per visualizzare come una deviazione diventa un’azione.
Agent drift: la sicurezza deve funzionare anche senza un attaccante
Questo è un passaggio che spesso si perde nei discorsi sull’AI security. Non dobbiamo proteggere gli agenti soltanto da prompt injection o supply-chain attack. Un sistema autonomo può deviare dal comportamento atteso anche semplicemente perché il task è ambiguo, il tool necessario non è disponibile o una lunga sequenza di retry produce un workaround non previsto.
Più il task è lungo e autonomo, più il sistema compie azioni intermedie. E ogni azione è un punto dove identità, dati e tool devono restare entro il perimetro autorizzato.
Il rapporto con AIDR: vedere e impedire non sono la stessa cosa
Nell’Insight precedente abbiamo parlato di AIDR/ADR: la necessità di correlare prompt, identità, tool call ed execution telemetry per capire perché un agente abbia fatto una determinata cosa.
OpenShell e Sentry guardano lo stesso problema da una prospettiva diversa: enforcement. In altre parole:
- AIDR / XDR / SIEM aiutano a vedere, correlare, rilevare e ricostruire;
- runtime policy limita ciò che il workload può fare;
- out-of-band enforcement aggiunge un livello di controllo indipendente dall’host;
- identity e least privilege riducono a monte i privilegi utilizzabili dall’agente.
Non sono alternative. Sono pezzi dello stesso control loop.
REFERENCE MODEL / MARFEDLAB
Il controllo di un agente enterprise, a strati
Identità distinta, owner chiaro, token temporanei, privilegi minimi.
Filesystem, process e network policy indipendenti dalle istruzioni del modello.
Secret mediati o workload identity, non chiavi persistenti consegnate all’agente.
Prompt, sessione, tool, identity ed endpoint telemetry da correlare.
Possibilità reale di revocare token, bloccare tool, egress o intera sessione.
Ricostruire chi ha chiesto cosa, quale agente ha deciso e quale azione ha prodotto.
Cosa controllerei in un’azienda prima ancora di comprare un prodotto
La parte interessante di questa architettura è che suggerisce domande utili anche a chi non utilizzerà OpenShell o BlueField. Se oggi in azienda esistono coding agent, agenti MCP o automazioni AI con accesso operativo, inizierei da qui:
- Quali agenti esistono realmente? Non solo quelli ufficiali: anche tool installati dai team di sviluppo o dagli utenti.
- Con quale identità lavorano? Account utente, API key statica, service principal, workload identity?
- Quali path possono leggere? Il repository è una cosa; home directory, SSH key e credenziali cloud sono un’altra.
- Dove possono uscire in rete? Egress libero verso Internet o allowlist di servizi e API?
- Quali azioni richiedono approvazione umana? Lettura, modifica, delete, deploy e rotazione credenziali non hanno lo stesso impatto.
- Posso fermarlo senza chiedere collaborazione all’agente? Revoca token, blocco sessione, network containment, process kill.
- Posso ricostruire la catena causale? Utente → prompt → agent → tool → identity → action → resource.
OpenShell non è “solo per NVIDIA”
OpenShell è open source e NVIDIA dichiara che può essere esteso anche verso piattaforme compute di terze parti. La documentazione mostra un’architettura con gateway, sandbox e supervisor e supporta diversi modelli di runtime. Tra gli agenti documentati compaiono Claude Code, OpenCode, Codex, GitHub Copilot CLI e altri, con livelli di policy coverage differenti.
Questo dettaglio è importante perché separa il concetto dal marketing hardware: si può adottare il modello sandbox/policy senza adottare necessariamente Sentry. Sentry è il livello aggiuntivo per scenari in cui si vuole spostare il trust boundary fuori dall’host.
Perché l’ecosistema intorno è interessante
NVIDIA afferma che oltre cento organizzazioni stanno lavorando con le tecnologie della piattaforma. Tra gli esempi citati nell’annuncio ci sono Salesforce/Slack per visibility e approvazioni, SAP con Joule Studio, Anthropic con Claude Managed Agents e diversi vendor infrastrutturali e di sicurezza.
Non prenderei questa lista come prova che il modello diventerà uno standard. Ma è un segnale: il problema della governance runtime degli agenti non è più confinato ai team che addestrano i modelli. Sta entrando nel dominio di IAM, endpoint, network, cloud, SOC e infrastructure engineering.
Il concetto Zero Trust cambia leggermente
Con utenti e device siamo abituati al motto never trust, always verify. Con gli agenti aggiungerei un secondo principio:
Never trust. Continuously constrain.
Perché sapere chi è l’agente non basta. Dobbiamo verificare continuamente cosa può fare, dove può andare, quali dati può leggere, quale tool può utilizzare e se è ancora dentro il perimetro previsto.
Ed è qui che, secondo me, Open Agent Safety Platform racconta qualcosa di più ampio del prodotto NVIDIA: la sicurezza degli agenti sta iniziando a somigliare sempre meno a “prompt engineering” e sempre più a infrastructure security.
Conclusione
Abbiamo passato anni a lavorare sulla sicurezza dell’AI soprattutto attraverso training, alignment, filtri e guardrail. Tutto necessario. Ma un agente autonomo non è soltanto un modello: è un workload che usa risorse reali.
Quando il workload può leggere file, chiamare API, usare credenziali e prendere decisioni, la domanda non può essere soltanto “il modello è sicuro?”.
Diventa:
“Quali confini tecnici restano validi anche quando l’agente sbaglia, viene manipolato o il sistema che lo ospita non è più affidabile?”
OpenShell prova a rispondere con una sandbox e policy runtime. Sentry sposta il concetto ancora più in basso, verso un trust domain hardware separato.
È presto per sapere se questa architettura diventerà uno standard. Ma la direzione mi sembra chiara: gli agenti AI stanno diventando infrastruttura, e come ogni infrastruttura dovranno essere isolati, autorizzati, osservati e contenuti senza doverci fidare del loro comportamento.