Come progettiamo agenti più sicuri

Per costruire agenti IA più sicuri, dobbiamo progettare tenendo conto sia delle loro capacità che dei loro fallimenti. Anche quando svolgono attività legittime e senza alcuna istruzione malevola, gli agenti possono superare i confini di sicurezza mentre cercano di superare gli ostacoli.

Crediamo che questo sia un problema di ingegneria della sicurezza e l'industria dovrebbe affrontarlo nel modo in cui ha affrontato i worm di Internet dei primi anni 2000. I sistemi che circondano gli agenti devono limitare ciò a cui gli agenti possono accedere, rilevare comportamenti indesiderati e contenere i guasti quando si verificano.

In Perplexity, stiamo collaborando attivamente con ricercatori e professionisti per far progredire l'ingegneria della sicurezza per gli agenti IA e applichiamo più livelli di difesa tra i nostri modelli, gli harness per agenti e l'infrastruttura, in modo che la sicurezza non dipenda da una singola salvaguardia.

Comportamento di meltdown degli agenti IA

A luglio, gli agenti IA sono penetrati nell'infrastruttura di produzione della piattaforma IA open-source Hugging Face. Durante l'esecuzione di valutazioni di cybersecurity interne e di addestramento, i modelli di OpenAI hanno scoperto un modo per sfruttare il gestore di repository Artifactory per stabilire una bacheca per comunicare tra loro, consentendo loro di organizzarsi in sciami. Successivamente, gli agenti che non riuscivano a fare progressi sulle attività in un benchmark di cybersecurity hanno reclutato altri agenti per farsi aiutare. Questi agenti sono evasi dal loro ambiente di valutazione e hanno raggiunto Internet. Hanno anche scoperto modi per barare decodificando le risposte alle attività del benchmark, ma hanno pensato che il sistema di punteggio avrebbe rilevato l'imbroglio. Per comprendere meglio come funzionava la valutazione del benchmark per trovare modi per evitare di essere scoperti a barare, hanno infine compromesso i sistemi di Hugging Face (Hugging Face; OpenAI).

L'incidente è un chiaro esempio di una modalità di errore che abbiamo descritto quando abbiamo reso open-source Numbat a luglio: meltdown accidentali, un termine coniato dai ricercatori di sicurezza di Cornell Tech (arXiv). Un agente che persegue un obiettivo legittimo incontra ostacoli, come un file mancante, una chiamata API fallita, una credenziale scaduta o un rifiuto di autorizzazione, e va in cerca di una soluzione alternativa. Nel farlo, potrebbe superare i confini di sicurezza tramite ricognizione, escalation dei privilegi, scoperta di segreti o esfiltrazione di dati. L'agente stesso diventa effettivamente l'avversario, anche se non è coinvolto alcun prompt malevolo o attaccante esterno.

Hugging Face non è stato un caso isolato. Altri comportamenti di meltdown degli agenti sono stati scoperti e segnalati nelle ultime settimane. Il 27-28 maggio, gli agenti che cercavano di raccogliere dati dell'Università dell'Iowa da Data USA, una piattaforma che offre accesso aperto ai dati del governo degli Stati Uniti, hanno riscontrato errori causati da una query malformata. Hanno risposto con sonde, tra cui SQL injection, cross-site scripting, template injection, path traversal e command injection. L'attività è stata successivamente collegata a OpenAI (SecurityWeek). Il 20-21 giugno, gli agenti di OpenAI che cercavano di ottenere i costi governativi pro capite per una categoria di medicinali in diverse aree locali del Victoria dall'Australian Institute of Health and Welfare (AIHW) sono stati bloccati dal download di un file. In risposta, gli agenti hanno scaricato il file, che era già pubblico, dal server di pre-produzione dell'AIHW, eludendo nel processo le protezioni anti-bot del sito (SecurityWeek).

Il modello non si limita a un solo laboratorio. Durante i test di cybersecurity, i modelli di Anthropic hanno violato tre aziende dopo che un errore ha concesso loro l'accesso aperto a Internet, Gemini di Google ha indovinato le credenziali di tre siti web e un modello di Meta ha sfruttato un servizio di terze parti (Reuters).

Imparare dalla storia: L'era dei worm di Internet

Questi incidenti ricordano l'era dei worm di Internet di circa un quarto di secolo fa. All'inizio degli anni 2000, Internet è cresciuta molto più rapidamente rispetto alle pratiche di sicurezza ad essa associate. Abbiamo assistito a un'ondata di virus e worm, con conseguenze molto più gravi di quelle che stiamo osservando ora con gli agenti IA in stato di meltdown.

Il 4 maggio 2000, le persone hanno iniziato a ricevere email da mittenti familiari con l'oggetto "ILOVEYOU". L'apertura dell'allegato nell'email ha comportato l'esecuzione di uno script che ha inviato una copia di se stesso a tutti i contatti nella rubrica di Outlook della vittima. Entro le ore 18:00 di quel giorno, il CERT Coordination Center aveva ricevuto segnalazioni che coinvolgevano più di 420.000 host Internet (US GAO Report). Secondo quanto riferito, il virus ha penetrato almeno 14 agenzie federali, tra cui il Dipartimento della Difesa, la CIA, la NASA e la Camera e il Senato (US GAO Report). Ha anche bloccato i server di posta elettronica al Pentagono e al Parlamento britannico (Wired). Il gigante assicurativo Lloyd's of London ha fatto una stima iniziale secondo cui il virus sarebbe costato oltre 15 miliardi di dollari in danni e perdita di produttività (US House Committee Hearing). Computer Economics ha successivamente stimato 8,75 miliardi di dollari di danni in tutto il mondo (Information Week).

Sono poi arrivati i worm che non richiedevano alcun clic umano. Il 19 luglio 2001, il worm Code-Red ha infettato più di 359.000 computer in meno di 14 ore (CAIDA). Il 25 gennaio 2003, SQL Slammer è raddoppiato di dimensioni ogni 8,5 secondi e ha infettato oltre il 90% degli host Internet vulnerabili ad esso entro 10 minuti (CAIDA), sfruttando una falla per la quale Microsoft aveva rilasciato una patch sei mesi prima (CNET). Nell'agosto 2003, il worm Blaster e il worm email Sobig sono comparsi a circa una settimana di distanza l'uno dall'altro (Microsoft, F-Secure).

All'epoca, era ragionevole chiedersi se i computer collegati in rete potessero essere resi sicuri. Sei giorni dopo il virus ILOVEYOU, una Sottocommissione della Camera degli Stati Uniti ha tenuto un'udienza in merito. Molti esperti di sicurezza hanno chiesto una legislazione che rendesse le aziende di software responsabili dei danni causati da difetti nei loro prodotti. Washington ha preso una strada diversa. La National Strategy to Secure Cyberspace ha affermato che "la regolamentazione federale non diventerà un mezzo primario per proteggere il cyberspazio". Ha avvertito che mandati ampi potrebbero creare un "approccio al minimo comun denominatore per la cybersecurity" (CISA).

L'industria ha risposto con l'ingegneria. Undici giorni dopo ILOVEYOU, Microsoft ha annunciato un aggiornamento di Outlook che bloccava gli allegati eseguibili. Nel gennaio 2002, l'azienda ha fatto della sicurezza una priorità assoluta (Seattle Times). L'applicazione automatica delle patch, le impostazioni predefinite sicure, i programmi di bug bounty e la divulgazione coordinata sono diventate prassi standard. Nel 2008, Chrome ha iniziato a eseguire i contenuti web in una sandbox che "limit[a] ciò che un attaccante può fare dopo aver sfruttato un bug" (Chromium Blog). La crittografia, un tempo l'eccezione, è diventata la norma. Le tecnologie di sicurezza, tra cui l'autenticazione a più fattori, i firewall, lo zero trust e la gestione delle informazioni e degli eventi di sicurezza (SIEM), sono diventate ampiamente utilizzate. Si prevede che le organizzazioni di tutto il mondo spenderanno circa 240 miliardi di dollari nel 2026 per la sicurezza delle informazioni (Gartner). I worm non sono mai scomparsi del tutto, ma l'era delle epidemie routinarie a livello di Internet è svanita. Allo stesso tempo, Internet, in gran parte libera da regolamentazioni, è diventata un potente motore di innovazione e crescita economica nei due decenni successivi.

Ingegneria della sicurezza per gli agenti IA

I recenti incidenti hanno sollevato interrogativi legittimi sulla governance degli agenti. I meccanismi di sicurezza esistenti sono stati sviluppati per ambienti di calcolo pre-agente caratterizzati da un comportamento software rigidamente circoscritto e in gran parte deterministico. I meccanismi di controllo degli accesso, in particolare, sono progettati principalmente attorno agli utenti umani e spesso concedono loro ampi privilegi che sono, in linea di principio, sufficienti a causare danni significativi.

Questo design si basa su diverse ipotesi: la maggior parte degli utenti agisce in buona fede; gli attori malevoli possono essere dissuasi tramite audit e conseguenze nel mondo reale; e gli umani compiono azioni, corrette o errate, a un ritmo relativamente limitato. L'applicazione di questi meccanismi di sicurezza agli agenti richiede di tenere conto delle differenze tra il comportamento umano e quello dell'agente. Come abbiamo scritto nella nostra risposta alla richiesta di informazioni del NIST sulla sicurezza degli agenti IA, gli agenti IA mettono in discussione queste ipotesi. Possono esercitare privilegi e compiere azioni alla velocità delle macchine, non sono essi stessi dissuasi dalle conseguenze del mondo reale e possono compiere azioni che sono tecnicamente consentite ma che un tipico utente umano compirebbe raramente.

Rispondere a queste domande richiede ingegneria della sicurezza. Conosciamo i principi di sicurezza per la costruzione di sistemi che mantengono i rischi sotto controllo quando i singoli componenti si comportano in modo anomalo. Ma dobbiamo assicurarci che questi principi vengano applicati durante la progettazione degli ambienti per l'addestramento, il test e l'utilizzo degli agenti IA.

Il principio di sicurezza della difesa in profondità

Probabilmente il principio di sicurezza più importante da applicare per proteggere gli agenti IA è la difesa in profondità, che promuove un'architettura di sicurezza stratificata, in cui vengono impiegate misure difensive multiple, varie e ridondanti per proteggere le risorse di sistema. Nessuna singola salvaguardia è perfetta. Le persone possono cadere vittime di attacchi di ingegneria sociale e rivelare le proprie credenziali di accesso, vengono scoperte e sfruttate vulnerabilità software zero-day e il rilevamento delle intrusioni non coglie nuove varianti di attacco. La difesa in profondità accetta questo scenario e accumula diversi livelli di difesa indipendenti. Se un livello difensivo viene aggirato, altri livelli rimangono in posizione per contrastare o rilevare l'intrusione.

L'incidente di Hugging Face mostra perché la difesa in profondità è importante. La retrospettiva di OpenAI riferisce che le salvaguardie automatizzate utilizzate nei suoi sistemi di produzione, inclusi harness, modelli di auto-revisione e classificatori di sicurezza, erano assenti dall'ambiente di valutazione. Se il suo monitoraggio della catena di pensiero attualmente distribuito fosse stato attivo su quelle valutazioni, avrebbe intercettato l'attività iniziale e avvisato il team di sicurezza più di un giorno prima della violazione (OpenAI). I livelli che avrebbero potuto intercettare il problema esistevano. Semplicemente non erano tutti presenti nello stesso momento.

Garantire la sicurezza degli agenti IA richiede di migliorare sia la sicurezza che l'affidabilità dei modelli IA e dei sistemi che li circondano. Il lavoro a livello di modello è importante e sta dando i suoi frutti. I primi LLM venivano facilmente manipolati da istruzioni iniettate, mentre i modelli di oggi sono notevolmente migliori nel riconoscerle e rifiutarle. Gli sviluppatori di modelli addestrano anche i modelli per un comportamento più sicuro e, come descrive la retrospettiva di OpenAI, monitorano le tracce di ragionamento alla ricerca di segni di comportamento problematico. Ma le difese a livello di modello sono solo una parte della soluzione. I sistemi in cui gli agenti vengono addestrati, testati e distribuiti devono anche essere progettati per la sicurezza e il contenimento. La sicurezza a livello di modello riduce la probabilità che un agente si perda d'animo; la sicurezza a livello di sistema limita i danni quando ciò accade.

Espandi

Regole di progettazione per salvaguardie ridondanti

La difesa in profondità richiede salvaguardie ridondanti. Per gli agenti, raccomandiamo di applicarla con tre regole di progettazione:

1. Indipendenza. Ciascun livello dovrebbe fallire per motivi indipendenti. Due controlli che condividono la stessa ipotesi possono essere battuti dallo stesso attacco. I monitor e i punti di applicazione dovrebbero trovarsi al di fuori della portata dell'agente.
2. Applicazione al di sotto dell'agente. Almeno un livello deve essere deterministico: codice convenzionale e verificabile che blocca le azioni proibite indipendentemente da ciò che produce il modello. Una salvaguardia che l'agente può rifiutarsi di invocare o riconfigurare non è una salvaguardia.
3. I segnali possono solo ridurre l'autorità. Il rilevamento dovrebbe attivare risposte che limitano ciò che l'agente può fare, come la messa in pausa, la revoca delle credenziali, il taglio dell'accesso alla rete o la chiusura della sessione. Nessun segnale di rischio dovrebbe mai concedere ulteriore accesso.

Condividiamo questi principi con i nostri partner nell' Open Secure AI Alliance, tra cui NVIDIA, che ha sostenuto che l'harness guida ciò che un agente tenta di fare mentre l'infrastruttura controlla ciò che può fare (NVIDIA).

La difesa in profondità nei prodotti di Perplexity

Perplexity esegue agenti in quattro tipi di ambienti: nel cloud attraverso la nostra piattaforma per agenti Computer, nel browser attraverso Comet, sui dispositivi degli utenti attraverso Portable Computer e sui computer portatili dei dipendenti, dove i nostri ingegneri utilizzano agenti di codifica di terze parti. Ogni ambiente ha i suoi rischi e ciascuno riceve diversi livelli di protezione.

Nel cloud: Computer e SPACE

Ogni attività di Computer viene eseguita in SPACE, la nostra piattaforma sandbox, che tratta l'agente come non attendibile per impostazione predefinita. Ogni attività riceve la propria microVM, le credenziali rimangono al di fuori della sandbox e vengono iniettate solo quando necessario, il traffico in uscita viene controllato all'esterno del guest e gli snapshot ci consentono di ripristinare le modifiche distruttive (Making SPACE). I clienti aziendali possono anche portare le proprie chiavi di crittografia. La revoca di una chiave rende il Dati protetti illeggibili e l'agente non può ignorare tale decisione.

Testiamo anche se questi livelli reggono. In Escaping SPACE: Part I, abbiamo assegnato a nove modelli di frontiera l'accesso root all'interno di una sandbox di SPACE e abbiamo chiesto loro di evadere. Nessuno è uscito dalla VM, ma alcuni hanno trovato modi per aggirare la policy di rete quando era consentito l'accesso parziale alla rete. Abbiamo corretto tali lacune, confermato le correzioni in un nuovo test e divulgato debolezze simili riscontrate in otto delle altre 10 piattaforme sandbox ai rispettivi fornitori.

Nel browser: Comet e BrowseSafe

Comet utilizza una difesa stratificata contro il prompt injection sin dal lancio: i classificatori esaminano i contenuti recuperati, i prompt strutturati li contrassegnano come non attendibili, le azioni sensibili come l'invio di un'email o l'effettuazione di un ordine richiedono la conferma dell'utente e gli utenti vengono avvisati quando qualcosa viene bloccato (Difese contro il prompt injection di Comet). BrowseSafe, il modello di rilevamento open-source dietro il primo livello, supera i modelli di frontiera sul nostro benchmark BrowseSafe-Bench, eppure lo stesso benchmark mostra che nessun rilevatore è infallibile, motivo per cui il rilevamento non è mai l'unico livello (Ricerca BrowseSafe). Computer eredita queste difese, che sono state verificate da Trail of Bits (Perplexity).

Sul dispositivo: Portable Computer

Portable Computer è un agente locale: il modello, l'harness, la conversazione e la traiettoria rimangono sulla macchina dell'utente per impostazione predefinita. Un orchestratore deterministico, che è codice di harness anziché un LLM, esegue il ciclo e applica le policy. Il modello propone azioni e le chiamate di strumenti approvate vengono eseguite in una sandbox a livello di sistema operativo che limita processi, percorsi di file e accesso alla rete. La sandbox è sempre attiva e fail-closed: se non è disponibile, l'harness si disabilita anziché eseguire comandi con le autorizzazioni dell'utente. Le azioni che superano il confine del dispositivo, come la ricerca sul web, i connettori e l'escalation a un modello di consulente cloud più forte, avvengono solo quando l'utente le abilita e le approva. Prima di una chiamata al consulente, un classificatore PII segnala le informazioni sensibili e l'utente vede cosa verrebbe inviato. Il consulente riceve solo quel contesto approvato e restituisce una guida testuale, senza alcun accesso ai file o agli strumenti del dispositivo.

Sull'endpoint: Numbat

Gli agenti di codifica sui computer portatili degli sviluppatori funzionano per ore con accesso al codice sorgente, alle credenziali e ai sistemi di produzione. Numbat, la nostra suite di sicurezza per agenti open-source, aggiunge un livello indipendente che si trova all'esterno di qualsiasi singolo agente. Funziona con harness come Claude Code, Codex, OpenCode e Pi, blocca azioni pericolose prima che vengano eseguite, segnala sequenze multi-passaggio sospette come la lettura di un segreto e il successivo invio di dati all'esterno e conserva le sequenze temporali delle sessioni per le indagini. Numbat viene eseguito su migliaia di endpoint di Perplexity insieme a Bumblebee, il nostro scanner open-source per la supply chain. Computer esamina regolarmente i loro risultati e propone regole di rilevamento migliorate, e un essere umano approva ogni modifica prima che venga rilasciata.

Un lavoro per l'intero settore

Man mano che gli agenti IA diventano più capaci e ampiamente utilizzati, l'ingegneria della sicurezza deve rimanere centrale per il loro sviluppo e la loro distribuzione. Ricercatori e ingegneri possono basarsi su principi consolidati, utilizzare i risultati del mondo reale per perfezionare le difese e testare le salvaguardie negli ambienti in cui operano gli agenti. La sicurezza è una disciplina ingegneristica continua che si sviluppa insieme alla tecnologia.

L'ingegneria della sicurezza per gli agenti è un lavoro per l'intero settore. Nessuna singola azienda controlla l'intero stack su cui viene eseguito un agente. Gli sviluppatori di modelli, i creatori di harness, i fornitori di sandbox e runtime, i vendor di cloud e hardware e i team di sicurezza aziendali possiedono ciascuno un livello. La sicurezza dell'insieme dipende dal fatto che ogni livello regga quando un altro cede. Questo è il motivo per cui costruiamo salvaguardie che funzionano tra i diversi harness per agenti e rendiamo open-source i nostri strumenti. È anche il motivo per cui divulghiamo le debolezze che troviamo in altre piattaforme e prendiamo parte a iniziative come l'Open Secure AI Alliance.

Per lavorare con la community più ampia su queste sfide, a marzo 2026 Perplexity ha lanciato il Secure Intelligence Institute per studiare la sicurezza, l'affidabilità e la difesa pratica dei sistemi IA all'avanguardia (Perplexity). Attualmente Perplexity collabora e/o finanzia ricercatori accademici a Stanford, CMU, Duke, Columbia, Ohio State e all'Università della Virginia. Conduciamo anche ricerche interne per far progredire la frontiera della ricerca sulla sicurezza degli agenti, tradurre tali progressi in miglioramenti concreti nei sistemi di Perplexity e condividere conoscenze e risorse che aiutano a rafforzare l'ecosistema IA più ampio. Agenti più sicuri sono qualcosa che l'industria può progettare. Intendiamo continuare a fare la nostra parte e invitiamo altri a costruire insieme a noi.