GhostJacking mette in luce le lacune nella governance delle identità degli agenti AI

Google News ha portato alla luce GhostJacking dopo che i ricercatori hanno mostrato come un singolo report di errore avvelenato possa indirizzare un agente AI autorizzato verso codice controllato da un attaccante. L'attacco riesce nonostante le difese perimetrali perché l'agente esegue ogni passaggio tramite strumenti legittimi e autorizzazioni di sviluppo.

Questa distinzione cambia il dibattito sulla sicurezza. Le credenziali dell'agente non sono necessariamente rubate e il suo software non è necessariamente compromesso. Al contrario, dati operativi non attendibili modificano l'intento dell'agente mentre la sua identità autenticata resta valida.

La ricerca alla base definisce la tecnica più ampia “Agentjacking”, mentre l'etichetta GhostJacking sottolinea la natura quasi invisibile della presa di controllo. Un agente continua a operare con la propria identità abituale, lasciando ai difensori il compito di distinguere l'automazione legittima dall'intento ostile.

Non si tratta semplicemente dell'ennesima storia di prompt injection. Mette in luce una collisione tra modelli linguistici, telemetria attendibile, integrazioni Model Context Protocol e sistemi di identità progettati per utenti prevedibili.

Il conflitto centrale è chiaro. Le aziende vogliono che gli agenti indaghino sugli incidenti ed eseguano riparazioni senza supervisione costante. Tuttavia, le autorizzazioni che rendono utili questi agenti rendono pericolose sul piano operativo anche decisioni manipolate.

Il report GhostJacking trasforma una coda di bug in un percorso di attacco

GhostJacking trasforma informazioni di cui un agente dovrebbe fidarsi in istruzioni che potrebbe eseguire.

L'attacco descritto nel report GhostJacking inizia con un falso errore software. Un attaccante inserisce testo appositamente costruito nella telemetria che un agente di coding recupera in seguito durante l'indagine su problemi irrisolti.

Per telemetria si intendono i log, gli errori, le tracce e i record diagnostici generati dal software. I team di sviluppo trattano solitamente questo materiale come prova del comportamento del sistema, non come un canale di comando attivo.

Questa ipotesi viene meno quando un modello linguistico legge il materiale. Il modello riceve fatti diagnostici, commenti, formattazione e potenziali istruzioni nello stesso flusso di testo.

Threat Labs di Tenet Security ha dimostrato questo schema usando Sentry, una piattaforma di monitoraggio degli errori che accetta eventi applicativi. Sentry utilizza un Data Source Name, o DSN, affinché le applicazioni possano inviare tali eventi al progetto corretto.

Un'applicazione browser spesso necessita di quel DSN nel codice lato client. Possederlo può quindi consentire a qualcuno di inviare un evento senza prima compromettere la rete interna dell'organizzazione.

L'evento dell'attaccante contiene una descrizione dell'errore convincente e apparenti indicazioni per la correzione. Quando un agente recupera l'evento tramite un'integrazione, le istruzioni malevole arrivano insieme ai dati diagnostici legittimi.

Il modello si trova quindi davanti a un problema di classificazione. Deve decidere se il testo descriva un errore, riporti le parole di una parte esterna o istruisca l'agente a eseguire un'azione correttiva.

Secondo la ricerca controllata, gli agenti testati a volte hanno interpretato il materiale inserito come passaggi validi per la risoluzione. Hanno quindi eseguito un pacchetto controllato dai ricercatori con i privilegi locali dello sviluppatore.

Tenet afferma che il suo pacchetto di convalida era progettato per test controllati, non per attività dannose. L'azienda afferma inoltre che le informazioni raccolte sono state oscurate e gestite secondo il proprio processo di divulgazione.

La conseguenza per la sicurezza va comunque oltre il pacchetto benigno. Un comando ostile eseguito con un account sviluppatore potrebbe raggiungere variabili d'ambiente, repository di codice sorgente, credenziali cloud o strumenti di sviluppo autenticati.

Tenet ha riferito di aver identificato 2.388 organizzazioni con credenziali Sentry potenzialmente iniettabili. Ha inoltre riferito di aver osservato oltre 100 agenti agire su errori iniettati durante test controllati.

Queste cifre provengono dal fornitore di sicurezza e non sono state riprodotte in modo indipendente sull'intera popolazione segnalata. Dovrebbero misurare l'esposizione osservata nello studio, non compromissioni confermate da criminali.

Il cambiamento importante è architetturale. Un tempo i log erano prove passive per le persone e per software deterministici. I flussi di lavoro agentici possono trasformare gli stessi log in contesto eseguibile.

Questo crea un insolito ciclo di feedback. Un controllo di sicurezza blocca traffico sospetto, registra la richiesta bloccata e memorizza il testo dell'attaccante in una piattaforma di monitoraggio attendibile.

In seguito, un agente AI legge il record memorizzato per diagnosticare l'incidente. Il blocco riuscito diventa quindi il percorso di consegna per la fase successiva.

Perché l'attenzione di Google News conta oltre una singola dimostrazione di sicurezza

La visibilità su Google News conta perché GhostJacking collega un rischio AI astratto a un normale flusso di lavoro di sviluppo.

L'iniezione indiretta di prompt è documentata da anni. Si verifica quando istruzioni malevole sono incorporate nei dati che un sistema AI elabora mentre completa un'altra attività.

L'attaccante non deve inserire istruzioni direttamente nel prompt dell'utente. Il payload può comparire in una pagina web, un'email, un documento, un ticket di assistenza, un commento al codice o un record di database recuperato.

GhostJacking applica questa debolezza nota alle prove operative. L'obiettivo non è un chatbot che risponde a una domanda innocua. È un agente incaricato di diagnosticare software e potenzialmente eseguire comandi correttivi.

Questa differenza alza la posta in gioco. Un chatbot potrebbe generare una risposta fuorviante, mentre un agente di coding dotato di poteri può modificare file, invocare una shell o accedere a servizi autenticati.

L'evento arriva inoltre durante la rapida adozione di agenti connessi agli strumenti. Model Context Protocol, comunemente chiamato MCP, offre ai modelli un modo standard per comunicare con strumenti esterni e fonti di dati.

MCP può ridurre il lavoro necessario per collegare un agente a sistemi di tracciamento dei problemi, database, repository, piattaforme di monitoraggio e strumenti locali degli sviluppatori. Non rende automaticamente attendibili i contenuti provenienti da tali sistemi.

Uno strumento può essere autentico pur restituendo dati controllati da un attaccante. Questa distinzione è centrale nell'attacco GhostJacking.

La sicurezza applicativa tradizionale spesso chiede se un chiamante possa accedere a una risorsa. Qui, l'agente autenticato è autorizzato ad accedere alla risorsa e a eseguire l'azione risultante.

La domanda mancante è se l'azione rifletta l'intento dell'utente. L'autenticazione risponde a chi sta agendo, ma non dimostra perché sia stata scelta l'azione.

NIST descrive il dirottamento degli agenti come una forma di prompt injection indiretta causata da una debole separazione tra istruzioni attendibili e dati esterni non attendibili. Le sue valutazioni sul dirottamento includevano scenari di esecuzione remota di codice, esfiltrazione di dati e phishing automatizzato.

I ricercatori di NIST hanno rilevato che gli attacchi adattivi contavano molto. In una valutazione, l'attacco di base più efficace ha raggiunto un tasso di successo dell'11% contro un modello aggiornato.

Un attacco sviluppato di recente ha raggiunto l'81% nella stessa configurazione di test riportata. Il risultato non fornisce un tasso universale di fallimento dei modelli, ma mette in discussione le affermazioni statiche sulla resistenza alla prompt injection.

Un modello può ottenere buoni risultati contro una suite di test nota e fallire comunque contro un attacco adattato al suo comportamento. I team di sicurezza non possono quindi considerare un benchmark come una garanzia duratura.

La copertura di Google News può contribuire a portare questa conclusione fuori dai circoli specializzati nella sicurezza dell'AI. Il flusso di lavoro interessato assomiglia a ciò che i team di sviluppo già desiderano che gli agenti facciano: esaminare un problema, individuarne la causa e applicare una correzione.

L'articolo non mette quindi in guardia da una superintelligenza ipotetica. Riguarda uno strumento di automazione familiare che opera con credenziali familiari contro servizi cloud familiari.

È proprio questa familiarità a rendere facile sottovalutare il rischio. Ogni componente può apparire legittimo se esaminato separatamente.

Il servizio Sentry è legittimo. L'integrazione MCP è legittima. L'agente di coding è legittimo e l'account dello sviluppatore è autenticato.

L'elemento ostile esiste nel passaggio tra dati e intento. Gli attuali controlli di identità raramente esaminano quel passaggio.

La governance delle identità degli agenti AI si ferma all'autenticazione

La governance delle identità degli agenti AI fallisce quando verifica l'attore ma non può verificare l'autorità alla base di ogni decisione.

I sistemi di identità umana iniziano solitamente con una persona, un account e autorizzazioni assegnate. Gli amministratori possono verificare chi possiede l'account e a quali risorse possa accedere.

Gli account di servizio estendono questo modello alle applicazioni. Funzionano ragionevolmente bene quando il software segue codice deterministico e svolge una funzione ristretta e documentata.

Un agente AI si comporta diversamente. La sua azione successiva dipende da obiettivi in linguaggio naturale, contesto recuperato, ragionamento del modello, strumenti disponibili e passaggi precedenti all'interno di un flusso di lavoro.

Lo stesso agente autenticato può esaminare un errore, modificare un repository, chiamare un servizio di deployment e inviare un messaggio a un team. Il suo ruolo effettivo cambia con lo sviluppo dell'attività.

Le organizzazioni spesso gestiscono questa complessità lasciando che l'agente erediti gli accessi esistenti di un utente. Questo approccio semplifica il deployment, ma indebolisce l'attribuzione.

Un record di audit può mostrare che un account sviluppatore ha avviato un pacchetto. Potrebbe non mostrare se lo sviluppatore abbia richiesto quel pacchetto specifico o esaminato prima il comando.

Potrebbe inoltre omettere quale documento recuperato abbia influenzato il modello. Senza questa provenienza, gli investigatori vedono l'azione finale ma non la catena di autorità che la sostiene.

Il sondaggio sulla sicurezza degli agenti della Cloud Security Alliance illustra il divario di preparazione. Il 40% delle organizzazioni intervistate ha riferito di avere agenti in produzione, mentre un altro 31% li stava testando.

Solo il 18% ha riferito un'elevata fiducia nella capacità dei sistemi di identità esistenti di gestire efficacemente le identità degli agenti. Appena il 21% manteneva un registro o inventario degli agenti in tempo reale.

Il sondaggio ha inoltre rilevato una continua dipendenza da chiavi API statiche, account di servizio condivisi e combinazioni di nome utente e password. Questi meccanismi possono autenticare l'accesso senza rappresentare l'intento delegato.

Un'identità utile per un agente dovrebbe rispondere a più domande oltre a “quale token ha effettuato questa richiesta?”. Dovrebbe collegare la richiesta a un proprietario, un'attività, strumenti approvati, un ambito dei dati e un punto di scadenza.

Questo record dovrebbe sopravvivere alla delega. Se un agente primario crea un sotto-agente, quest'ultimo non dovrebbe ereditare silenziosamente ogni privilegio disponibile al suo genitore.

Ogni identità delegata dovrebbe ricevere solo l'autorità necessaria per il passaggio assegnato. Il sistema dovrebbe inoltre preservare la relazione tra l'utente, l'agente genitore, l'agente figlio e l'azione risultante.

GhostJacking mostra cosa accade quando questa catena resta implicita. L'errore malevolo non deve rubare l'identità dell'agente perché può guidare l'identità già presente.

Questo ricorda il classico problema del deputato confuso. Un programma attendibile usa impropriamente la propria autorità dopo aver accettato input influenzati da un attaccante che non riesce a classificare correttamente.

I modelli linguistici rendono il problema più difficile perché interpretano i contenuti in modo probabilistico. Una “risoluzione” formattata con astuzia può sembrare più operativa di una vaga istruzione dell'utente.

La gerarchia dei prompt aiuta i modelli a dare priorità alle istruzioni di sistema e dell’utente. Non crea un confine crittografico tra l’output fattuale degli strumenti e i comandi incorporati in tale output.

Anche l’etichettatura di una fonte come non attendibile presenta dei limiti. Tenet afferma che gli agenti talvolta hanno seguito istruzioni iniettate anche quando le configurazioni indicavano loro di non fidarsi dei contenuti esterni.

Questa affermazione richiede test indipendenti più ampi su modelli e configurazioni diversi. Tuttavia, i risultati adattivi del NIST supportano l’avvertimento più generale secondo cui le difese basate esclusivamente sulle istruzioni si degradano sotto pressione mirata.

Il livello di identità deve quindi presumere che il modello possa prendere una decisione errata. La governance dovrebbe limitarne le conseguenze prima che quella decisione diventi un’azione irreversibile.

Il compromesso fondamentale è tra accesso utile e intento verificabile

Un agente diventa più utile man mano che acquisisce accesso, ma ogni autorizzazione aggiuntiva amplia l’impatto di un intento manipolato.

Un assistente di programmazione limitato ai suggerimenti può comunque produrre codice non sicuro. Un agente di programmazione con accesso al terminale può eseguire quel codice prima che uno sviluppatore lo legga.

Un agente per la gestione degli incidenti limitato ai riepiloghi può distorcere un’indagine. Lo stesso agente, con accesso alla produzione, può modificare l’infrastruttura seguendo un record diagnostico avvelenato.

Questo crea un compromesso pratico, non un motivo per rifiutare ogni automazione agentica. Le organizzazioni devono collegare l’autonomia a controlli progressivamente più rigorosi.

L’accesso in sola lettura dovrebbe rimanere l’impostazione predefinita per l’esplorazione e la diagnosi. L’accesso in scrittura dovrebbe essere concesso per attività, risorse e finestre temporali specifiche.

L’esecuzione dei comandi merita un confine separato. Un agente in grado di recuperare dati di monitoraggio non dovrebbe ricevere automaticamente un permesso illimitato di eseguire qualsiasi cosa tali dati raccomandino.

Le azioni ad alto rischio richiedono anche un’autorizzazione semantica. Ciò significa valutare lo scopo e il contesto di un’azione, non limitarsi a verificare che il chiamante possieda un token valido.

Per esempio, una policy può consentire a un agente di eseguire un comando di test approvato all’interno di uno spazio di lavoro isolato. La stessa policy può negare l’installazione di pacchetti, l’accesso alle credenziali o le connessioni in uscita.

Tali decisioni dovrebbero avvenire al di fuori del modello. Chiedere allo stesso agente potenzialmente manipolato di giudicare il proprio comando non stabilisce un controllo indipendente.

L’applicazione delle policy in fase di esecuzione offre una separazione più solida. Un gateway può ispezionare ogni chiamata agli strumenti richiesta, confrontarla con la policy e bloccare le azioni al di fuori dell’attività approvata.

Il gateway crea inoltre un punto in cui registrare prove strutturate. Tali prove possono includere l’identità richiedente, l’obiettivo dell’utente, la fonte recuperata, l’operazione richiesta, la decisione della policy e il risultato.

L’approvazione umana rimane utile quando il potenziale impatto è elevato. Tuttavia, una generica finestra di conferma non è sufficiente.

Il revisore deve vedere cosa farà il comando, a quali file o sistemi può accedere e quali contenuti esterni lo hanno attivato. Altrimenti, l’approvazione diventa un altro clic di routine.

Il sandboxing limita i danni quando l’autorizzazione fallisce. Un agente di programmazione può lavorare in un ambiente usa e getta senza accesso alle credenziali di produzione o a connessioni di rete senza restrizioni.

Anche le credenziali di breve durata riducono l’esposizione permanente. L’agente dovrebbe ottenere un token con ambito ristretto per l’operazione corrente, per poi perdere tale autorità al termine dell’attività.

La ricerca AutoJack di Microsoft rafforza la stessa lezione progettuale attraverso un meccanismo diverso. Contenuti web non attendibili hanno raggiunto un percorso di controllo MCP locale e potevano generare processi in una build di sviluppo.

Microsoft ha riferito che la superficie interessata è stata rafforzata prima di arrivare alla relativa release pacchettizzata. La conclusione più ampia resta importante perché l’agente ha dissolto un confine normalmente considerato affidabile.

Un browser umano che visita una pagina esterna di norma non diventa il processo di automazione locale. Un browser controllato da un agente può ricoprire entrambi i ruoli contemporaneamente.

L’attacco GhostJacking attraversa un confine semantico, mentre AutoJack ha attraversato confini tra web, localhost e piano di controllo. Entrambi i casi mostrano agenti che collegano domini di sicurezza che i controlli precedenti mantenevano separati.

Questo confronto mette sotto pressione contemporaneamente fornitori di identità, provider di modelli, framework per agenti e team di sicurezza aziendale. Nessuno può risolvere il problema da solo.

Gli sviluppatori di modelli possono migliorare la resistenza alle istruzioni malevole. Gli sviluppatori di framework possono etichettare i dati e vincolare gli strumenti.

I provider di identità possono emettere credenziali di carico di lavoro con ambito ristretto e preservare la delega. Le aziende devono comunque definire proprietà, soglie di approvazione e autonomia accettabile.

Il progetto corretto presume che ogni livello possa fallire. Un modello resistente dovrebbe comunque operare secondo il principio del privilegio minimo, e un’identità ben delimitata dovrebbe comunque essere soggetta a controlli delle policy in fase di esecuzione.

Cosa le prove su GhostJacking non dimostrano ancora

La dimostrazione rivela una classe di attacco credibile, ma non prova uno sfruttamento criminale diffuso né il fallimento universale degli agenti.

Le cifre più elevate riportate provengono da Tenet Security, che vende anche protezione per sistemi agentici. Questa posizione commerciale non invalida i risultati, ma rende particolarmente importante una replica indipendente.

Il dato di 2.388 organizzazioni descrive condizioni di esposizione individuate. Non significa che gli aggressori abbiano compromesso con successo ogni organizzazione o che ciascuna abbia collegato attivamente dati Sentry a un agente dotato di poteri.

Analogamente, oltre 100 azioni osservate degli agenti provenivano da una ricerca controllata. Il risultato dimostra fattibilità e portata nel test riportato, non un tasso di violazione misurato nell’intero settore del software.

Anche le configurazioni dei prodotti variano. Alcuni agenti richiedono l’approvazione prima dei comandi shell, mentre altri operano all’interno di container o spazi di lavoro cloud con restrizioni.

Modelli diversi possono interpretare lo stesso payload in modo diverso. Il loro comportamento può anche cambiare dopo aggiornamenti, nuovi prompt di sistema o formattazioni modificate delle risposte degli strumenti.

La superficie di attacco dipende dalle autorizzazioni. Un agente con accesso in sola lettura all’interno di un repository isolato presenta meno rischi di uno che detiene chiavi cloud e accesso illimitato al terminale.

Queste differenze rendono fuorviante un unico tasso di fallimento da titolo. I team di sicurezza necessitano di test basati sui propri modelli, strumenti, credenziali e regole di approvazione.

Anche il nome “GhostJacking” può creare confusione. I materiali pubblicati da Tenet usano principalmente “Agentjacking” per la tecnica dell’errore avvelenato.

GhostJacking è meglio considerarlo un’etichetta descrittiva per una presa di controllo invisibile dell’agente, non necessariamente una categoria di vulnerabilità standardizzata distinta. Il meccanismo centrale rimane l’iniezione indiretta di prompt seguita dall’uso autorizzato degli strumenti.

Non esiste inoltre una patch universale per la piattaforma. Filtrare un payload noto può fermare una dimostrazione senza risolvere il problema generale delle istruzioni nei dati.

Bloccare titoli Markdown, comandi dei gestori di pacchetti o frasi specifiche invita gli aggressori a riformattare lo stesso intento. Le valutazioni adattive mostrano ripetutamente perché le difese basate solo sulle firme invecchiano rapidamente.

Al contrario, affermare che il problema sia del tutto irrisolvibile sopravvaluterebbe le prove. Un addestramento migliore dei modelli, l’etichettatura dei dati, l’isolamento degli strumenti e l’applicazione delle policy possono ridurre il rischio.

L’obiettivo realistico non è il rilevamento perfetto all’interno del modello. È impedire che un’unica interpretazione errata diventi un’esecuzione senza restrizioni.

Le organizzazioni dovrebbero iniziare con un inventario. I team non possono governare agenti di cui ignorano l’esistenza, compresi gli strumenti locali per sviluppatori e le integrazioni sperimentali.

Ogni agente necessita di un proprietario nominato e di uno scopo documentato. I team di sicurezza dovrebbero registrare modelli, strumenti, fonti di dati, credenziali, ambienti di esecuzione e percorsi di delega.

I contenuti influenzati dall’esterno richiedono una classificazione esplicita. Log, ticket, commenti nei repository, email e pagine web dovrebbero entrare nell’agente come dati non attendibili.

Le autorizzazioni degli strumenti dovrebbero rimanere indipendenti dalla classificazione dei contenuti. Una fonte non attendibile non dovrebbe mai ottenere autorità solo perché un connettore affidabile l’ha recuperata.

I team dovrebbero quindi testare catene di attacco realistiche. Il red teaming deve includere telemetria avvelenata, ticket manipolati, pagine web ostili, descrizioni di strumenti compromesse e testi di mitigazione ingannevoli.

I test dovrebbero misurare gli esiti, non soltanto se il modello ripete una frase malevola. La domanda cruciale è se l’agente richiede o completa un’azione non autorizzata.

Cosa dovrebbero osservare i lettori di Google News

La fase successiva sarà decisa dai controlli in fase di esecuzione, dagli standard di identità e dalle prove provenienti da implementazioni reali.

Il primo segnale è la replica indipendente. I ricercatori dovrebbero testare la catena di telemetria avvelenata sulle versioni correnti degli agenti di programmazione, sulle modalità di approvazione, sui sandbox e sulle policy aziendali.

Repliche che confermassero alti tassi di esecuzione rafforzerebbero la tesi a favore dell’applicazione obbligatoria delle policy in fase di esecuzione. Tassi inferiori con configurazioni rafforzate identificherebbero controlli già efficaci.

Il secondo segnale è una separazione a livello di prodotto tra dati recuperati e istruzioni eseguibili. I protocolli degli strumenti necessitano di modalità strutturate per descrivere provenienza, affidabilità e uso consentito.

Un modello dovrebbe sapere che un testo proviene da un campo evento non autenticato. Ancora più importante, il livello di esecuzione dovrebbe negare a quel testo l’autorità di richiedere un comando.

Osservate se le piattaforme per agenti associano una provenienza verificabile alle risposte degli strumenti e la preservano nel ragionamento in più passaggi. Semplici etichette di avviso offriranno un valore limitato senza applicazione delle policy.

Il terzo segnale è un’infrastruttura di identità costruita per la delega. Le aziende necessitano di credenziali per agenti di breve durata, ambiti vincolati all’attività, inventari in tempo reale e relazioni padre-figlio verificabili.

I progressi diventeranno visibili quando i sistemi di identità sapranno rispondere a una domanda precisa: quale persona ha autorizzato questo agente, per quale obiettivo e con quali limiti?

Questi segnali contano oltre la programmazione. Gli agenti di assistenza clienti leggono ticket, gli agenti finanziari elaborano documenti e gli agenti di sicurezza indagano sugli avvisi.

Qualsiasi flusso di lavoro che combini contenuti non attendibili con strumenti privilegiati contiene lo stesso rischio strutturale. Il canale di distribuzione specifico cambierà, ma il problema dell’autorità rimane.

L’attenzione di Google News conferisce a GhostJacking un nome memorabile. La lezione duratura è meno drammatica e più consequenziale: l’autenticazione da sola non può stabilire un intento affidabile.

I team di sicurezza dovrebbero ora mappare ogni punto in cui un agente legge contenuti influenzati dall’esterno prima di agire. Iniziate da log, ticket, email, repository e strumenti web.

Poi identificate quali azioni possono modificare dati, eseguire codice, esporre segreti o contattare sistemi esterni. Collocate controlli di policy indipendenti tra tali input e i risultati.

Non aspettate la prova di una campagna di sfruttamento di massa. Usate l’attacco segnalato come avvertimento controllato e verificate se i vostri agenti possono riprodurlo.

Se un agente non sa spiegare chi ha delegato la sua autorità, quale fonte ha plasmato la sua decisione e perché una chiamata a uno strumento è stata consentita, non è pienamente governato.