Lazarus di Microsoft: backdoor in un agente AI con meno di 10 neuroni

Un agente AI che supera ogni test di sicurezza, lavora senza intoppi per mesi e poi, il giorno in cui il calendario passa al 2027, scarica ed esegue codice scelto da un attaccante. Non è la trama di un film, ma la dimostrazione pubblicata da Microsoft Research con Lazarus, una tecnica che trasforma un modello linguistico in un agente dormiente modificando meno di dieci neuroni.

La ricerca, firmata dal principal researcher Dimitris Papailiopoulos e uscita tra il 10 e l’11 novembre 2026, è tra le più inquietanti dell’anno per chi usa agenti con accesso a terminale e strumenti. Vediamo cosa è stato dimostrato, perché conta e cosa puoi fare fin da subito.

Cos’è Lazarus e come funziona il backdoor

Il titolo del lavoro, «Lazare, veni foras», richiama la resurrezione di Lazzaro, e l’immagine è calzante. La tecnica prende dei neuroni che in un modello quasi non si attivano mai, cioè neuroni dormienti, e li riprogramma modificando direttamente i pesi, senza alcun nuovo addestramento.

Una volta riscritto, il neurone si risveglia solo quando compare un innesco preciso. Per riconoscerlo basta un semplice classificatore lineare addestrato su una cinquantina di esempi, capace di distinguere gli input con il trigger da quelli normali.

Da un token a un comando completo

Un singolo neurone modificato è in grado di forzare un token specifico nell’output del modello. Concatenando più neuroni si ottengono sequenze più lunghe, fino a un vero comando da eseguire in un terminale. È così che, nella dimostrazione, l’agente aspetta il cambio di data oltre la mezzanotte del 2027 e poi scarica ed esegue codice fornito dall’attaccante.

Fino a quel momento il modello si comporta in modo del tutto normale. Supera le valutazioni standard di sicurezza e di qualità, perché nulla, nel suo comportamento quotidiano, lascia intuire la manipolazione.

Questo è il cuore del problema: l’agente non mostra segnali, non rallenta, non produce risposte strane. Si limita ad aspettare, come un programma con una bomba logica incorporata, solo che qui la bomba non è nel codice ma nei numeri che compongono il modello.

Cosa serve all’attaccante

Qui arriva la parte che tranquillizza solo in parte. Per eseguire l’attacco servono potenza di calcolo a livello di inferenza e, soprattutto, accesso in scrittura al checkpoint, cioè al file dei pesi. Non si tratta quindi di un attacco che chiunque può lanciare da remoto contro un modello già in produzione.

Il punto è che l’accesso al checkpoint può arrivare da molte strade: un account compromesso, una pipeline di sviluppo violata, un deposito di storage configurato male. Sono scenari ben noti a chi lavora nella sicurezza della supply chain software, e la ricerca li applica ai modelli.

Un altro messaggio è esplicito: i modelli sviluppati internamente dalle aziende sono vulnerabili quanto quelli open weight pubblici. Come sintetizzano i ricercatori, i pesi andrebbero verificati «come si verifica il codice».

Ne consegue che affidarsi a un modello proprietario, sviluppato in casa o acquistato da un fornitore, non elimina il rischio: sposta soltanto la domanda su chi controlla davvero i file dei pesi e con quali permessi.

Perché la ricerca preoccupa: agenti con permessi reali

Per un chatbot che risponde a domande, un backdoor di questo tipo è un problema limitato. Per un agente che gira senza supervisione per ore, con accesso al terminale, a credenziali e a sistemi privilegiati, diventa un rischio operativo concreto. Un modello innescato potrebbe sottrarre segreti oppure eseguire comandi distruttivi mentre continua a superare ogni controllo.

Il paper tratta infatti un modello compromesso come software compromesso e come potenziale minaccia interna. È un cambio di prospettiva importante: la sicurezza di un agente non dipende solo da cosa gli chiedi, ma da cosa contengono davvero i suoi pesi.

Il dettaglio su Claude Code

Tra i particolari più curiosi c’è quello che riguarda gli strumenti usati nella ricerca: secondo Microsoft, Claude Code con Opus 4.5 ha scoperto in autonomia la maggior parte della tecnica. È un segnale di come gli agenti di coding stiano diventando utili anche nella ricerca offensiva e difensiva sui modelli, un tema che abbiamo visto anche nel bilancio di Project Glasswing sulle CVE sfruttate.

La stessa capacità, naturalmente, cambia anche l’equilibrio tra chi attacca e chi difende.

Si può rilevare? I limiti delle difese attuali

La risposta onesta dei ricercatori è prudente. Una rilevazione affidabile richiede un confronto con i pesi originali non modificati: senza una copia di riferimento, individuare poche modifiche in miliardi di parametri è difficile. Gli agenti più avanzati riescono a segnalare modifiche anomale ai pesi se glielo si chiede espressamente, ma nessuna scansione può dimostrare che un modello sia sicuro.

Per questo l’idea di fondo è trattare gli audit come prove a supporto e non come garanzie assolute, e stratificare più protezioni.

Le misure di Microsoft

Microsoft indica le salvaguardie di Microsoft Foundry: verifica della provenienza dei modelli, collegamento al publisher originale e scansione del software circostante, inclusi i container. Sono in lavorazione scansioni dei pesi basate su AI, strumenti di red teaming per le manomissioni a livello di modello, firme crittografiche per certificare l’integrità e tracce di audit.

Ai marketplace e ai fornitori di modelli la ricerca chiede di controllare i pesi rispetto a un modello base dichiarato, mostrare la provenienza e comunicare i rischi dei checkpoint di terze parti.

Cosa cambia per aziende, sviluppatori e professionisti

Se usi agenti AI nel tuo lavoro, la lezione pratica non è smettere di usarli, ma ridurre la superficie d’attacco. Conoscere l’origine dei modelli che scarichi, preferire fonti ufficiali e verificabili, limitare i permessi degli agenti e monitorarne le azioni sono abitudini che pesano più di qualsiasi scansione a posteriori.

Vale soprattutto per i flussi automatizzati con accesso a terminale o a credenziali. Le azioni più delicate, come cancellare dati, eseguire script scaricati o toccare sistemi di produzione, dovrebbero passare da una revisione umana prima dell’esecuzione.

È la stessa logica che emerge dagli incidenti recenti sugli agenti, come l’operazione Snowball con un agente DeepSeek contro un operatore telecom europeo, e dalle falle nell’infrastruttura che li ospita, come nel caso della vulnerabilità critica di GPUStack inserita nel catalogo CISA.

Una checklist minima

Se gestisci modelli o agenti in azienda, parti da quattro controlli: tracciare da dove arrivano i pesi, confrontarli con la versione dichiarata dal publisher, separare i permessi dell’agente da quelli degli utenti e registrare ogni comando eseguito. Nessuno di questi passaggi da solo basta, ma insieme alzano molto il costo di un attacco come Lazarus.

Per i professionisti e le piccole realtà che usano modelli scaricati da repository pubblici, il consiglio è ancora più semplice: preferisci i canali ufficiali dei publisher, evita checkpoint di provenienza dubbia e non dare mai a un agente più permessi di quanti gliene servano per il compito in corso.

Il quadro più ampio: la fiducia nei modelli come supply chain

Lazarus si inserisce in un filone di ricerche sui cosiddetti sleeper agent, modelli che nascondono comportamenti attivati da un innesco. La novità è la semplicità dell’intervento: poche modifiche mirate, nessun riaddestramento, nessun segno visibile nelle valutazioni abituali.

Il messaggio per il settore è che i pesi di un modello vanno considerati un artefatto critico, come un eseguibile firmato, e che la catena che li produce e li distribuisce merita lo stesso rigore riservato alle librerie software. Finché non esisteranno strumenti maturi di firma e verifica, la prudenza resta la difesa migliore.

Un aspetto da non sottovalutare è la scala. Più agenti autonomi entrano nei processi aziendali, più cresce il valore di un singolo checkpoint compromesso: un solo file manipolato e distribuito su molte installazioni può trasformarsi in un punto di ingresso replicato ovunque.

Per questo la parte più interessante della ricerca non è la trovata tecnica in sé, ma la richiesta implicita al settore: costruire in fretta standard condivisi di provenienza, firma e verifica dei modelli, prima che l’adozione degli agenti superi la capacità di controllarli.

Conclusioni

Lazarus non significa che i tuoi agenti siano già compromessi, né che sia un attacco alla portata di tutti: richiede accesso ai pesi. Dimostra però che un backdoor invisibile nelle valutazioni standard è tecnicamente realistico, e che la sicurezza degli agenti passa dalla provenienza dei modelli, dai permessi concessi e dalla supervisione umana sulle azioni critiche.

Il mio consiglio è di fare oggi un breve inventario degli agenti che usi, dei modelli che li alimentano e dei permessi che hanno. Continua a seguire intelligenzaartificiale.net per gli aggiornamenti sulla sicurezza dell’AI e sulle ricerche che cambiano il modo di usare gli agenti.