Una skill è codice, e il codice ha bisogno di un checkpoint

Una skill è codice, e il codice ha bisogno di un checkpoint

NVIDIA ha reso open source questa settimana uno strumento chiamato SkillSpector. Il suo compito è ristretto e atteso da tempo: analizzare le skill degli agenti AI alla ricerca di problemi di sicurezza prima che un agente le carichi. Il progetto include il rilevamento di 64 pattern di vulnerabilità, un numero su cui vale la pena soffermarsi, perché implica che qualcuno si sia messo a elencare i modi in cui una skill può andare storta.

Accanto a questo, Cloudflare ha pubblicato una skill di audit di sicurezza che esegue audit in più fasi su una base di codice ed emette risultati leggibili dalla macchina, mentre GitHub ha illustrato un classificatore di rilevamento dei segreti sensibile al contesto, che ha aumentato dell'11,5 per cento l'accettazione ponderata dei risultati reali e ridotto dell'86 per cento il tempo mediano di scansione. Tre team diversi, tre angolazioni diverse, stessa conclusione: lo strato in cui gli agenti ricevono le istruzioni è diventato infrastruttura, e l'infrastruttura viene sottoposta ad audit.

Che cos'è davvero una skill

La parola "skill" fa sembrare tutto più morbido di quanto sia. Una skill non è un'impostazione. È un insieme di istruzioni e, molto spesso, di script, modelli e definizioni di strumenti che un agente leggerà e seguirà con i permessi che gli sono stati concessi.

Quest'ultima frase riassume il modello di sicurezza in una sola proposizione. Una skill non ha bisogno di un exploit, perché non sta forzando l'ingresso. Viene invitata a entrare, le vengono consegnate le chiavi e le viene chiesto aiuto. Se le sue istruzioni sono malevole o semplicemente sciatte, l'agente agirà di conseguenza come se fossero la tua stessa intenzione, perché per quanto può capire, lo sono.

È lo stesso problema che i gestori di pacchetti hanno affrontato decenni fa, e fu risolto allo stesso modo: dando per scontato che la catena di fornitura sia ostile e inserendo checkpoint al suo interno. L'ecosistema degli agenti è all'inizio di quel processo, ed è per questo che un progetto come SkillSpector conta molto più di quanto suggerisca il numero di stelle.

Perché 64 pattern è il numero interessante

Un elenco di 64 pattern di vulnerabilità è una tassonomia, e le tassonomie sono il modo in cui un campo matura. Prima di averne una, ogni incidente è una sorpresa. Dopo, gli incidenti diventano istanze di classi note, il che significa che si possono testare, tracciare e infine eliminare per progettazione.

Alcune di quelle classi sono familiari nel software comune: comandi shell non sicuri, input non validati, credenziali scritte in file che non dovrebbero mai contenerle. Altre sono specifiche di questo nuovo strato. Istruzioni che ampliano la portata dell'agente senza dirlo. Prompt che attirano contenuti non affidabili e li trattano come un comando. Descrizioni degli strumenti che travisano ciò che uno strumento fa, così che l'agente lo chiami per il motivo sbagliato. Skill che concatenano altre skill in un percorso che nessuno aveva previsto.

È nell'ultima categoria che sta la difficoltà. Una skill è pericolosa esattamente in proporzione a quanto può raggiungere, e gli agenti moderni possono raggiungere molto: il file system, la rete, altri agenti, gli strumenti registrati da un'altra skill. Il raggio d'azione di una skill cattiva non è la skill. È tutto ciò che l'agente può toccare, un bersaglio mobile che dipende da quali altre skill sono state caricate per prime.

Il problema del contesto avvelenato

La parte scomoda della sicurezza degli agenti è che il confine tra dati e istruzioni non è imposto da nulla. Un modello legge testo. Non sa per natura quali frasi sono fatti da considerare e quali sono ordini da obbedire.

Quindi una skill che recupera una pagina web, legge un issue tracker o riassume un'email sta esponendo l'agente a testo che può contenere istruzioni. Se il modello le segue, non c'è alcun exploit in senso tradizionale. C'è solo un sistema che ha fatto ciò che gli è stato detto da qualcosa di cui non avrebbe dovuto fidarsi.

Per questo la scansione deve avvenire al momento del caricamento e non al momento dell'incidente. Una volta che una skill gira dentro un agente con permessi ampi, la domanda interessante ha già ricevuto una brutta risposta. Il checkpoint deve venire prima, e deve essere automatico, perché la revisione umana di ogni skill di un registro non scala e mai lo farà.

L'audit sta diventando un prodotto

Il rilascio di Cloudflare punta a una seconda tendenza. La sua skill di audit produce risultati leggibili dalla macchina invece di un elenco che qualcuno deve leggere. Quella formulazione fa un lavoro reale. I risultati che un umano deve leggere sono risultati che un umano scorrerà. I risultati che una pipeline può consumare possono diventare ticket, merge bloccati o deployment rifiutati senza che nessuno debba ricordarsi di guardare.

Il lavoro di GitHub sul rilevamento dei segreti rientra nello stesso schema. La fuga di segreti cresce con quanto codice viene prodotto, e la produzione di codice è aumentata molto. La risposta non è stata "assumere più revisori". È stato un classificatore sensibile al contesto che riduce il rumore, così che gli avvisi che le persone vedono davvero siano più probabilmente reali. La precisione, negli strumenti di sicurezza, determina se qualcuno legge ancora gli avvisi dopo il terzo mese.

Entrambe sono la stessa mossa fatta a strati diversi. Invece di chiedere agli umani più vigilanza, si rende il controllo automatico abbastanza buono che l'attenzione umana venga spesa solo dove può contare. È l'unica strategia che sopravvive al contatto con il volume.

La questione di governance sottostante

C'è qui uno strato di policy che si muove più in fretta di quanto la maggior parte dei team realizzi. I sistemi di controllo di versione cominciano a portare metadati di provenienza. I registri dei pacchetti aggiungono attestazione. Gli organismi di standardizzazione lavorano su come etichettare i contenuti sintetici e su come identificare un agente. La direzione è verso un mondo in cui l'origine e l'integrità di un artefatto devono essere dimostrabili, non presunte.

Le skill stanno in quel mondo in modo scomodo, perché la stessa skill può essere utile e pericolosa a seconda del contesto. Una skill che può modificare file è essenziale per un agente di programmazione e catastrofica per un agente che legge anche email non affidabili. La decisione di fiducia non è una proprietà della skill da sola. È una proprietà della skill più l'ambiente più le altre skill che può raggiungere.

Il che suggerisce che gli scanner dovranno alla fine fare più del semplice pattern matching. La versione davvero difficile di questo strumento verifica se una combinazione proposta di skill concede una capacità che nessuno ha chiesto, e avvisa prima del rilascio invece che dopo.

Cosa dovrebbero fare i team adesso, senza reagire troppo

Il panico non è la risposta giusta, e nemmeno trattarlo come un problema di qualcun altro.

Le mosse pratiche non sono glamour. Tratta le skill di terze parti come dipendenze non affidabili, perché è esattamente ciò che sono. Fissa le versioni e rivedi i diff quando cambiano. Esegui gli agenti in ambienti dove il raggio d'azione è limitato, così che una skill cattiva non possa raggiungere la rete o il database di produzione solo perché l'agente era comodo. Registra quali skill si sono caricate e cosa hanno fatto, perché la prima domanda difficile dopo qualsiasi incidente è che cosa è stato autorizzato a girare.

L'industria ha già percorso questa strada. Gli ecosistemi dei pacchetti erano insicuri, poi sono diventati noiosi da attaccare, e la noia è il punto. Le skill degli agenti si stanno dirigendo verso lo stesso equilibrio, e i progetti pubblicati questa settimana sono il primo serio tentativo di costruire il checkpoint. Arrivarci prima dell'incidente costa meno che arrivarci dopo, e l'unica cosa necessaria per arrivarci presto è la disponibilità a essere noiosi al riguardo.