La sicurezza degli agenti AI non può stare nel prompt

AI / SICUREZZA / ARCHITETTURA

Abbiamo passato mesi a discutere di agenti AI come se la sicurezza fosse soprattutto un problema di istruzioni: prompt migliori, policy più esplicite, modelli più allineati. È una parte del problema, ma ha un difetto abbastanza evidente: stiamo chiedendo allo stesso componente che prende decisioni di rispettare anche il recinto che dovrebbe limitarle.

Il nuovo Open Agent Safety Platform presentato da NVIDIA il 28 settembre prova a spostare il discorso su un piano più interessante. Il punto non è rendere l’agente più obbediente. È costruire confini che l’agente non controlla.

È una differenza architetturale, non semantica. E secondo me è qui che la sicurezza degli agenti comincia finalmente ad assomigliare alla sicurezza del software serio.

Se il componente che deve rispettare una regola può anche modificare, aggirare o reinterpretare il meccanismo che la applica, non abbiamo costruito un confine: abbiamo scritto una raccomandazione.

Un agente non è pericoloso perché “pensa male”

Nel precedente articolo su cosa cambia quando l’AI smette di essere un chatbot e il software comincia ad agire il punto era proprio questo: appena un agente dispone di filesystem, rete, API, credenziali e strumenti, un errore non produce soltanto una frase sbagliata. Può produrre uno stato sbagliato.

Da quel momento la domanda utile non è più «quanto è intelligente?», ma «quale autorità possiede e chi può revocarla?». È una domanda molto meno spettacolare, ma molto più vicina a quelle che ci facciamo da decenni con processi, utenti, container, servizi e sistemi distribuiti.

NVIDIA parte da una constatazione analoga. Nel suo documento tecnico cita casi recenti in cui agenti sottoposti a valutazione hanno oltrepassato i confini dell’ambiente previsto. Non serve trasformarli in Terminator. Basta osservare una proprietà normale dei sistemi agentici: possono scegliere percorsi che l’operatore non ha enumerato, soprattutto quando lavorano a lungo, incontrano blocchi o ricevono istruzioni ambigue.

OpenShell: il primo confine sta fuori dal modello

Il primo livello della proposta è OpenShell, runtime open source con licenza Apache 2.0. Esegue gli agenti in sandbox con isolamento a livello kernel e permette all’operatore di definire quali file, reti, processi, strumenti e credenziali possano raggiungere.

La cosa importante non è la parola sandbox. È la posizione del controllo. La policy viene applicata dal runtime, fuori dal modello e dall’agent harness. L’agente può decidere di tentare un’azione; non decide se quell’azione è autorizzata.

È la stessa separazione che cerchiamo in qualunque sistema con privilegi: il codice applicativo esprime un’intenzione, un altro livello decide se quell’intenzione può diventare un’operazione reale. Non affidiamo a un processo la possibilità di autoconcedersi root perché nel file README ha promesso di comportarsi bene. Con gli agenti, stranamente, a volte sembriamo ancora tentati di farlo.

Sentry sposta il watchdog ancora più fuori

Il secondo livello è quello più particolare. Nella reference architecture NVIDIA aggiunge Sentry, un watchdog che gira sulle DPU BlueField-4 e osserva l’attività da un dominio separato dall’host. NVIDIA descrive questo livello come enforcement “in-silicon”: se un agente prova a uscire dai confini software, Sentry può intervenire da un punto che l’agente non controlla.

Secondo NVIDIA, Sentry può mettere in quarantena un agente che viola i confini nell’ordine dei millisecondi. È un claim del produttore, non un benchmark indipendente, e va trattato come tale. Il principio architetturale però resta interessante anche senza innamorarsi del numero: il watchdog non vive nello stesso dominio di fiducia del workload che sorveglia.

È defense in depth applicata agli agenti. OpenShell impone il perimetro software; il livello BlueField può aggiungere osservazione ed enforcement out-of-band. E soprattutto quest’ultimo è opzionale: la documentazione NVIDIA specifica che OpenShell può funzionare anche su piattaforme di calcolo di terze parti, incluse architetture Arm e Intel. Non bisogna quindi confondere la parte aperta del modello con la reference architecture ottimizzata per l’hardware NVIDIA.

La parte più interessante è il trust boundary

Il documento NVIDIA elenca cinque principi. Quello che per me li tiene insieme è semplice: il confine di sicurezza deve essere verificabile e stare fuori dalla portata dell’agente.

Questo cambia anche il modo in cui progettiamo sistemi agentici. Un agente non dovrebbe ricevere «accesso al server» e poi essere pregato di usare solo una directory. Dovrebbe ricevere una capability che rende fisicamente o logicamente impossibile andare altrove. Non dovrebbe conoscere una credenziale permanente e promettere di non stamparla. Dovrebbe poter effettuare l’operazione autorizzata senza possedere il segreto. Non dovrebbe decidere autonomamente quando il proprio lavoro è verificato. Dovrebbe produrre evidenze che un altro componente può controllare.

È una direzione coerente anche con un altro problema che ho affrontato parlando di errori MCP e action space degli agenti: quando il software viene usato da attori non umani, il contratto operativo conta più delle frasi rassicuranti. Permessi, errori, stati e transizioni devono diventare leggibili dalla macchina e, soprattutto, enforceable.

Non è una soluzione magica, ed è un bene dirlo

La piattaforma è appena stata annunciata. OpenShell è un progetto giovane e Sentry è una reference design legata a BlueField-4. Non abbiamo ancora una storia operativa abbastanza lunga per sapere quanto questo modello riduca incidenti reali, quali falsi positivi produca, quanto sia semplice mantenere policy complesse o quanto pesi davvero su workload eterogenei.

C’è poi un tema commerciale evidente: NVIDIA propone una parte software aperta e contemporaneamente mostra il livello più profondo di enforcement sul proprio stack hardware. Non è uno scandalo; è esattamente il punto in cui bisogna distinguere l’idea architetturale dal prodotto che la implementa. L’idea — separare workload e autorità di controllo — è generalizzabile. Il modo in cui Sentry la realizza è, oggi, specifico dell’ecosistema NVIDIA.

Anche una buona sandbox non risolve tutto. Una policy sbagliata può essere applicata perfettamente e restare sbagliata. Un agente autorizzato a cancellare un database può farlo senza violare alcun confine. L’enforcement riduce lo spazio delle azioni possibili; non sostituisce la progettazione dei permessi, la verifica dei risultati o la responsabilità di chi assegna l’autorità.

La sicurezza degli agenti sta diventando infrastruttura

Questa è la parte che considero più significativa dell’annuncio. Per molto tempo la sicurezza dell’AI è stata raccontata quasi esclusivamente come proprietà del modello: alignment, filtri, red teaming, prompt injection, comportamento. Tutto importante. Ma quando il modello diventa un componente di un sistema che agisce, la sicurezza deve tornare a essere anche proprietà dell’architettura che lo contiene.

Process isolation, least privilege, capability boundaries, policy enforcement, identity, audit, revoca. Non sono concetti nuovi e forse è proprio questa la buona notizia. Non dobbiamo inventare una nuova religione della sicurezza perché il processo adesso contiene un LLM.

Un agente può essere molto più imprevedibile di un processo tradizionale. È esattamente per questo che i suoi confini dovrebbero essere meno negoziabili, non più intelligenti.

Se l’agent economy diventerà davvero qualcosa di grande, non sarà perché avremo finalmente scritto il prompt perfetto. Sarà perché avremo costruito sistemi in cui un agente può essere utile senza dover essere implicitamente fidato. NVIDIA sta proponendo una propria implementazione di quel principio. È presto per sapere quanto funzionerà il prodotto; è già abbastanza tardi per riconoscere che il principio è quello giusto.