La guida CISA sui token AI avverte che l'utilizzo può diventare un attacco

CISA e le agenzie alleate di cybersicurezza avvertono che il consumo di AI può diventare una minaccia alla sicurezza prima ancora che un sistema vada offline. La guida CISA sui token AI affronta gli attacchi denial-of-wallet, abusi deliberati che fanno aumentare gli addebiti a consumo di un'organizzazione. La sua rilevanza va oltre le fatture inattese: limiti di spesa e capacità esaurita possono anche interrompere il lavoro che dipende dall'AI.

La copertura sulla cybersicurezza di ottobre di ExecutiveGov ha datato la notizia al 23 ottobre 2026. La tensione centrale è semplice. Le imprese desiderano sistemi AI che continuino a lavorare su attività complesse, ma l'attività prolungata consuma anche risorse. Un sistema che prosegue in modo affidabile un'attività non autorizzata o inefficiente crea un diverso tipo di problema di affidabilità.

Questa preoccupazione compare già nel framework di sicurezza di OWASP e nella documentazione di sicurezza aziendale di Microsoft. La guida la porta nella discussione su approvvigionamento e resilienza operativa. Acquirenti aziendali, sviluppatori e team di sicurezza si trovano ora davanti a una domanda condivisa: chi decide quando un workflow AI ha fatto abbastanza e chi può fermarne la spesa?

La guida CISA sui token AI collega la spesa alla continuità del servizio

Il cambiamento più rilevante è trattare il consumo di AI come una dipendenza operativa che merita supervisione di sicurezza.

La pubblicazione congiunta, disponibile tramite il Canadian Centre for Cyber Security, è intitolata AI token consumption. I token sono unità di informazione che i modelli AI elaborano o generano. Aiutano a misurare l'utilizzo, anche se il rapporto tra conteggio dei token, lavoro di calcolo e addebiti dipende dal servizio.

La pubblicazione distingue il danno finanziario dall'accesso esaurito. Gli attacchi denial-of-wallet aumentano deliberatamente i costi basati sull'utilizzo. Gli attacchi denial-of-tokens consumano le allocazioni o attivano limiti, interferendo con l'accesso legittimo. Gli esiti si sovrappongono, ma non sono intercambiabili.

La guida identifica anche cause operative ordinarie di esaurimento, tra cui la domanda legittima e applicazioni inefficienti. Invita le organizzazioni a comprendere il consumo e le condizioni di servizio prima di stipulare accordi con i fornitori. Per gli operatori di infrastrutture critiche, la preoccupazione include la continuità quando le capacità AI diventano degradate o indisponibili.

Questo inquadramento conta perché una salvaguardia finanziaria può diventare a sua volta un vincolo di disponibilità. Interrompere il consumo protegge un budget, ma uno stop indiscriminato può interrompere lavori importanti. Proseguire il consumo preserva temporaneamente l'accesso, ma lascia l'organizzazione esposta a ulteriori spese.

L'implicazione pratica è un conflitto tra obiettivi concorrenti. La finanza vuole un'esposizione prevedibile. Le operazioni vogliono un accesso affidabile. I team di prodotto vogliono il completamento con successo delle attività. La sicurezza vuole contenere i comportamenti sospetti. Un'implementazione AI necessita di un modo esplicito per risolvere questi obiettivi quando entrano in conflitto.

Si consideri un assistente documentale aziendale esemplificativo, usato per domande di routine e indagini operative urgenti. Entrambe le attività potrebbero dipendere dallo stesso account del modello sottostante. Un'attività in background inefficiente diventa rilevante se consuma le risorse necessarie all'indagine urgente.

Questo esempio non dimostra che una specifica organizzazione abbia subito un simile incidente. Mostra perché conta la posizione del confine di spesa. Un limite applicato a un intero account produce conseguenze diverse da un limite applicato a un singolo workflow.

Cambia anche il modo in cui dovrebbe essere interpretata una dimostrazione riuscita. Una dimostrazione stabilisce che un assistente può completare attività selezionate in condizioni selezionate. Non stabilisce come si comporta il servizio quando cambia la domanda, falliscono le dipendenze o l'attività consentita diventa eccessiva.

Per gli acquirenti, ciò crea un divario tra prove di capacità e prove operative. Le prime rispondono alla domanda se il sistema possa svolgere il lavoro. Le seconde rispondono alla domanda se l'organizzazione possa continuare a usarlo in condizioni avverse.

La guida CISA sui token AI rende più difficile lasciare questa seconda domanda fuori dal processo di acquisto. La questione appartiene alla discussione sulla disponibilità del servizio, sulle aspettative di ripristino e sulle responsabilità in caso di guasti.

La pressione ricade sugli acquirenti che non possono vedere i singoli workload

Una fattura AI aggregata non può spiegare se un singolo workflow meriti di continuare a funzionare.

La pressione immediata ricade sulle organizzazioni che acquistano capacità AI tramite applicazioni, integrazioni e servizi condivisi. La loro sfida è collegare il consumo a uno scopo aziendale. Senza questo collegamento, un totale di utilizzo in aumento offre poco aiuto durante un incidente.

Un'attività insolitamente costosa potrebbe essere legittima. Potrebbe comportare un'analisi difficile, una grande raccolta di documenti o ripetuti tentativi di risolvere prove contraddittorie. Lo stesso schema di spesa potrebbe anche riflettere un'integrazione difettosa o un abuso deliberato.

Questa ambiguità rende inaffidabili i giudizi semplici. Un consumo elevato non dimostra un intento malevolo. Un consumo ridotto non dimostra un comportamento sicuro. La domanda significativa è se l'attività resti autorizzata, proporzionata e utile.

I team di approvvigionamento necessitano quindi di prove sui confini dei controlli, anziché di formulazioni rassicuranti sul monitoraggio. Una dashboard può mostrare un problema senza prevenirlo. Un avviso può notificare qualcuno che non dispone dell'autorità o dei mezzi tecnici per intervenire.

La documentazione Microsoft su unbounded AI consumption descrive l'esaurimento delle risorse tramite prompt impegnativi, richieste ripetute e attività eccessiva degli agenti. Raccomanda controlli sulle chiamate al modello e sui servizi downstream, incluse quote, contenimento e limiti all'espansione degli agenti. Microsoft rileva inoltre che gli incidenti malevoli ampiamente pubblicizzati restano limitati.

Quest'ultima precisazione è importante per gli acquirenti. Un modello di minaccia credibile sostiene la preparazione, ma non giustifica il trattare ogni aumento dei costi come un attacco. Buone decisioni di acquisto richiedono la distinzione tra un meccanismo dimostrato e la prevalenza misurata degli incidenti.

La posizione di Microsoft offre anche un confronto utile con il framework di sicurezza applicativa di OWASP. Microsoft descrive i controlli in un contesto di sicurezza aziendale. OWASP classifica la debolezza di consumo sottostante nelle applicazioni. Queste prospettive rafforzano il problema senza dimostrare che un particolare fornitore lo abbia risolto.

L'implicazione commerciale è che i fornitori dovranno spiegare sempre più l'ambito dei loro controlli. Una restrizione si applica a un cliente, un reparto, un'applicazione o una singola attività? Un operatore può isolare il lavoro sospetto preservando l'attività non correlata?

Queste domande incidono anche sulla responsabilità all'interno dell'organizzazione acquirente. Un team finanziario potrebbe possedere il budget mentre l'ingegneria possiede l'integrazione. La sicurezza potrebbe ricevere avvisi senza possedere il contratto. Un passaggio di consegne irrisolto può lasciare tutti informati e nessuno responsabile di fermare il workflow.

Per gli sviluppatori, la visibilità sui consumi diventa parte della diagnosi del comportamento applicativo. Sapere che un account ha speso di più dice meno che sapere quale attività ha ripetuto un'azione senza successo. Prove utili dovrebbero collegare l'attività, il suo avanzamento e le risorse consumate.

Per i knowledge worker, le conseguenze si manifestano come risposte ritardate, ricerche interrotte o assistenti indisponibili. Raramente controllano l'allocazione delle risorse sottostanti. La loro esperienza dipende da decisioni prese da approvvigionamento e ingegneria molto prima dell'interruzione.

I team che esaminano queste dipendenze possono conservare contratti approvati, decisioni architetturali e procedure di incidente in una base di conoscenza tecnica ricercabile. La documentazione supporta una risposta coordinata, sebbene non possa sostituire i controlli applicati dall'applicazione.

Autonomia utile e consumo delimitato tirano in direzioni diverse

Il compromesso centrale è tra consentire a un sistema di proseguire un lavoro utile e impedirgli di continuare indefinitamente.

Un agente AI è software che usa un modello per selezionare azioni durante un'attività. Questo può rendere più facile delegare lavori difficili. Significa anche che la richiesta originale non descrive necessariamente ogni azione che segue.

Un utente potrebbe autorizzare un'indagine senza sapere di quali ricerche, documenti o servizi esterni l'agente avrà bisogno. Un confine restrittivo rischia di interrompere prematuramente un lavoro utile. Un confine aperto lascia l'organizzazione ad accettare conseguenze che non ha specificato pienamente.

La categoria OWASP unbounded consumption identifica l'uso non controllato del modello come fonte di degrado del servizio e danno economico. I suoi esempi includono richieste eccessive e query ad alta intensità di risorse. Il framework raccomanda protezioni stratificate, tra cui gestione delle risorse, timeout, monitoraggio e degrado graduale, ossia funzionalità ridotte che preservano un servizio utile.

Questa prospettiva rende la questione più ampia della lunghezza di un prompt. Una breve istruzione può avviare un workflow complesso. Contare soltanto le richieste in ingresso dice poco su tutto ciò che l'applicazione fa dopo averle accettate.

Un assistente di ricerca esemplificativo potrebbe cercare in una raccolta di documenti, esaminare passaggi in conflitto e richiedere ulteriori prove. Ogni azione può essere ragionevole singolarmente. La domanda aziendale è se la sequenza continui ad avanzare l'indagine autorizzata.

È qui che completamento e prosecuzione dell'attività divergono. L'attività continuata può apparire produttiva in un'interfaccia anche quando il lavoro sottostante ha smesso di fare progressi. Un flusso di aggiornamenti di stato non dimostra che l'azione successiva meriti più risorse.

La stessa tensione appare nel recupero dagli errori. Ripetere un'azione non riuscita talvolta risolve un problema temporaneo. Ripetere un'azione che non può avere successo prolunga soltanto il fallimento. Un'applicazione necessita di un modo per distinguere queste situazioni usando prove che vadano oltre la disponibilità del modello a tentare di nuovo.

Questa distinzione dovrebbe anche modellare il modo in cui le organizzazioni valutano l'autonomia. Un minore intervento umano non è automaticamente migliore se gli operatori perdono la capacità di comprendere ciò che continua. Un maggiore intervento non è automaticamente più sicuro se le approvazioni di routine diventano interruzioni prive di significato.

Una valutazione utile chiede quali prove consentano al workflow di procedere. Ha ottenuto nuove informazioni? È cambiata una dipendenza? Ha completato un risultato intermedio significativo? Queste sono domande analitiche sul progresso, non affermazioni che un prodotto attuale vi risponda in modo affidabile.

La responsabilità va inoltre oltre il fornitore del modello. Un'applicazione decide quale lavoro richiedere, quali strumenti esporre e come gestire le attività non completate. Queste decisioni incidono sull'esposizione anche quando il modello sottostante si comporta come previsto.

Questo spiega perché non si può presumere che cambiare modello risolva il problema. Un modello meno intensivo in risorse potrebbe ridurre la spesa per ogni azione. Non dimostra che l'applicazione sceglierà un numero appropriato di azioni.

Le linee guida CISA sui token dell’AI si inseriscono quindi in un dibattito più ampio sull’autorità delegata. Autorizzare un sistema di AI a perseguire un obiettivo dovrebbe includere un confine definito attorno alle risorse che può impegnare.

Il difficile problema progettuale consiste nel preservare un utile margine di discrezionalità all’interno di tale confine. Le imprese hanno bisogno di flessibilità sufficiente per il lavoro complesso, insieme a una spiegazione credibile di ciò che accade quando il limite viene raggiunto.

Il software attorno al modello determina il limite di spesa

Il giudizio di un modello e il permesso di un’applicazione di spendere sono decisioni separate.

L’avviso dell’Australian Signals Directorate sugli ambienti di esecuzione per AI agentica, pubblicato l’11 settembre 2026, pone l’attenzione sul software circostante. Un harness è il livello software che collega un modello a strumenti, dati, memoria e controlli di esecuzione.

L’avviso sostiene che le organizzazioni dovrebbero valutare questo livello come una fonte distinta di rischio operativo e di sicurezza. L’enfasi riguarda autorizzazioni, monitoraggio, supervisione e le modalità con cui i modelli interagiscono con i sistemi connessi. Ciò fornisce un utile complemento architetturale alle linee guida sui token.

La distinzione è importante perché un assistente può raccomandare un’azione senza avere l’autorità di eseguirla. L’applicazione che circonda il modello determina se l’azione avviene. La stessa separazione può applicarsi all’autorizzazione di ulteriore consumo di risorse.

Da questa prospettiva, un limite di spesa dovrebbe essere una decisione dell’applicazione che il modello non può semplicemente aggirare con le parole. Chiedere a un modello di restare parsimonioso è diverso dall’imporre una restrizione applicabile. Il primo esprime un obiettivo; il secondo modifica il comportamento consentito.

Una ricerca presentata a settembre aggiunge una preoccupazione tecnica più circoscritta. Un preprint sullo stato fatturabile persistente esamina i contenuti di strumenti esterni mantenuti tra le interazioni di un agente. Gli autori riferiscono che i contenuti conservati possono diventare input fatturabili ricorrenti quando le richieste successive li includono nuovamente.

Il loro studio testa attacchi e difese lato host in flussi di lavoro controllati. I risultati riguardano la gestione delle informazioni conservate, anziché costituire prova di compromissioni diffuse nelle imprese. In quanto preprint, richiede esame critico e replicazione indipendente prima di trarre conclusioni generali sul rischio di implementazione.

La ricerca evidenzia comunque un’importante distinzione tra accettare informazioni e pagare ripetutamente per elaborarle. Una risposta di uno strumento può rimanere in un flusso di lavoro dopo che il suo scopo immediato è terminato. Le decisioni sulla conservazione meritano quindi attenzione accanto alle decisioni di accesso.

Un’indagine documentale esemplificativa rende concreto il problema. Un assistente recupera un lungo rapporto per rispondere a una domanda circoscritta. Se l’applicazione continua a fornire quel rapporto durante azioni di follow-up non correlate, l’elaborazione continuativa necessita di una propria giustificazione.

Eliminare semplicemente tutto non è una risposta generale adeguata. L’assistente potrebbe aver bisogno di prove precedenti per risolvere contraddizioni o spiegare la propria conclusione. La questione architetturale è quali informazioni restano necessarie e come l’applicazione rende visibile tale valutazione.

È anche qui che i confronti tra provider diventano più significativi. Gli acquirenti possono confrontare il trattamento della cronologia delle attività, dell’intervento e del comportamento di riavvio. Un contesto disponibile più lungo, ossia le informazioni che un modello può considerare durante una richiesta, non risolve queste questioni operative.

Allo stesso modo, cambiare provider crea una nuova dipendenza anziché eliminare il bisogno di governance. Il servizio destinatario potrebbe gestire le informazioni in modo diverso. Un fallback che preserva la disponibilità necessita comunque di una valutazione in termini di correttezza, autorizzazioni ed esposizione delle risorse.

L’implicazione centrale riguarda il controllo organizzativo. Le imprese dovrebbero comprendere quali decisioni spettano al modello, quali all’applicazione e quali richiedono autorità umana. Confondere queste responsabilità rende più difficile indagare sia la spesa eccessiva sia le interruzioni non necessarie.

L’avvertimento è credibile, ma la diffusione degli attacchi resta incerta

Un percorso di attacco plausibile non stabilisce con quale frequenza gli aggressori lo sfruttino né quanti danni provochi.

Le fonti disponibili supportano il trattamento del consumo eccessivo come una questione di sicurezza e resilienza. Non forniscono una misurazione completa degli incidenti malevoli di denial-of-wallet nelle imprese. Questa incertezza dovrebbe rimanere visibile nella copertura dell’avvertimento.

La distinzione è importante perché diversi tipi di guasto possono produrre sintomi simili. Una richiesta malevola, un difetto software e un’attività legittima inaspettatamente complessa possono tutti aumentare il consumo. Un picco di spesa da solo non può stabilire quale spiegazione sia corretta.

Definire ogni picco un attacco distorcerebbe la segnalazione degli incidenti. Definire ogni picco normale domanda oscurerebbe gli abusi. Le organizzazioni hanno bisogno di prove sufficienti a livello di attività per indagare prima di scegliere una delle due interpretazioni.

Esiste inoltre un limite importante alle affermazioni sui controlli protettivi. Una soglia configurata dimostra che esiste un’impostazione. Non stabilisce con quale rapidità avvenga l’applicazione, quale attività copra o se il lavoro dipendente continui altrove.

Un avviso costituisce un’affermazione ancora più circoscritta. Dimostra che il sistema può notificare qualcuno in condizioni specificate. Gli acquirenti devono comunque comprendere i ritardi di notifica, le responsabilità di escalation e le azioni disponibili dopo la notifica.

Analogamente, una dimostrazione riuscita di contenimento dovrebbe essere interpretata nelle condizioni in cui è stata testata. Fermare un carico di lavoro artificiale dimostra qualcosa di utile su quel test. Non stabilisce automaticamente protezione contro ogni flusso di lavoro, integrazione o schema di abuso.

La più forte domanda scettica riguarda le conseguenze per l’attività aziendale. Un controllo che arresta il consumo eccessivo può comunque interrompere il lavoro legittimo. Valutare la protezione richiede quindi di esaminare sia l’esposizione evitata sia il lavoro che la protezione blocca.

Questo compromesso diventa particolarmente importante quando le organizzazioni usano i tassi di completamento per valutare gli assistenti. Interventi aggressivi possono ridurre il completamento con successo. Una prosecuzione permissiva può migliorare il completamento apparente aumentando al tempo stesso l’esposizione. Un confronto significativo deve considerare entrambi gli esiti.

Un’altra incertezza riguarda il punto in cui inizia e termina la responsabilità contrattuale. Un provider potrebbe fornire il monitoraggio mentre il cliente configura l’applicazione delle regole. Un fornitore di applicazioni potrebbe dipendere dal servizio di modelli di un’altra azienda. Gli acquirenti dovrebbero evitare di dedurre la responsabilità dal nome di una funzionalità.

Anche le linee guida stesse dovrebbero essere descritte accuratamente. Una pubblicazione sulla cybersecurity non equivale automaticamente a un nuovo obbligo legale. Qualsiasi affermazione su obblighi vincolanti richiederebbe un’autorità distinta e applicabile. Le fonti qui stabiliscono linee guida e preoccupazioni tecniche, anziché una scadenza universale di conformità.

Per i team di prodotto, la risposta ragionevole è una convalida proporzionata. Possono verificare se attività rappresentative rimangano utili entro limiti realistici. Possono inoltre testare se attività sospette o non funzionanti si arrestino senza disabilitare il lavoro non correlato.

Per i lettori, lo standard di reporting dovrebbe rimanere altrettanto rigoroso. Richiedete distinzioni chiare tra controlli raccomandati, comportamento testato in modo indipendente e incidenti verificati. Queste categorie rispondono a domande diverse e trattarle come intercambiabili rende le decisioni di acquisto meno affidabili.

Le linee guida CISA sui token dell’AI sono rilevanti senza richiedere affermazioni esagerate. Identificano una dipendenza che le organizzazioni possono esaminare ora, lasciando aperte a ulteriori prove la frequenza e la gravità dello sfruttamento nel mondo reale.

Osservare l’applicazione delle regole, l’isolamento dei carichi di lavoro e i test indipendenti

Le prossime evidenze dovrebbero mostrare se le organizzazioni possono contenere il lavoro eccessivo preservando al contempo il servizio legittimo.

Nei prossimi mesi, i segnali più utili riguarderanno il comportamento operativo piuttosto che promesse generali su un’AI più sicura. La pubblicazione offre una base chiara per porre domande più specifiche. Non stabilisce che provider o acquirenti abbiano già risposto a tali domande.

Il primo segnale è una documentazione più chiara del comportamento di applicazione delle regole. Occorre osservare se i fornitori distinguono tra notifiche e restrizioni, spiegando con precisione dove si applica ciascuna restrizione. Ciò rafforzerebbe l’idea che la governance dei consumi stia diventando una capacità di prodotto utilizzabile.

Il segnale opposto indebolirebbe tale valutazione. Se la documentazione continua a descrivere budget senza spiegare l’intervento, gli acquirenti faticheranno ancora a stimare l’esposizione. Una funzionalità dovrebbe essere giudicata dal suo effetto operativo, compreso ciò che resta consentito dopo la sua attivazione.

Il secondo segnale è l’evidenza dell’isolamento dei carichi di lavoro nei requisiti di acquisto e nei test di accettazione. L’isolamento dei carichi di lavoro consiste nel limitare un’attività problematica senza interrompere inutilmente le altre. L’evidenza pertinente mostrerebbe che l’attività critica prosegue mentre l’attività a priorità inferiore o sospetta si arresta.

Ciò sosterrebbe il collegamento delle linee guida tra controlli dei consumi e continuità. Uno spegnimento a livello di account potrebbe comunque essere appropriato in alcune circostanze. Tuttavia, presentare tale comportamento come equivalente a un contenimento selettivo nasconderebbe una differenza rilevante.

Il terzo segnale consiste in test indipendenti che combinano il contenimento con il completamento utile delle attività. Occorre cercare valutazioni che pubblichino le proprie ipotesi sui carichi di lavoro e spieghino perché le attività interrotte si siano fermate. Risultati solidi mostrerebbero un’esposizione limitata insieme al completamento credibile del lavoro autorizzato.

Risultati che misurano soltanto la riduzione dei consumi lascerebbero una lacuna importante. Spendere meno è facile se un assistente rifiuta abbastanza lavoro. Il test difficile consiste nel verificare se i limiti preservino lo scopo aziendale per cui il sistema è stato acquistato.

Questi segnali creano anche un modo pratico per confrontare offerte concorrenti. Gli acquirenti possono esaminare l’applicazione delle regole documentata, il comportamento di isolamento e gli esiti valutati in modo indipendente. Ciò produce una valutazione più utile rispetto all’affidarsi alle sole affermazioni sulle capacità del modello.

Per gli sviluppatori, l’implicazione immediata è rendere il comportamento operativo verificabile. Un’attività dovrebbe avere uno scopo identificabile, un responsabile accountable e una condizione di arresto comprensibile. Queste proprietà rendono i guasti più facili da diagnosticare e le affermazioni commerciali più facili da testare.

Per i leader aziendali, chiedete al team responsabile di un servizio di AI di tracciare un’attività rappresentativa dall’autorizzazione fino al completamento o all’interruzione. Identificate chi possiede il suo limite di risorse, chi può intervenire e quale lavoro non correlato rimane disponibile successivamente. Richiedete prove di un test effettivo anziché accettare una dashboard come risposta. Usate le linee guida CISA sui token dell’AI per inquadrare questa revisione attorno alla continuità operativa oltre che alla spesa. Confrontate quindi il comportamento osservato con l’accordo di servizio e le responsabilità interne. Se queste versioni non coincidono, risolvete il disaccordo prima di ampliare l’implementazione. La decisione di delegare il lavoro dovrebbe accompagnarsi a una risposta chiara su chi possa arrestarlo.