L'architettura di riferimento NVIDIA OpenShell porta l'applicazione delle regole per gli agenti nell'infrastruttura

NVIDIA ha lanciato la propria architettura di riferimento NVIDIA OpenShell il 21 ottobre, spostando le autorizzazioni degli agenti oltre il controllo del software che esegue il lavoro. Annunciato al GTC Berlin, il progetto collega l'elaborazione dei modelli, l'esecuzione degli agenti e l'applicazione indipendente delle misure di sicurezza. La sua proposta centrale è pratica: un agente dovrebbe continuare a operare in autonomia senza acquisire l'autorità di riscrivere le proprie restrizioni.

Ciò crea una decisione d'acquisto diversa dalla scelta di un modello più capace. Le aziende devono decidere dove risiedono le autorizzazioni, quale infrastruttura le applica e chi può fermare un agente dopo che qualcosa è andato storto. La tensione è tra un'autonomia utile e restrizioni sufficientemente precise da impedire azioni non autorizzate senza bloccare il lavoro legittimo.

Claude Code di Anthropic offre un confronto utile perché limita anch'esso gli agenti attraverso il loro ambiente operativo. NVIDIA estende questa discussione all'infrastruttura aziendale e all'applicazione hardware opzionale. Sviluppatori, team di sicurezza e fornitori di software aziendale si trovano ora davanti a una domanda comune: come può un'organizzazione trasformare le proprie regole aziendali in confini che restino efficaci durante l'esecuzione?

L'architettura di riferimento NVIDIA OpenShell collega esecuzione e applicazione delle regole

L'annuncio propone il contenimento degli agenti come responsabilità dell'infrastruttura, con componenti separati per eseguire il lavoro e governarlo.

Un'architettura di riferimento è un progetto di sistema documentato che organizzazioni e partner possono utilizzare per realizzare distribuzioni. Non significa che ogni integrazione nominata arrivi come prodotto finito con capacità identiche. Questa distinzione conta quando si valuta un annuncio che comprende processori, sistemi operativi, fornitori di sicurezza e applicazioni aziendali.

Secondo l'architettura di riferimento OpenShell di NVIDIA, l'infrastruttura Vera Rubin esegue i modelli, mentre le CPU Vera gestiscono gli harness degli agenti, il software che coordina chiamate ai modelli e strumenti. Le data processing unit BlueField-4, processori specializzati per l'infrastruttura, eseguono il software di sicurezza Sentry per il monitoraggio e l'applicazione indipendenti delle regole.

La divisione riflette problemi operativi distinti. Generare un piano richiede capacità di calcolo. Eseguirlo richiede accesso a file, servizi e strumenti. Autorizzare tali azioni richiede regole che l'agente esecutore non possa modificare semplicemente perché una restrizione interferisce con il suo incarico.

L'annuncio estende inoltre il progetto verso distribuzioni locali e edge, ovvero sistemi che operano più vicino agli utenti o alle apparecchiature. NVIDIA cita RTX Spark, DGX Spark e DGX Station. Gli acquirenti dovrebbero valutare tali ambienti singolarmente anziché presumere che una workstation locale offra ogni protezione descritta per una distribuzione infrastrutturale più ampia.

Il cambiamento importante è il rapporto proposto tra questi elementi. Invece di trattare la sicurezza come una funzionalità applicativa aggiunta dopo lo sviluppo, l'architettura colloca l'applicazione delle regole sotto l'applicazione. La richiesta di un agente diventa qualcosa che l'infrastruttura valuta, anziché qualcosa accettato perché l'agente ha generato una spiegazione plausibile.

Si consideri un'attività ingegneristica esemplificativa: un agente indaga su un servizio non funzionante e propone una riparazione. Leggere file diagnostici, installare una dipendenza, modificare la configurazione e distribuire la correzione rappresentano autorizzazioni diverse. Una singola istruzione di riparare il servizio non stabilisce che ogni possibile passaggio sia autorizzato.

Questo esempio spiega perché l'architettura è rilevante oltre gli specialisti della sicurezza. I team di prodotto che promettono esecuzione autonoma devono anche spiegare i confini di tale esecuzione. Altrimenti, i clienti ricevono una descrizione delle capacità senza una corrispondente descrizione del controllo.

Anche la disponibilità richiede un'interpretazione attenta. NVIDIA afferma che l'architettura di riferimento è disponibile, ma ciò non stabilisce la prontezza per la produzione per ogni combinazione di partner. Un progetto documentato, una distribuzione supportata e un'installazione cliente convalidata rispondono a domande diverse.

Per i lettori che valutano il lancio, la prima domanda è quindi specifica: quali parti della catena proposta di esecuzione e applicazione delle regole esistono nella configurazione offerta? La risposta determina se un acquirente sta valutando controlli software, protezione hardware aggiuntiva o una roadmap che combina entrambi.

I team aziendali ereditano il problema delle autorizzazioni

Portare l'applicazione delle regole nell'infrastruttura offre alle aziende maggiore controllo, rendendo però più difficile lasciare implicite le decisioni sulle policy.

La pressione immediata ricade sui team responsabili della traduzione dell'autorità aziendale in autorizzazioni tecniche. I team di sicurezza possono definire risorse limitate, ma i responsabili aziendali devono spiegare quali azioni appartengono a un'attività. I team infrastrutturali devono quindi rendere tali decisioni applicabili attraverso i sistemi che un agente utilizza.

Un'istruzione come “prepara il rinnovo del cliente” contiene una notevole ambiguità. Potrebbe giustificare la lettura della cronologia dell'account e la stesura di una proposta. Non giustifica automaticamente la modifica delle condizioni contrattuali, l'esportazione dei dati dei clienti o l'invio della proposta senza revisione.

Si tratta di distinzioni esemplificative, non di risultati riportati relativi a distribuzioni OpenShell. Mostrano perché la sicurezza degli agenti richiede più dell'identificazione del modello o della verifica che un dipendente abbia avviato la richiesta. L'autorità dipende dall'azione, dal suo obiettivo e dalle circostanze.

I controlli di runtime degli agenti di NVIDIA dividono la responsabilità tra un gateway, un supervisore, una sandbox e un verificatore delle policy. Il gateway gestisce le policy e i cicli di vita delle sandbox. Il supervisore controlla le richieste e media le credenziali al di fuori della sandbox, un ambiente di esecuzione isolato. Il verificatore delle policy controlla le autorizzazioni rispetto a un limite definito dall'organizzazione.

Questa separazione fornisce luoghi in cui applicare le regole, ma le organizzazioni devono comunque decidere cosa tali luoghi dovrebbero consentire. Un limite verificato formalmente può confermare una relazione tra policy. Non può decidere autonomamente se un reparto aziendale abbia inizialmente concesso un accesso eccessivo.

Ciò modifica la discussione tra sviluppatori di applicazioni e revisori della sicurezza. Invece di chiedere se un agente sia affidabile in generale, i revisori possono esaminare cosa può leggere, modificare, invocare o trasmettere. Queste domande producono risposte più concrete, anche se richiedono una preparazione più dettagliata.

Gli sviluppatori affrontano un vincolo di progettazione correlato. Un flusso di lavoro che riesce solo quando riceve autorizzazioni ampie è più difficile da approvare rispetto a uno con requisiti espliciti e limitati. Le interfacce degli strumenti e le descrizioni delle attività diventano parte della progettazione della sicurezza perché determinano con quale precisione l'autorità può essere espressa.

Per i knowledge worker, la distinzione inizia con l'accesso alle informazioni. Una base di conoscenza ricercabile aiuta a stabilire dove risieda il materiale utile. Un agente che compie azioni introduce un'altra decisione: se trovare informazioni conceda anche l'autorizzazione a condividerle o a modificare il sistema che le contiene.

L'onere organizzativo è continuo. I dipendenti cambiano ruolo, i progetti terminano, le credenziali scadono e le applicazioni acquisiscono nuove funzioni. L'autorità di un agente deve riflettere tali cambiamenti anziché conservare qualunque accesso abbia reso efficace la sua prima dimostrazione.

Per questo motivo la governance non può terminare con un documento di approvazione. Le aziende hanno bisogno di un collegamento tra la persona che autorizza il lavoro, la policy che rappresenta tale autorità e l'infrastruttura che la applica. Senza questo collegamento, regole applicate in modo indipendente possono comunque preservare una decisione obsoleta o eccessivamente ampia.

Il lancio esercita quindi pressione sui fornitori di software tanto quanto sugli acquirenti di infrastrutture. I fornitori devono esporre dettagli sufficienti sulle azioni degli agenti affinché i clienti possano governarle. Un sistema che presenta ogni operazione come una richiesta indistinguibile lascia ai clienti una scelta grossolana tra accesso ampio e interruzione.

L'isolamento hardware cambia il punto in cui regge il confine

La proposta hardware di NVIDIA aggiunge un punto indipendente per l'applicazione delle regole; il suo valore dipende dal fatto che le azioni rilevanti passino effettivamente attraverso quel punto.

Una restrizione software ha un ambito definito. La sua protezione dipende dai componenti che la applicano e dalle ipotesi su cui tali componenti si basano. L'aggiunta di un livello hardware di sicurezza separato modifica alcune di queste ipotesi collocando i controlli al di fuori dell'ambiente di esecuzione dell'agente.

NVIDIA descrive Sentry come protezione aggiuntiva opzionale accanto ai confini software di OpenShell. Questa distinzione evita un fraintendimento comune: utilizzare OpenShell non significa automaticamente che una distribuzione includa l'applicazione delle regole tramite BlueField-4. Gli acquirenti devono identificare la configurazione effettiva prima di confrontare le dichiarazioni sulla sicurezza.

Nel progetto di sicurezza runtime Sentry di NVIDIA, BlueField-4 occupa il percorso di comunicazione del nodo verso modelli e sistemi esterni. Sentry combina l'ispezione del traffico con analisi selezionate della memoria host. NVIDIA afferma che può mettere in quarantena gli agenti in pochi millisecondi senza richiedere la cooperazione dell'agente o del software host.

La logica architetturale è semplice. Un controllo è più utile contro un carico di lavoro compromesso quando tale carico non può disabilitarlo. Ma l'indipendenza da sola non stabilisce una copertura completa. Il punto di applicazione deve anche vedere l'azione in valutazione e mantenere l'autorità di bloccarla.

Ciò crea domande concrete per le revisioni delle distribuzioni. La configurazione instrada ogni connessione esterna rilevante attraverso il percorso controllato? Quali azioni locali ricevono restrizioni separate? Cosa accade quando uno strumento esegue lavoro su un altro servizio dopo aver ricevuto una richiesta autorizzata?

Queste domande derivano dal progetto anziché documentare guasti rilevati. Sono importanti perché il flusso di lavoro di un agente può attraversare diversi confini amministrativi. Bloccare la sua connessione successiva non può necessariamente annullare un'azione già accettata da un'altra applicazione.

Il traffico crittografato introduce un'ulteriore decisione di configurazione. NVIDIA descrive l'ispezione delle connessioni configurate per essere decrittografate ed esaminate. Le aziende devono quindi comprendere dove si applichi l'ispezione, quali informazioni diventino visibili e come tale visibilità si concili con i loro requisiti di riservatezza.

Il confronto con Anthropic aiuta a chiarire la scelta progettuale. Il sandboxing di Claude Code di Anthropic utilizza meccanismi del sistema operativo per limitare l'accesso al filesystem e alla rete. Il suo approccio dichiarato offre agli agenti libertà entro confini predefiniti, controllando al contempo l'accesso oltre tali confini.

Entrambi gli approcci pongono restrizioni al di fuori delle istruzioni generate dal modello. La differenza non è una semplice sfida tra software senza restrizioni e hardware sicuro. Gli acquirenti confrontano modalità di applicazione, requisiti di distribuzione e ipotesi di fallimento.

L'esempio di Anthropic riguarda un ambiente di esecuzione per sviluppatori. L'annuncio di NVIDIA collega l'esecuzione degli agenti a un progetto infrastrutturale più ampio, con un livello hardware indipendente opzionale. Nessuna delle due descrizioni, da sola, stabilisce quale configurazione sia più adatta a uno specifico carico di lavoro aziendale.

Per un'organizzazione che esegue attività di sviluppo con un ambito ristretto, i controlli esistenti dell'ambiente meritano una valutazione autonoma. Per implementazioni sensibili che richiedono maggiore indipendenza dal software host, l'approccio hardware di NVIDIA offre un'opzione diversa. La decisione dovrebbe seguire la minaccia da affrontare.

Il compromesso fondamentale è una separazione più forte a fronte di una maggiore complessità di distribuzione. Un ulteriore livello di applicazione crea un altro punto in cui fermare attività non sicure. Crea però anche un altro componente le cui policy, visibilità, aggiornamenti e responsabilità operative devono rimanere coerenti con il resto del sistema.

Gli annunci dei partner rivelano diversi livelli di maturità

I dettagli più utili dei partner distinguono le funzionalità disponibili oggi dalle integrazioni ancora pianificate.

ServiceNow fornisce un esempio concreto dell'ingresso di questa architettura nella conversazione sui prodotti aziendali. Il suo annuncio sulla governance degli agenti aziendali afferma che Arc, un agente personale progettato per attività di lunga durata, è generalmente disponibile. ServiceNow descrive l'applicazione di OpenShell come parte dell'esecuzione governata di Arc.

Lo stesso annuncio colloca l'integrazione di AI Passport con OpenShell e l'applicazione tramite BlueField in una versione futura. AI Passport è un record di autorizzazione pensato per comunicare i permessi di un agente. Il suo stato pianificato è rilevante perché il lancio attuale di un'applicazione non dimostra la disponibilità dell'intera catena di governance proposta.

Questa distinzione offre agli acquirenti un modo utile per leggere gli altri materiali di lancio. La disponibilità espressa al presente va valutata separatamente dall'integrazione prevista, dalla collaborazione con i partner e dalle funzionalità future. Riunirle in un'unica impressione di maturità nasconde il lavoro ancora necessario.

L'esempio di ServiceNow rende tangibile anche il problema aziendale. Un agente persistente sul posto di lavoro deve operare tra incarichi e permessi in continua evoluzione. La governance deve restare rilevante dopo la richiesta iniziale, specialmente quando un'attività continua oltre l'attenzione immediata dell'utente.

Un caso esemplificativo è quello di un dipendente che incarica un agente di coordinare il passaggio di consegne di un progetto. Leggere documenti di progetto, individuare il lavoro incompiuto, redigere messaggi e modificare diritti di accesso richiedono autorità diverse. Un sistema utile deve preservare tale distinzione man mano che l'attività evolve.

I partner della sicurezza introducono un ulteriore livello di differenziazione. F5 descrive l'ispezione del traffico AI che integra i permessi in fase di esecuzione con l'esame di prompt, risposte e chiamate agli strumenti supportati. Il suo annuncio distingue inoltre una topologia di distribuzione proposta, soggetta a convalida del prodotto.

Si tratta di una precisazione importante, non di una nota marginale. Un partner può sostenere la direzione dell'architettura mentre una configurazione specifica richiede ancora convalida. I clienti dovrebbero chiedere quale implementazione sia stata testata, con quali funzioni di ispezione abilitate e rispetto a quale carico di lavoro.

La descrizione di F5 separa inoltre l'autorizzazione dalla valutazione dei contenuti. Una richiesta può indirizzarsi a un servizio approvato pur contenendo informazioni sensibili o istruzioni malevole. Il permesso di connettersi e il giudizio sul contenuto trasmesso affrontano rischi diversi.

Questo aiuta a spiegare perché il lancio includa partner della sicurezza anziché presentare l'applicazione infrastrutturale come sostituto di ogni difesa esistente. Il confine proposto necessita di input su identità, autorizzazione e attività sospette. Richiede inoltre una risposta operativa dopo che qualcosa è stato bloccato.

La questione commerciale è se questi livelli diventino più facili da gestire insieme. Gli acquirenti dovrebbero cercare policy coerenti e registri degli incidenti comprensibili. Aggiungere console separate senza una relazione chiara tra le decisioni lascerebbe agli investigatori il compito di ricostruire quanto accaduto tra sistemi scollegati.

L'ampiezza della rete di partner segnala interesse, ma i dettagli di distribuzione hanno più peso. Un cliente può valutare una configurazione supportata, una limitazione documentata o un'integrazione rilasciata. Il nome di un'azienda in un elenco di lancio fornisce meno prove su ciò che quel cliente può gestire in sicurezza oggi.

I confini sicuri dipendono ancora da regole corrette

La NVIDIA OpenShell Reference Architecture non elimina la distinzione tra un'azione autorizzata e una buona decisione.

Un agente può rimanere entro i propri permessi e produrre comunque un risultato errato. Può interpretare male un documento, scegliere il record sbagliato o formulare una raccomandazione inadeguata. Il contenimento infrastrutturale affronta l'ambito dell'azione; non stabilisce la correttezza di ogni conclusione.

Questa distinzione dovrebbe guidare il modo in cui le organizzazioni interpretano la parola “sicuro”. La sicurezza è un risultato ampio, mentre l'applicazione in fase di esecuzione fornisce controlli specifici. Una valutazione significativa identifica il fallimento che si intende prevenire e le ipotesi alle quali la prevenzione è valida.

Immaginate un agente autorizzato ad aggiornare un sistema di pianificazione. Una restrizione potrebbe impedirgli con successo di accedere ai dati delle buste paga. Lo stesso agente potrebbe comunque fissare l'appuntamento sbagliato all'interno dell'applicazione consentita. Entrambi gli esiti contano, ma richiedono misure di protezione diverse.

Permessi eccessivamente ampi creano un'altra limitazione. Una regola applicata perfettamente che consenta a un agente di esportare un intero set di dati non protegge quel set dall'esportazione autorizzata. La qualità della decisione aziendale resta centrale anche quando l'applicazione funziona esattamente come progettato.

Permessi eccessivamente ristretti creano il problema opposto. Se il lavoro ordinario si interrompe ripetutamente, gli utenti hanno un incentivo a richiedere accessi più ampi. I team di sicurezza hanno quindi bisogno di prove su quali blocchi prevengano danni e quali riflettano policy mal adattate alle attività legittime.

Si tratta di una preoccupazione analitica, non di una conclusione secondo cui OpenShell provochi interruzioni non necessarie. Identifica la misurazione necessaria per valutare il compromesso dell'autonomia. Il contenimento efficace dovrebbe essere considerato insieme al completamento utile delle attività, alla frequenza degli interventi e alle conseguenze delle operazioni negate.

Anche la tempistica del rilevamento necessita di contesto. Un'affermazione di quarantena rapida descrive la risposta dopo il rilevamento di una condizione rilevante. Gli acquirenti devono comunque comprendere quali eventi attivino il rilevamento e se un sistema esterno abbia già agito prima che inizi il contenimento.

Le descrizioni dei fornitori disponibili non stabiliscono una garanzia universale verificata in modo indipendente per tutti i flussi di lavoro aziendali. Illustrano meccanismi previsti e punti di integrazione. Le conclusioni sulla sicurezza in produzione richiedono prove legate alla configurazione implementata, inclusi i suoi permessi e le protezioni abilitate.

Esiste inoltre una dimensione di privacy legata all'osservabilità ampliata. L'esame delle comunicazioni e del contesto di esecuzione può migliorare le indagini, esponendo al contempo materiale sensibile a componenti di sicurezza aggiuntivi. Le organizzazioni necessitano di decisioni chiare sull'ambito dell'ispezione, sull'accesso ai record e sulla conservazione.

La responsabilità operativa merita uguale attenzione. Qualcuno deve mantenere le policy, indagare sui dinieghi, approvare eccezioni e ripristinare un agente dopo il contenimento. Se tali responsabilità restano poco chiare, un confine tecnicamente efficace può comunque produrre lunghe interruzioni o soluzioni alternative non sicure.

L'approccio di NVIDIA rende queste domande più concrete perché identifica i punti in cui le regole possono essere applicate in modo indipendente. Si tratta di un progresso utile nella progettazione dei sistemi. Non elimina la necessità di valutare le regole stesse o il flusso di lavoro che circonda una decisione di sicurezza.

Lo standard appropriato è quindi un'affermazione circoscritta: controlli specifici impediscono determinate azioni non autorizzate in condizioni definite. Gli acquirenti dovrebbero evitare di trasformare tale affermazione in una promessa generale che un agente non possa causare danni.

Osservare integrazioni rilasciate, evidenze di sicurezza e adeguatezza operativa

I prossimi segnali significativi saranno capacità rilasciate, convalida riproducibile ed evidenze che le organizzazioni possano mantenere i controlli risultanti.

Nei prossimi mesi, il primo segnale sarà la distribuzione delle integrazioni descritte come lavoro futuro. L'applicazione pianificata di AI Passport da parte di ServiceNow fornisce un esempio specifico. Una versione con supporto e limitazioni documentati renderebbe più facile valutare il collegamento proposto tra autorità aziendale e applicazione infrastrutturale.

Ciò rafforzerebbe la tesi secondo cui le aziende possono trasferire una decisione di governance attraverso i livelli di esecuzione. Un linguaggio che continui a riferirsi alla roadmap lascerebbe quella parte della proposta meno consolidata. Gli acquirenti dovrebbero distinguere la disponibilità del prodotto da dimostrazioni o annunci di collaborazione.

Il secondo segnale è la convalida della sicurezza collegata a una distribuzione completa. Evidenze utili descriverebbero il carico di lavoro, la configurazione delle policy, l'ispezione abilitata, l'azione non autorizzata tentata e il risultato osservato. Dovrebbero anche spiegare quale lavoro legittimo sia rimasto possibile.

Una dimostrazione che mostra un agente bloccato stabilisce meno di una descrizione riproducibile del motivo del blocco. Quest'ultima aiuta i clienti a determinare se lo stesso controllo si applichi alle loro applicazioni. Espone inoltre ipotesi che una presentazione può lasciare implicite.

La convalida dovrebbe includere flussi di lavoro consentiti oltre agli attacchi. Un confine che blocca attività non autorizzate consentendo al contempo il lavoro previsto sostiene il compromesso centrale dell'architettura. Una dipendenza ripetuta da eccezioni ampie indebolirebbe l'affermazione secondo cui le aziende possano combinare autonomia e controllo preciso.

Il terzo segnale è l'adeguatezza operativa negli ambienti aziendali reali. Le organizzazioni devono sapere se le policy restino coerenti al variare di applicazioni, identità e strumenti. Hanno inoltre bisogno di record degli incidenti che spieghino la relazione tra l'azione richiesta e la decisione di applicazione.

Evidenze di aggiornamenti delle policy gestibili e di indagini comprensibili rafforzerebbero il caso di distribuzione. Evidenze di regole incoerenti o responsabilità poco chiare identificherebbero un diverso collo di bottiglia. In tale situazione, una maggiore capacità di applicazione non risolverebbe da sola il problema di governance.

Le distribuzioni locali e edge meritano particolare attenzione in questa valutazione operativa. I lettori dovrebbero cercare capacità documentate del sistema specifico da distribuire. Una famiglia di prodotti o un'etichetta architetturale condivisa non risponde a ogni domanda sulla copertura dell'applicazione.

Per gli sviluppatori, la conseguenza pratica è una richiesta di requisiti di autorizzazione più chiari. Per gli acquirenti aziendali, è una richiesta di prove specifiche per configurazione. Per i knowledge worker, è una distinzione tra concedere a un agente l'accesso alle informazioni e delegargli l'autorità di agire.

Prima di approvare un deployment, identificate l'esatto workflow che volete affidare a un agente e le azioni che devono restare fuori dalla sua autorità. Chiedete al fornitore di mostrare entrambi gli esiti nella configurazione proposta: la prosecuzione del lavoro legittimo e l'interruzione di un'azione non autorizzata. Esaminate poi chi gestisce la policy, come entrano in vigore le modifiche agli accessi e cosa gli investigatori possono ricostruire in seguito. Tenete separate le capacità attuali dalle integrazioni promesse, soprattutto quando i rilasci software e hardware seguono tempistiche diverse. La NVIDIA OpenShell Reference Architecture offre un progetto infrastrutturale concreto da analizzare. Usatela per esigere una risposta precisa a una domanda pratica: quali decisioni restano sotto il controllo della vostra organizzazione mentre l'agente opera in autonomia?