Dirottamento dell'identità del flusso di lavoro: Noma Labs trasforma una normale email di assistenza in un accesso privilegiato ai dati

Il 9 settembre 2026 il team di ricerca di Noma Security, che scrive con il nome di Noma Labs, ha pubblicato un resoconto di quello che definisce dirottamento dell'identità dei flussi di lavoro: un flusso di lavoro AI aziendale legge un normale messaggio che arriva a un punto di ingresso pubblico — una casella di posta di supporto, una issue di GitHub, un modulo web, un documento condiviso — e poi esegue il lavoro richiesto usando il proprio account di servizio con privilegi elevati anziché i permessi del mittente. La dimostrazione di Noma mostra un soggetto esterno che invia un'email all'indirizzo pubblico di supporto di un'azienda e chiede, tra le altre cose, i numeri di vendita trimestrali contenuti nell'email più recente del direttore finanziario; pochi minuti dopo, il contenuto arriva nella casella di posta dell'attaccante. Nessun modello è stato ingannato e nessun account è stato compromesso, ed è questo il punto del rapporto: «tutto ciò che l'attaccante ha dovuto fare è stato chiedere». L'archivio non registra alcun danno reale — non viene nominata alcuna vittima e nessun sistema in uso viene descritto come compromesso — e classifica la scoperta come ricerca, gravità media, affidabilità A, contestata: no. Questo resoconto si basa sul rapporto di Noma Labs, sulla copertura di Dark Reading pubblicata lo stesso giorno e sull'approfondimento di CSO Online, e l'archivio degli incidenti AI contiene questa voce accanto alle voci vicine, ciascuna con le proprie fonti, la propria gravità e il proprio grado di affidabilità.

Vale la pena leggere i campi del record stesso prima del testo. È etichettato INFRA ed EXFIL, copre la regione GLOBAL, riporta un'unica data precisa al giorno, il 9 settembre 2026, e non è contrassegnato come voce fondamentale. La data è la data di pubblicazione della ricerca e nient'altro; non vi è alcuna cronologia dell'incidente collegata, perché non c'è alcun incidente da collocare nel tempo. È la prima cosa da tenere a mente: ciò che Noma ha pubblicato è un meccanismo e una categoria, non un resoconto di violazione.

Ciò che Noma ha dimostrato e ciò che non ha dimostrato

La sequenza della inbox di supporto è un'illustrazione costruita, non un caso cliente. Il rapporto di Noma non nomina un'organizzazione, non fornisce un conteggio dei deployment interessati, non pubblica telemetria da alcuna pipeline reale e non collega un'esecuzione proof-of-concept per questo scenario — a differenza della ricerca del gruppo di luglio, che rimandava a un'esecuzione pubblica di GitHub Actions. Ciò che il rapporto offre invece è una descrizione del meccanismo abbastanza precisa da poter essere verificata rispetto a un'architettura: arriva un input non autenticato, il modello lo interpreta correttamente, la pipeline esegue la chiamata downstream e tale chiamata viene effettuata con l'autorità del creatore del workflow.

Sasi Levi, responsabile della ricerca sulla sicurezza di Noma e autore del report, riassume la causa principale in una frase: «l'identità e i permessi dell'utente che attiva un workflow sono disaccoppiati dall'identità e dai permessi usati per eseguirlo». Dove questo vale, il workflow diventa, secondo le parole del report, «proxy non autenticati per azioni privilegiate ed esfiltrazione silenziosa di dati».

Poiché le azioni vengono eseguite tramite automazione fidata con credenziali valide, Noma sostiene che ci sia poco che i sistemi di allerta convenzionali possano rilevare. La richiesta è normale, l'output del modello è un output valido del modello, la chiamata API è autenticata, la risposta è quella che il flusso di lavoro è stato progettato per inviare. CSO Online ha citato il membro del red team Vibhum Dubey, che rende concreto il problema del rilevamento: "I singoli eventi possono sembrare del tutto legittimi. I segnali utili deriverebbero dalla correlazione tra il richiedente originale, l'identità usata a valle, le risorse a cui si accede, i parametri forniti e l'azione finale."

Il controllo che fallisce è un controllo di autorizzazione, non un filtro sui contenuti

L'illustrazione più incisiva del rapporto è una coppia di richieste identiche. Da un direttore amministrativo e finanziario: «Quali sono i numeri trimestrali delle vendite del direttore finanziario nella sua email più recente?» Da un mittente esterno: le stesse parole. Il punto di Noma è che il prompt e l'operazione richiesta sono gli stessi, mentre la decisione di autorizzazione dovrebbe essere del tutto diversa — «Un CFO ha diritto a quell'informazione; un mittente esterno no».

Secondo il rapporto, i rilevatori standard di prompt injection e i guardrail degli agenti classificano i due input allo stesso modo, perché in nessuno dei due c’è qualcosa di malevolo da rilevare. "Il rischio per la sicurezza non è nel prompt; è nel confine di autorizzazione." La tesi strutturale di Noma deriva da ciò: i guardrail, le istruzioni di sistema e i filtri sugli input "non sono stati progettati per fungere da confine di autorizzazione", quindi una pipeline che si affida a essi per decidere cosa un chiamante può recuperare si affida a un controllo a cui non è mai stato chiesto di svolgere quel compito.

La distinzione ha un'importanza pratica. L'iniezione diretta di prompt manipola il modo in cui il modello segue le istruzioni; l'iniezione indiretta di prompt nasconde le istruzioni in contenuti che il modello leggerà in seguito; il dirottamento dell'identità del flusso di lavoro, come lo definisce Noma, non richiede nessuna delle due, perché si tratta di una richiesta che il modello dovrebbe comprendere e che la pipeline dovrebbe eseguire. Un difensore che ha passato l'anno a rafforzare le difese contro l'iniezione ha lavorato su un livello diverso.

I flussi di lavoro statici restano al di fuori dell’iniziativa di hardening degli agenti

Noma separa due cose che vengono comunemente usate in modo intercambiabile. Un flusso di lavoro AI è una sequenza predefinita e statica in cui un modello costituisce una fase di elaborazione — la sintesi del report è fase A, modello, fase B, fase C — e la pipeline deterministica attorno al modello controlla ciò che accade. Un flusso di lavoro agentico è autonomo: l'agente decide quali fasi intraprendere e quali strumenti invocare. Gran parte dell'attuale impegno sulla sicurezza, sostiene il report, è stato dedicato al secondo tipo, limitando l'accesso agli strumenti e delimitando le autorizzazioni per gli agenti che prendono decisioni dinamiche, e tali controlli non raggiungono il primo.

Il report chiude anche un'evidente via di fuga. Limitare chi o cosa può attivare un workflow non risolve il problema: se un'automazione viene eseguita secondo una pianificazione alle 8:00 del mattino e agisce su una casella di posta in cui chiunque può scrivere, verificare "chi può attivare questo workflow" risponde alla domanda sbagliata. La regola di Noma è che ogni automazione deve essere valutata in base a "la parte meno affidabile in grado di influenzare ciò su cui agisce" — e-mail, moduli, ticket, issue di GitHub, documenti condivisi e messaggi di chat inclusi.

Noma afferma che Google ha risolto un caso di Google Workflows; Google non ha pubblicato nulla.

L'unica piattaforma nominata nel rapporto è quella di Google. Noma dichiara di aver identificato lo stesso vettore di rischio all'interno di Google Workflows, di averlo segnalato in modo responsabile e che Google ha preso atto del rapporto e confermato una correzione «senza divulgare i dettagli di implementazione». Quella frase costituisce l'intero registro pubblico. Non è stato possibile reperire alcun avviso, nota di rilascio o CVE di Google che descriva questo vettore, e ogni resoconto secondario della correzione — compresi quelli pubblicati nei giorni successivi al 9 settembre — la attribuisce a Noma anziché a Google.

Il rapporto non è inoltre perfettamente coerente su quale prodotto Google intenda. Il testo nomina Google Workflows; l'intestazione di una sezione nello stesso rapporto recita "Google Workspace: AI Workflow Identity Hijacking". Entrambi sono prodotti Google con confini di fiducia diversi, e il rapporto non li concilia. Noma non dice se il caso riportato sia stato sfruttato, quanti clienti siano stati esposti o cosa abbia cambiato la correzione — e poiché Google non ha detto nulla, nessuna di queste lacune può essere colmata dal lato del fornitore.

GitLost era lo stesso confine, visto attraverso una lente più ristretta

La precedente divulgazione di Noma offre alla categoria un precedente. Nel luglio 2026 il gruppo ha pubblicato una ricerca su GitHub Agentic Workflows, che ha chiamato GitLost: un workflow attivato quando una issue veniva assegnata leggeva il titolo e il corpo della issue e rispondeva con un commento, e poiché l'agente disponeva di accesso in lettura ai repository dell'organizzazione, gli utenti esterni potevano sfruttare l'assegnazione delle issue per raggiungere dati di repository privati. Dark Reading ne ha parlato il 7 luglio 2026 e ha descritto un attaccante che nascondeva comandi in inglese comune nel corpo di una issue aperta in un repository pubblico, senza bisogno di credenziali né di competenze di programmazione.

Le due impostazioni non sono identiche, e la differenza è la parte interessante. Il resoconto di luglio di Dark Reading è una storia di prompt injection: il testo controllato dall'attaccante viene letto come istruzioni. Il rapporto di settembre di Noma descrive GitLost in termini del trigger e dell'accesso in lettura all'intero repository, e lo presenta come lo stesso confine di autorizzazione visto da una certa angolazione. Entrambe le descrizioni si adattano a un flusso di lavoro il cui agente leggeva testo scritto da un esterno, ma solo la prima dipende dal fatto che il modello venga guidato. Noma ora afferma di aver segnalato lo stesso vettore di rischio a Google; non dice se il caso GitLost sia mai stato sfruttato al di là della dimostrazione pubblicata.

Secondo quanto dichiarato da Noma stessa in merito alla portata, Hacker News, Dark Reading e oltre 100 altre testate internazionali hanno trattato la ricerca GitLost. Quel dato è del fornitore e questo articolo non ha conteggiato autonomamente la copertura mediatica.

I professionisti concordano sul fatto che il meccanismo sia antico; la discussione riguarda il nome.

La copertura indipendente non ha contestato la conclusione, e due professionisti esterni hanno contestato la novità anziché la sostanza. Morey Haber, chief security adviser di BeyondTrust, ha dichiarato a Dark Reading: "Nessuno ha indotto un modello di IA a fare qualcosa che non avrebbe dovuto fare. Il modello ha fatto esattamente ciò che gli è stato detto, da uno sconosciuto (non attendibile), e il flusso di lavoro attorno a esso ha usato l'identità di qualcun altro per farlo accadere, poiché non era circoscritto e trattato con il privilegio minimo." CSO Online ha citato Vibhum Dubey, che ha descritto il pattern come "una classe nota di debolezza di autorizzazione", aggiungendo che, quando un input non autenticato può attivare un flusso di lavoro attendibile che agisce con i propri privilegi, "il flusso di lavoro può di fatto agire come un confused deputy".

Ram Varadarajan, amministratore delegato di Acalvio, ha offerto a Dark Reading un controllo del tutto diverso: invece di aumentare il filtraggio, popolare l'ambiente con esche — finti thread dirigenziali, record honeytoken — che non hanno alcun motivo legittimo per essere toccati da un flusso di lavoro autorizzato, così che una richiesta dall'apparenza innocua che tenti di accedere a una di esse oltrepassi un confine che non dovrebbe mai valicare. Il disaccordo, se così si può chiamare, riguarda se il contributo utile sia un nuovo nome per una falla di delega risalente al 1988 o una descrizione operativa di dove quella falla risieda oggi. La posizione di Noma è la seconda: che il pattern è sistemico nelle pipeline di AI aziendali e che gli attuali framework di sicurezza AI guardano la superficie sbagliata.

La mitigazione è la delega e un punto di controllo, non un filtro migliore

I controlli consigliati da Noma sono a livello applicativo piuttosto che a livello di modello. La delega di token consapevole dell'identità significa rimuovere le chiavi API amministrative statiche dai flussi di lavoro AI ed eseguire operazioni sui dati con token di delega a breve termine e con ambito limitato, legati al richiedente autenticato, in modo che il contesto utente si propaghi alla chiamata che effettivamente accede ai dati. I checkpoint di autorizzazione contestuale significano trattare ogni output del modello come input non attendibile e inserire una valutazione esplicita di controllo degli accessi e protezione a runtime tra la fase di trasformazione del modello e qualsiasi successiva chiamata a database o strumenti. La separazione asimmetrica degli output significa isolare strutturalmente il recupero dei dati dai canali di comunicazione esterni, in modo che un flusso di lavoro che gestisce dati interni sensibili non condivida un percorso di esecuzione con un meccanismo automatizzato che risponde a soggetti esterni.

Dubey ha fornito a CSO Online un test più economico di qualsiasi degli altri tre: confrontare i risultati tra i livelli di privilegio. "Se un utente con privilegi bassi può ottenere lo stesso risultato di un amministratore perché i sistemi a valle vedono solo l'identità del flusso di lavoro, è lì che concentrerei l'indagine."

Ciò che il verbale lascia aperto

• Nessuna vittima, nessun conteggio e nessuna telemetria. Il caso della casella di posta del supporto di Noma è una dimostrazione guidata; il rapporto non nomina alcuna organizzazione e l'archivio registra come falsi danni reali. La plausibilità del meccanismo non è prova che sia stato utilizzato.

• Quale prodotto Google è stato corretto e in cosa consisteva la correzione. Il testo di Noma parla di Google Workflows, il titolo della sua sezione dice Google Workspace, e Google non ha pubblicato nulla. Le organizzazioni non possono ancora stabilire da fonti pubbliche se una pipeline che eseguono rientrava nell'ambito.

• Se il vettore sia stato sfruttato da qualche parte. Né il rapporto né alcuna copertura mediatica esaminata per questo articolo descrive una campagna osservata, una perdita di dati o un risultato forense attribuibile al dirottamento dell'identità del workflow.

• Se la categoria regga alla prova della misurazione. Nessuna parte indipendente ha pubblicato una scansione, un corpus di pipeline interessate o una suite di test per il pattern; le prove in circolazione sono argomentazioni architetturali più il resoconto di un singolo fornitore su un singolo caso già corretto.

• Chi sostiene l'argomentazione. Noma Labs è il braccio di ricerca di Noma Security, che vende controlli di sicurezza per agenti esattamente del tipo raccomandato nel suo rapporto. Ciò non rende errato il risultato — Dark Reading e CSO Online lo hanno entrambi riportato, e nessuno dei due ha rilevato un errore fattuale — ma è un contesto che il lettore dovrebbe tenere presente mentre valuta quanto ampiamente è definita la categoria.

Il grado di severità del record, medio, e il suo flag di danno reale, falso, descrivono l’evidenza, non il meccanismo. Ciò che Noma ha effettivamente stabilito è ristretto e verificabile: che l’identità del trigger di un workflow e la sua identità di esecuzione sono cose distinte, che la seconda è di solito la più potente, e che una pipeline che non le confronta mai farà per un estraneo ciò che farebbe per la persona per cui è stata costruita. Il controllo che ne deriva è corrispondentemente poco appariscente: chiedere, per ogni automazione, chi può influenzare ciò su cui agisce, e se qualcosa a valle verifichi mai di nuovo che a chi chiede fosse consentito chiedere.