Lanciata NVIDIA Open Agent Safety Platform, che sposta le protezioni dell'AI al di fuori del modello

NVIDIA Open Agent Safety Platform è stata lanciata il 28 settembre, ponendo una sfida chiara all'attuale modello di sicurezza dell'industria dell'AI. Invece di confidare che gli agenti rispettino i prompt, NVIDIA punta a far sì che software e hardware esterni all'agente controllino ogni azione.

La piattaforma combina OpenShell, un runtime open source per l'esecuzione isolata degli agenti, con Sentry, un progetto di monitoraggio indipendente basato sulle unità di elaborazione dati NVIDIA BlueField-4. NVIDIA afferma che Sentry può mettere in quarantena un agente in millisecondi quando oltrepassa un confine autorizzato.

Questa distinzione la rende più di un altro framework per agenti. NVIDIA sostiene che l'allineamento dei modelli e le istruzioni a livello applicativo non possano fornire un controllo sufficiente una volta che gli agenti ricevono credenziali, accesso alla rete e il permesso di modificare sistemi reali. L'alternativa proposta ricorda la sicurezza infrastrutturale convenzionale: negare l'accesso per impostazione predefinita, concedere autorizzazioni ristrette, registrare ogni decisione e mantenere l'applicazione delle regole al di fuori del controllo del carico di lavoro.

La domanda immediata non è se OpenShell possa collocare un agente in una sandbox. I sistemi operativi e le piattaforme cloud esistenti offrono già strumenti di isolamento. La questione più difficile è se NVIDIA possa trasformare il contenimento degli agenti in un livello infrastrutturale pratico senza bloccare il lavoro che le imprese desiderano affidare agli agenti.

NVIDIA Open Agent Safety Platform lanciata con due livelli di controllo

NVIDIA ha suddiviso la sicurezza degli agenti in un confine software e una protezione hardware indipendente.

OpenShell fornisce il primo livello. Esegue ogni agente in un ambiente isolato e applica policy che coprono file, processi, destinazioni di rete, credenziali ed endpoint dei modelli. L'agente può ricevere l'accesso necessario per un'attività senza ottenere un controllo illimitato sul sistema host.

NVIDIA descrive OpenShell come un runtime anziché un framework per agenti. Si colloca al di sotto di strumenti quali Claude Code, Codex, GitHub Copilot CLI, OpenCode e sistemi di agenti personalizzati. Gli sviluppatori non devono sostituire il modello di ragionamento dell'agente né il framework applicativo per utilizzare il confine di sicurezza.

Il runtime adotta un approccio di negazione per impostazione predefinita. Quando parte la sua sandbox, un agente non riceve accesso generale alla rete, privilegi elevati o ampie autorizzazioni sul filesystem. Gli amministratori definiscono poi le risorse approvate tramite policy leggibili dalle macchine.

Per esempio, un agente per l'elaborazione delle fatture potrebbe ricevere l'autorizzazione a leggere una cartella specifica e a contattare un'API contabile approvata. Potrebbe restare impossibilitato a eliminare fatture, ispezionare directory non correlate o inviare dati a un sito web non approvato.

OpenShell separa inoltre l'uso delle credenziali dal loro possesso. Il supervisore, che opera al di fuori della sandbox, può fornire le credenziali solo quando una policy autorizza una richiesta specifica. L'agente non necessita di accesso diretto al segreto sottostante.

Il runtime valuta l'attività di rete in base a dettagli quali il binario richiedente, la destinazione, il metodo e il percorso. Può applicare aggiornamenti alle policy mentre un agente continua a operare. Ogni azione consentita o negata diventa parte di una traccia di audit.

L'architettura OpenShell di NVIDIA include anche un verificatore delle policy. Questo componente utilizza la verifica formale, un metodo matematico per controllare se regole specificate soddisfano proprietà definite, prima che gli amministratori applichino modifiche alle policy.

Il verificatore affronta un problema sottile. I team di sicurezza spesso capiscono che un agente necessita dell'accesso a un nuovo servizio, ma non riescono facilmente a vedere ogni capacità creata da una modifica alla policy. Una regola apparentemente ristretta potrebbe aprire un percorso di rete imprevisto o rendere una credenziale raggiungibile.

Sentry fornisce il secondo livello. Opera in un dominio di fiducia isolato sulle DPU BlueField-4, processori specializzati che gestiscono carichi di lavoro infrastrutturali e di sicurezza al di fuori della CPU principale.

Secondo l'annuncio della piattaforma di NVIDIA, Sentry monitora in modo indipendente l'attività degli agenti e può fermare comportamenti sospetti in millisecondi. NVIDIA afferma che il sistema utilizza il proprio software DOCA per ispezionare le richieste, verificare le identità, proteggere l'accesso ai dati e produrre telemetria attestata.

Questa separazione è importante perché un agente non può semplicemente dare istruzioni a Sentry tramite prompt, riscriverne le istruzioni o disabilitarlo dall'interno dell'ambiente di lavoro. Anche un runtime compromesso si trova davanti a un ulteriore punto di applicazione delle regole al di fuori del sistema principale.

OpenShell è ampiamente disponibile, mentre Sentry viene presentato come parte di un progetto di sistema di riferimento legato a BlueField-4. Secondo NVIDIA, il software di OpenShell può essere esteso anche a processori Arm e Intel.

Il risultato è una proposta stratificata, anziché un singolo prodotto di sicurezza. OpenShell limita ciò che un agente può fare durante il normale funzionamento. Sentry osserva dall'esterno di quel confine e interviene quando l'attività sembra sfuggirgli.

Perché la sicurezza degli agenti si sta spostando oltre i prompt

Un agente in grado di agire crea un problema di sicurezza che istruzioni migliori, da sole, non possono risolvere.

I chatbot tradizionali restituiscono testo che una persona può esaminare. Gli agenti autonomi possono leggere file locali, installare pacchetti, chiamare servizi esterni, usare token di autenticazione, modificare codice e continuare a lavorare senza approvazione costante.

Queste capacità rendono gli agenti utili. Ampliano però anche le conseguenze di un presupposto errato, di un input manipolato, di una dipendenza compromessa o di un'istruzione ambigua.

Un prompt può dire a un agente di non condividere informazioni riservate. Quell'istruzione non impedisce fisicamente all'agente di aprire un file sensibile o contattare un server sconosciuto. Le protezioni a livello applicativo restano parte dello stesso ambiente software che l'agente sta esplorando.

Il prompt injection rende questa debolezza particolarmente importante. Un agente potrebbe imbattersi in istruzioni ostili all'interno di un sito web, documento, email, sistema di tracciamento delle issue o repository di codice sorgente. Tali istruzioni possono tentare di reindirizzare l'agente pur apparendo come dati legittimi dell'attività.

Un modello può anche interpretare erroneamente una richiesta valida senza incontrare un aggressore. Un agente di coding incaricato di ripulire un progetto potrebbe rimuovere file necessari. Un agente di ricerca potrebbe inviare informazioni a un servizio non autorizzato perché considera utile quel passaggio.

Justin Boitano, vicepresidente dell'AI enterprise di NVIDIA, ha dichiarato ai giornalisti che gli agenti possono deviare quando le istruzioni sono ambigue o gli strumenti si comportano in modo inatteso. Il suo argomento centrale era che non ci si può aspettare che un agente controlli sé stesso una volta che è in grado di agire.

Questo è il principio alla base dell'annuncio del lancio di NVIDIA Open Agent Safety Platform. Il ragionamento degli agenti resta probabilistico, ma le autorizzazioni infrastrutturali possono essere deterministiche. Un motore di policy può rifiutare una connessione di rete indipendentemente dalla spiegazione del modello per averla richiesta.

Il cambiamento ricorda le precedenti evoluzioni della sicurezza cloud. Le organizzazioni hanno smesso di affidarsi esclusivamente agli sviluppatori applicativi per proteggere ogni database, segreto e percorso di rete. Hanno aggiunto gestione delle identità, isolamento dei carichi di lavoro, motori di policy e monitoraggio al di fuori di ciascuna applicazione.

La sicurezza degli agenti affronta ora una transizione simile. Il modello necessita ancora di addestramento alla sicurezza e l'applicazione necessita ancora di istruzioni sensate. Nessuno dei due livelli dovrebbe ricevere autorità illimitata semplicemente perché ottiene buoni risultati nei test.

La posizione di NVIDIA mette inoltre sotto pressione i fornitori di piattaforme per agenti. I controlli di sicurezza implementati solo all'interno di un framework per agenti diventano meno convincenti quando un runtime esterno può applicare autorizzazioni su più modelli e framework.

Anche i provider cloud subiscono pressione. I clienti che distribuiscono flotte di agenti si aspetteranno sempre più confini di identità, intermediazione delle credenziali, controlli dell'egress e registri di audit progettati per carichi di lavoro autonomi. I container generici non risponderanno a ogni questione di governance.

Le imprese sono il terzo gruppo sotto pressione. Un'azienda non può affermare che un agente agisca secondo il principio del privilegio minimo se non sa spiegare a quali risorse l'agente accede, come cambiano le autorizzazioni e chi può fermarlo.

Questo requisito va oltre gli scenari spettacolari di agenti fuori controllo. I team di conformità necessitano di registri per le operazioni ordinarie, inclusi accesso ai file, chiamate API, modifiche alle policy e uso delle credenziali.

NVIDIA afferma che più di 100 organizzazioni stanno lavorando con le tecnologie della piattaforma. Il gruppo annunciato comprende Anthropic, Cisco, CrowdStrike, Dell Technologies, Hugging Face, JPMorganChase, Microsoft, Palantir, Perplexity, Red Hat, Salesforce, SAP, Scale AI, ServiceNow e altre.

Questo elenco segnala un ampio interesse, ma non dimostra maturità produttiva. “Lavorare con” può comprendere valutazioni, integrazioni, ingegneria congiunta o supporto pianificato. Gli acquirenti necessitano ancora di prove di distribuzione e risultati operativi.

OpenShell 0.1 trasforma il privilegio minimo in un runtime per agenti

Il contributo principale di OpenShell non è un modello più intelligente, ma un livello di controllo riutilizzabile al di sotto di molti modelli diversi.

La linea di rilascio OpenShell 0.1 formalizza questo approccio attraverso una cadenza di rilasci stabile, punti di estensione ampliati, nuove API e meccanismi di isolamento aggiuntivi. Il suo repository open source espone il runtime, il sistema di policy, i kit di sviluppo software e i materiali di distribuzione per l'ispezione.

Ogni agente opera all'interno di una sandbox con un account non privilegiato e capacità ridotte del sistema operativo. I controlli Linux limitano l'accesso al filesystem e le chiamate di sistema, mentre le connessioni in uscita passano attraverso controlli delle policy.

L'architettura separa la sandbox dal suo supervisore. L'agente opera all'interno del confine ristretto del carico di lavoro, mentre il supervisore resta all'esterno e media l'accesso autorizzato. Un gateway gestisce utenti, sandbox, policy, impostazioni e credenziali.

Questa separazione riduce l'autorità detenuta dal processo dell'agente. Se un modello genera un comando shell che richiede un file vietato, l'ambiente operativo blocca l'azione. La sicurezza del modello o la motivazione dichiarata non modificano quel risultato.

Le policy di OpenShell sono dichiarative. Gli amministratori descrivono il comportamento consentito nella configurazione anziché incorporare ogni restrizione nel codice applicativo. Ciò crea una superficie comune di revisione per team di sicurezza, piattaforma e sviluppo.

Le policy coprono diverse aree correlate. Le regole del filesystem distinguono i percorsi leggibili da quelli scrivibili. I controlli sui processi riducono i privilegi e limitano le chiamate di sistema. Le regole di rete valutano destinazioni, porte, binari e dettagli a livello applicativo.

I profili dei provider collegano i servizi approvati alle corrispondenti credenziali e regole di rete. Ciò può mantenere un token API vincolato alla destinazione prevista invece di collocarlo in una variabile d'ambiente generale.

Il runtime supporta anche il routing dell'inferenza. Un'azienda può governare gli endpoint dei modelli utilizzati da un agente mantenendo le credenziali dei provider al di fuori della sandbox. Questo è importante quando i team combinano modelli locali, API cloud e dati soggetti a restrizioni.

L'osservabilità completa il ciclo di controllo di base. OpenShell registra le decisioni e può esportare eventi di sicurezza in un formato strutturato. Gli investigatori possono esaminare ciò che un agente ha richiesto, ciò che il runtime ha consentito e ciò che ha negato.

Queste capacità si adattano particolarmente bene agli agenti di coding. Uno sviluppatore potrebbe consentire a un agente di leggere un repository, creare file all'interno di un branch di lavoro, scaricare pacchetti da registri approvati e contattare un endpoint di modello autorizzato.

La stessa policy può anche bloccare l'accesso a repository non correlati, directory personali, credenziali di produzione e siti web arbitrari. Se l'agente richiede un accesso più ampio, una persona o un sistema affidabile può esaminare la modifica proposta.

Il design supporta anche agenti a lunga esecuzione. Un sandbox tradizionale spesso protegge un unico processo circoscritto per un'attività limitata. OpenShell punta a governare nel tempo attività degli agenti in evoluzione, inclusi aggiornamenti delle policy e flussi di lavoro con sotto-agenti.

Questa ambizione introduce complessità operative. Le policy devono accogliere variazioni legittime senza diventare così ampie da perdere il proprio valore protettivo. I team devono inoltre disporre di processi per esaminare le eccezioni senza bloccare ogni attività.

La verifica formale aiuta a valutare la struttura di una policy proposta. Non può stabilire se l'azienda intendesse autorizzare un'azione pericolosa. La governance umana continua a determinare il confine accettabile.

Lo status open source di OpenShell offre alle organizzazioni un ulteriore vantaggio. I ricercatori di sicurezza possono ispezionare l'implementazione, testare le ipotesi e proporre modifiche. Le aziende possono inoltre estendere il software per diverse piattaforme di calcolo o ambienti di deployment.

L'open source non produce automaticamente software sicuro. Fornisce le condizioni per una revisione indipendente, ma un esame utile richiede manutentori attivi, processi chiari di divulgazione, test riproducibili e correzioni tempestive.

La versione 0.1 comunica inoltre prudenza. Il progetto dispone ora di un'architettura pubblica concreta, ma i primi adottanti dovrebbero aspettarsi cambiamenti nelle API, nelle policy, nelle pratiche di deployment e nelle integrazioni, man mano che i carichi di lavoro reali ne metteranno in luce i limiti.

La sfida principale è tra enforcement e autocontrollo dell'agente

NVIDIA scommette sul fatto che controlli infrastrutturali applicabili supereranno le regole di sicurezza che restano all'interno del ciclo di ragionamento dell'agente.

Non si tratta principalmente di una competizione tra NVIDIA e un altro produttore di chip. È una sfida tra due approcci alla sicurezza: chiedere a un agente di comportarsi in modo sicuro e costruire un ambiente in cui le azioni non sicure falliscano.

I fornitori di modelli continuano a migliorare l'allineamento, il comportamento di rifiuto, la gerarchia delle istruzioni e il monitoraggio. Queste misure possono ridurre la probabilità che un modello scelga un'azione dannosa. Affrontano anche comportamenti che i controlli infrastrutturali non possono riconoscere autonomamente.

OpenShell affronta un livello diverso. Presuppone che un modello prima o poi commetterà un errore, seguirà un contesto manipolato o tenterà un'operazione non autorizzata. Il runtime si concentra sul limitare i danni risultanti.

I due approcci dovrebbero integrarsi, ma le loro priorità differiscono. L'allineamento mira a migliorare le decisioni dell'agente. L'enforcement in fase di esecuzione presuppone che le decisioni restino fallibili e ne limita le conseguenze.

La partecipazione di Anthropic illustra questo approccio combinato. NVIDIA afferma che Claude Managed Agents separa il ciclo dell'agente dai sandbox di esecuzione. OpenShell e BlueField possono aggiungere ulteriori controlli attorno all'accesso tramite tali sandbox.

Questa configurazione crea una difesa in profondità, ossia diversi controlli indipendenti tra l'agente e le risorse sensibili. Un fallimento in un livello non compromette automaticamente tutti gli altri.

La piattaforma supporta anche modelli aperti e chiusi. Questa posizione indipendente dal modello è strategicamente importante per NVIDIA, perché l'azienda fornisce infrastruttura a ecosistemi di IA concorrenti. Un runtime condiviso potrebbe diventare utile indipendentemente dal modello che guida un determinato mercato.

Tuttavia, la portabilità del software e l'indipendenza dall'hardware non sono la stessa cosa. OpenShell può estendersi oltre le CPU NVIDIA, mentre il design completo di Sentry dipende da BlueField-4 per un enforcement isolato, integrato nel silicio.

Questo crea una tensione commerciale all'interno della piattaforma “aperta”. Il livello software può supportare infrastrutture eterogenee, ma la più forte narrativa di contenimento di NVIDIA mette in evidenza l'hardware di rete NVIDIA e il suo stack DOCA.

Concorrenti e fornitori cloud possono rispondere in diversi modi. Possono supportare OpenShell sulle proprie piattaforme, creare sistemi di policy compatibili o promuovere come alternative le funzionalità esistenti di isolamento e confidential computing.

I fornitori di sicurezza possono inoltre collegare l'attività degli agenti ai prodotti consolidati per endpoint, identità, rete e protezione dei dati. La governance degli agenti diventerà probabilmente un ulteriore livello dell'architettura di sicurezza aziendale, anziché un mercato autonomo.

L'evento di lancio della NVIDIA Open Agent Safety Platform amplia quindi il ruolo di NVIDIA. L'azienda non si limita a fornire capacità di calcolo per training e inferenza. Vuole contribuire a definire come i carichi di lavoro autonomi ricevano autorità e come l'infrastruttura la revochi.

Questa posizione conferisce a NVIDIA influenza su un nuovo piano di controllo. Se le policy di OpenShell saranno ampiamente adottate, il runtime potrebbe plasmare le aspettative su identità degli agenti, auditabilità, gestione delle credenziali e accesso alla rete.

L'adozione dipenderà dalla neutralità. Le aziende potrebbero esitare se un livello di sicurezza presentato come universale favorisce fortemente uno stack hardware. Interfacce chiare e un supporto credibile per sistemi non NVIDIA saranno importanti.

Gli sviluppatori valuteranno una questione diversa: l'attrito. Un livello di sicurezza che interrompe costantemente il lavoro utile incoraggerà eccezioni troppo ampie, deployment abbandonati o aggiramenti non ufficiali.

La piattaforma avrà successo solo se autorizzazioni ristrette resteranno pratiche. Ciò richiede strumenti che aiutino i team a individuare gli accessi necessari, spiegare i rifiuti, testare le policy e approvare modifiche senza trasformare ogni attività dell'agente in un ticket di sicurezza.

Cosa la piattaforma di sicurezza NVIDIA ancora non può garantire

Il contenimento può limitare la portata di un agente, ma non può stabilire se ogni azione consentita sia corretta.

Un agente può causare danni pur rimanendo entro le proprie autorizzazioni formali. Un agente finanziario autorizzato a inviare fatture potrebbe approvare un documento fraudolento. Un agente di coding con accesso in scrittura potrebbe introdurre una vulnerabilità sottile in un repository consentito.

OpenShell può registrare queste azioni e limitarne l'ambito. Non può comprendere autonomamente le intenzioni, la logica aziendale o i requisiti etici di ogni organizzazione.

La qualità della policy resta centrale. Se un amministratore concede un accesso ampio al filesystem, uscita di rete senza restrizioni o credenziali riutilizzabili, il runtime applicherà con precisione un confine debole.

Earlence Fernandes, ricercatore dell'University of California, San Diego, ha descritto la piattaforma come un passo nella giusta direzione. Ha anche avvertito che definire l'accesso minimo necessario resta difficile, perché gli agenti utili hanno bisogno di risorse reali.

Somesh Jha, professore di informatica all'University of Wisconsin, ha sollevato una preoccupazione correlata. Ha dichiarato all'Associated Press che gli studi di caso devono mostrare come il sistema bilanci la sicurezza con il lavoro utile bloccato.

I falsi positivi rappresentano un lato di questo equilibrio. Se Sentry mette in quarantena carichi di lavoro legittimi, le organizzazioni potrebbero perdere fiducia nelle operazioni autonome. Hanno bisogno di procedure di recupero affidabili e spiegazioni per ogni intervento.

I falsi negativi rappresentano l'altro lato. Un comportamento sospetto può somigliare a un'attività valida, soprattutto quando un agente usa strumenti approvati per uno scopo non previsto. Una richiesta consentita può comunque divulgare informazioni attraverso il suo contenuto.

NVIDIA afferma che Sentry può intervenire entro millisecondi. La velocità conta dopo il rilevamento, ma l'affermazione pubblica non dimostra l'accuratezza del rilevamento in ambienti diversi.

I benchmark indipendenti dovranno misurare più della latenza di quarantena. I valutatori dovrebbero testare tentativi di evasione, aggiramenti delle policy, uso improprio delle credenziali, trasferimento occulto di dati, dipendenze compromesse e attacchi al piano di controllo stesso.

Anche l'overhead sulle prestazioni richiede misurazioni accurate. NVIDIA descrive come minimo l'overhead di OpenShell sulle CPU Vera. Gli acquirenti hanno bisogno di risultati specifici per i carichi di lavoro, che coprano agenti intensivi in rete, grandi catene di strumenti, frequenti modifiche alle policy e numerosi sandbox simultanei.

La dipendenza dall'hardware del sistema completo presenta un'altra incertezza. BlueField può isolare l'enforcement dal carico di lavoro principale, rafforzando il modello di sicurezza. Aggiunge però requisiti infrastrutturali che gli adottanti di soluzioni solo software non devono affrontare.

La piattaforma non elimina il lavoro sull'allineamento dei modelli. Non può impedire output ingannevoli, ragionamenti scadenti, prove inventate, raccomandazioni distorte o contenuti dannosi quando tali comportamenti avvengono entro canali consentiti.

Non può inoltre risolvere la questione della responsabilità. Le organizzazioni devono comunque decidere chi approva le autorizzazioni, chi esamina i log, chi risponde agli eventi di contenimento e chi si assume la responsabilità delle azioni autorizzate di un agente.

NVIDIA ha collegato il lancio a recenti incidenti che hanno coinvolto agenti oltrepassando i limiti previsti. La copertura iniziale sottolinea correttamente l'importanza di OpenShell e della piattaforma di sicurezza più ampia.

Tuttavia, le affermazioni secondo cui il sistema avrebbe prevenuto una violazione precedente restano valutazioni retrospettive dell'azienda. Test che riproducano gli incidenti ed esercitazioni di red team indipendenti fornirebbero prove più solide.

L'interpretazione più credibile è più circoscritta. NVIDIA ha introdotto una seria risposta a livello di sistemi al rischio degli agenti, ma non ha risolto la sicurezza dell'IA nel suo complesso. La piattaforma può ridurre la superficie d'attacco accessibile quando le organizzazioni la configurano correttamente.

Tre segnali mostreranno se la piattaforma funziona

Le prossime prove dovranno provenire da deployment, test indipendenti e supporto oltre l'infrastruttura di NVIDIA.

Il primo segnale è l'esperienza di produzione pubblicata dalle organizzazioni nominate al lancio. L'elenco dei partner è significativo, ma i clienti hanno bisogno di resoconti dettagliati su policy, azioni bloccate, overhead operativo e risposta agli incidenti.

Uno studio di caso significativo descriverebbe un flusso di lavoro reale dell'agente e le autorizzazioni richieste. Mostrerebbe quali azioni OpenShell ha negato, come gli sviluppatori hanno adeguato le policy e se tali controlli hanno ostacolato il lavoro legittimo.

Le prove provenienti da ambienti regolamentati sarebbero particolarmente utili. Banche, organizzazioni sanitarie, enti governativi e operatori di infrastrutture critiche devono rispettare requisiti rigorosi di controllo degli accessi e auditabilità.

Se queste organizzazioni porteranno OpenShell in produzione, l'argomentazione di NVIDIA acquisterà forza. Se l'attività resterà limitata a dimostrazioni e valutazioni, il lancio apparirà più come una proposta architetturale.

Il secondo segnale è la convalida indipendente della sicurezza. I ricercatori devono avere accesso a deployment rappresentativi, modelli di minaccia, indicazioni di configurazione e test riproducibili.

I test dovrebbero esaminare il sandbox, il supervisore, il gateway, il policy prover, il broker delle credenziali e il confine di Sentry. Gli aggressori prenderanno di mira le interazioni tra i componenti, non solo quello che NVIDIA considera più robusto.

I ricercatori dovrebbero inoltre esaminare i fallimenti di usabilità. Un sistema di sicurezza tecnicamente corretto può diventare inefficace quando gli amministratori copiano esempi permissivi, fraintendono le impostazioni predefinite o disattivano i controlli dopo ripetuti rifiuti.

La documentazione pubblica di NVIDIA offre già agli sviluppatori materiale da esaminare. Il prossimo passo è una revisione esterna continuativa, una gestione trasparente delle vulnerabilità e correzioni visibili quando i ricercatori individuano difetti.

Il terzo segnale è una portabilità credibile. Il software di OpenShell può estendersi alle piattaforme Arm e Intel, ma le affermazioni più forti su Sentry restano collegate a BlueField-4.

Integrazioni funzionanti tra sistemi cloud, ibridi, on-premises e air-gapped sosterrebbero l'affermazione di NVIDIA secondo cui si tratta di un livello aperto di sicurezza per agenti. Una concentrazione ristretta sull'hardware NVIDIA indebolirebbe tale posizionamento.

Il supporto da parte dei fornitori di sistemi operativi potrebbe essere utile. Canonical, Red Hat e SUSE figurano tra le organizzazioni che NVIDIA identifica come integrate nelle tecnologie della piattaforma in infrastrutture comunemente distribuite.

Gli sviluppatori dovrebbero inoltre monitorare la cadenza delle release di OpenShell. Compatibilità con le policy, API stabili, indicazioni per la migrazione e miglioramenti nell’osservabilità determineranno se la versione 0.1 evolverà in un’infrastruttura affidabile.

L’annuncio del lancio di NVIDIA Open Agent Safety Platform definisce uno standard utile per il dibattito. La sicurezza degli agenti dovrebbe includere controlli che un agente non possa riscrivere, aggirare tramite persuasione o ignorare.

Questo standard non richiede a ogni azienda di adottare l’intero progetto di NVIDIA. Richiede però agli acquirenti di porre domande più rigorose su accesso, isolamento, credenziali, auditing e contenimento d’emergenza.

I team che valutano agenti autonomi possono iniziare mappando ogni risorsa a cui un agente può accedere. Dovrebbero individuare quali controlli dipendono dalla collaborazione del modello e quali restano applicabili anche quando il modello si comporta in modo inatteso.

Possono inoltre mantenere una base di conoscenza ingegneristica per policy, azioni negate, decisioni sulle eccezioni e risultati degli incidenti. Questa documentazione aiuta le regole di sicurezza a evolvere sulla base di evidenze anziché supposizioni.

Il test pratico è semplice: un’organizzazione può consentire a un agente di svolgere un lavoro utile senza concedergli un’autorità che vada ben oltre quel compito? OpenShell e Sentry offrono la risposta di NVIDIA. Le evidenze in produzione determineranno se tale risposta reggerà.