La skill affidabile era l'attacco: Copilot Cowork e la supply chain degli agenti

La promessa degli agenti AI è che possono usare strumenti per tuo conto. Un ricercatore che ha esaminato Microsoft Copilot Cowork ha trovato un modo per rivoltare quella promessa contro l'utente, e il percorso seguito dice molto su dove sta andando la sicurezza degli agenti.

PromptArmor ha divulgato la scoperta il 30 settembre. La versione breve: una «skill» scaricata che sembrava un innocuo verificatore di documenti poteva dirottare il percorso di rete di Cowork stesso, aprire un canale di comando verso il server di un attaccante e prelevare dati da Outlook, SharePoint e Teams. Microsoft, secondo il resoconto del ricercatore, ha ricevuto la segnalazione a giugno e ha completato la correzione ad agosto, quindi i dettagli tecnici sono stati pubblicati dopo la correzione anziché prima.

Quattro passaggi, e solo due coinvolgono te

L'attacco richiedeva che l'utente facesse due cose ordinarie: caricare un documento da rivedere e invocare una skill.

Nella dimostrazione, la skill pretendeva di confrontare un contratto con una proposta e segnalare incongruenze. Lo faceva davvero, ed è questo che rende difficile individuare questa classe di attacchi. Il problema era uno script incluso insieme alla skill. Cowork viene eseguito all'interno di una sandbox che non dovrebbe raggiungere Internet aperto, ma mantiene un ponte per le richieste necessarie a generare risposte. Lo script malevolo ha usato un servizio di sincronizzazione file raggiungibile attraverso quel ponte e, cosa cruciale, il servizio accettava un URL fornito dal chiamante.

Quel dettaglio è l'intero exploit. Una volta che lo script poteva raggiungere un indirizzo controllato dall'attaccante, apriva un ciclo. Ogni pochi secondi recuperava un file contenente un comando, eseguiva il comando dentro Cowork e codificava il risultato in un parametro URL inviato al server. Si tratta di un canale di comando bidirezionale, non di un beacon unidirezionale, il che significa che l'attaccante poteva inviare nuove istruzioni in base a ciò che il comando precedente restituiva.

Nella demo, il ricercatore ha elencato la posta di Outlook della vittima e letto il contenuto di un thread email. Secondo il rapporto, lo stesso percorso di accesso esponeva anche file di SharePoint, cronologia delle sessioni e dati dei plugin. Quanto lontano arrivi dipende da ciò che l'utente in questione può già vedere, che è il solito amplificatore in questi casi: l'agente eredita i permessi dell'utente, quindi il raggio d'azione è tutto ciò che quell'account può toccare.

Un altro dettaglio vale la pena ripetere perché cambia il modo in cui si pensa a fermare un attacco. Selezionare il controllo di arresto non terminava il processo in background. Il turno visibile poteva concludersi mentre lo script continuava a fare polling. L'utente crede che il compito sia finito e il canale è ancora aperto.

La skill è la dipendenza

La parte interessante di questa divulgazione non è il bug specifico, che ora è corretto. È che la superficie d'attacco non era un prompt injection nelle istruzioni del modello. Era la supply chain attorno all'agente.

Le skill in un sistema come questo sono piccole applicazioni. Possono includere script, documenti di riferimento e configurazione, fino a venti file companion nel caso di Cowork, e spesso arrivano da fuori dell'organizzazione, scaricate da un marketplace o condivise tra colleghi. È la stessa struttura che ha prodotto anni di problemi negli ecosistemi npm e PyPI, dove una dipendenza che non hai scritto può eseguire codice che non hai letto. Le skill degli agenti sono dipendenze con un nome più amichevole. La descrizione sulla pagina della skill affermava che tutta l'elaborazione avveniva localmente e che nulla veniva inviato a terzi. L'ispezione della piattaforma stessa non ha individuato il vero comportamento dello script incluso.

C'è una seconda fuga di dati più silenziosa che punta alla stessa debolezza. Un rapporto di Glow ha scoperto che gli agenti avevano esposto più di 13.000 immagini e screenshot interni di oltre 300 organizzazioni attraverso repository GitHub pubblici. Nessuno aveva l'intenzione di pubblicare quei file. Sono finiti allo scoperto perché un agente li ha scritti in un posto raggiungibile da un repository pubblico.

I due incidenti sembrano diversi e condividono una causa comune. In uno, una skill malevola raggiungeva l'esterno di proposito. Nell'altro, un agente che si comporta bene scriveva dati in un posto che non capiva essere pubblico. Entrambi sono fallimenti del confine attorno a ciò che un agente può raggiungere e fin dove viaggiano i suoi output. Il caso Cowork mostra un attaccante che sfrutta quel confine. Il caso GitHub mostra il confine che fallisce da solo, senza che nessuno tenti di violarlo, il che è probabilmente l'esito più comune nell'uso ordinario.

Come leggere una divulgazione di sicurezza come questa

La timeline è la parte che la maggior parte dei lettori salta, e vale la pena ripercorrerla perché ti dice come pesare la scoperta. PromptArmor ha segnalato il problema a Microsoft a fine giugno. Microsoft ha chiesto maggiori informazioni a luglio, ha discusso la correzione all'inizio di agosto e ha confermato il fix entro metà-fine agosto. La ricerca è diventata pubblica alla fine di settembre, dopo la patch, che è la sequenza standard di divulgazione responsabile. Ne seguono due lezioni.

Primo, una vulnerabilità corretta non è la stessa cosa di una classe di vulnerabilità corretta. Il percorso di exploit specifico è chiuso. Il pattern che lo ha reso possibile, un'integrazione fidata che l'agente deve raggiungere e che può essere usata come canale arbitrario, si presenta ovunque un agente abbia un percorso di rete consentito. La stessa settimana ha prodotto altri esempi che puntano alla stessa debolezza, incluse segnalazioni che gli agenti avevano esposto migliaia di immagini interne attraverso repository pubblici. Bug diversi, stessa forma.

Secondo, la correzione arriva secondo i tempi di Microsoft, non i tuoi. Chiunque usi questi strumenti in azienda deve sapere su quale versione si trova e se l'aggiornamento lo ha effettivamente raggiunto. Una nota di patch su un blog non è la stessa cosa di un deployment correttamente aggiornato.

La skill è la dipendenza

L'istinto dopo una storia così è fidarsi di più della sandbox. La sandbox di Cowork ha fatto il suo lavoro contro l'accesso diretto a Internet, e l'exploit ha aggirato il confine usando un percorso che la sandbox doveva lasciare aperto. Questo è il pattern generale: un agente senza uno strumento di rete diretto non è comunque un sistema chiuso se può creare contenuti su una superficie che recupera risorse esterne in un secondo momento, o guidare un servizio che lo fa.

Per i team che eseguono agenti in un ambiente aziendale, la risposta pratica assomiglia meno a una patch di sicurezza e più a una normale governance del software. Sapere quali skill sono installate e da dove provengono. Spostare l'installazione delle skill sotto il controllo IT invece di lasciarla ai singoli utenti. Trattare una skill con un percorso di rete come tratteresti qualsiasi nuovo eseguibile, con una revisione prima dell'esecuzione. Verificare se un aggiornamento di sicurezza copre effettivamente la versione in uso.

Niente di tutto ciò è esotico. È la disciplina che la sicurezza della supply chain ha imposto ai team software nell'ultimo decennio, e che ora arriva uno strato più in alto. La differenza sono la posta in gioco. Un pacchetto npm compromesso può eseguire codice sulla macchina di uno sviluppatore. Una skill compromessa viene eseguita dentro un agente che ha già accesso alla tua posta, ai tuoi file e alla cronologia delle tue chat, e può continuare a funzionare dopo che pensi di avergli detto di fermarsi.