{"id":31073,"date":"2026-10-21T10:59:44","date_gmt":"2026-10-21T08:59:44","guid":{"rendered":"https:\/\/www.kaspersky.it\/blog\/?p=31073"},"modified":"2026-10-21T10:59:44","modified_gmt":"2026-10-21T08:59:44","slug":"tokenomics-ai-and-cybersecurity","status":"publish","type":"post","link":"https:\/\/www.kaspersky.it\/blog\/tokenomics-ai-and-cybersecurity\/31073\/","title":{"rendered":"L’impatto diretto della “tokenomics” sui processi di cybersecurity"},"content":{"rendered":"

Di recente abbiamo pubblicato un post sugli attacchi \u201ctokenomics\u201d<\/a> e \u201cdenial of wallet\u201d: un nuovo tipo di attacco DDoS volto a spendere troppo i token IA. Ma prima che gli specialisti della sicurezza inizino a proteggere i processi di IA dei colleghi da questa nuova minaccia, dovrebbero ricordare che il lavoro stesso del dipartimento di sicurezza delle informazioni pu\u00f2 diventare un bersaglio per un simile autore dell\u2019attacco. Poich\u00e9 i team di sicurezza stanno ora testando e implementando attivamente vari tipi di automazione basata sull\u2019IA, la minaccia di interferenza esterna volta a paralizzare il sistema di difesa colpisce direttamente i propri processi e le tecnologie.<\/p>\n

Elastic ha stimato<\/a> che, a seconda dell\u2019architettura \u201cSOC basato su agente\u201d, il triage di un singolo avviso da un host pu\u00f2 costare 0,69 dollari per un insieme di agenti altamente specializzati o 3,42 dollari per un agente generico con 14 diverse competenze.<\/p>\n

Tuttavia, queste medie nascondono un\u2019ampia gamma di variazioni. In qualsiasi momento, l\u2019elaborazione di base di un semplice avviso (ad esempio, un migliaio di token) pu\u00f2 trasformarsi in un\u2019indagine a catena che implica l\u2019elaborazione di milioni di voci di registro, chiamate API e altri dati correlati, il che equivale a milioni di token in una questione di minuti<\/a>.<\/p>\n

Lo stesso Elastic riconosce di utilizzare il modello Claude Sonnet 4.6 nel proprio SOC. Questo solleva immediatamente la domanda: cosa succede quando il budget si esaurisce o vengono attivati i filtri di sicurezza del modello? Nello scenario peggiore, si verifica quanto segue: il SOC IA avvia un'\u201dorchestra di agenti\u201d per indagare su eventi sospetti simili a movimenti laterali nell\u2019infrastruttura. L\u2019agente chiama l\u2019API di Anthropic, ma il budget mensile del dipartimento \u00e8 stato esaurito e l\u2019API restituisce gli errori. L\u2019indagine si blocca e le persone lo scoprono mezza giornata dopo. Inoltre, se i \u201cfiltri di sicurezza\u201d in continua evoluzione di uno dei principali provider di IA segnalano le richieste del SOC come dannose, lo stesso effetto \u00e8 possibile anche senza esaurire il budget, come dimostrato dall\u2019esperienza di Hugging Face<\/a> nell\u2019indagine sulla violazione della propria infrastruttura da parte di OpenAI.<\/p>\n

Naturalmente, un autore dell\u2019attacco ha interesse a un risultato del genere. Possono influenzare direttamente i costi dei difensori iniettando prompt dannosi nei dati a loro disposizione (record DNS TXT, intestazioni HTTP, commenti sul codice, nomi file e cos\u00ec via), contando sul fatto che tali prompt verranno elaborati dai sistemi di sicurezza delle informazioni. Ad esempio, nel caso di attacco GhostJacking<\/a>, i registri WAF fungono da vettore per l\u2019iniezione di prompt e in uno studio accademico \u00e8 stato proposto un altro metodo: i ricercatori sono riusciti ad attaccare i guardrail di sicurezza LLM <\/a>stessi<\/a>, facendo s\u00ec che le richieste aumentino la latenza di 148 e il numero di token utilizzati di 63. In altre parole, il sistema teoricamente continua a funzionare correttamente, ma la latenza nell\u2019elaborazione degli avvisi e i costi associati aumentano in modo significativo.<\/p>\n

Errore automatico pericoloso<\/h2>\n

Negli scenari basati su agenti, l\u2019esaurimento del budget non si manifesta come un errore esplicito con un messaggio \u201climite richiesta superato\u201d e un avviso immediato per le parti responsabili. In determinate configurazioni possono verificarsi scenari di \u201cguerriglia\u201d: una richiesta al modello scade, il sistema passa automaticamente a un modello pi\u00f9 economico e, di conseguenza, la qualit\u00e0 dei relativi output diminuisce e l\u2019esecuzione di agenti secondari e attivit\u00e0 periodiche smette di funzionare. Nel frattempo, il team di sicurezza potrebbe continuare a credere per ore che tutto funzioni come prima.<\/p>\n

Come controllare i costi dell\u2019IA nella cybersecurity<\/h2>\n

Il compito di gestire le spese, ovviamente, non \u00e8 semplicemente una questione di \u201cprevenzione di spese eccessive\u201d. Il settore \u00e8 gi\u00e0 caduto in questa trappola durante l\u2019implementazione SIEM: quando le aziende hanno dovuto pagare in base al volume dei dati di telemetria raccolti, hanno iniziato a limitare in modo selettivo, e non sempre efficace, la raccolta dei registri. Di conseguenza, si sono ritrovati con il rilevamento di punti ciechi. La stessa situazione potrebbe verificarsi con i token, ma pi\u00f9 velocemente e su scala pi\u00f9 ampia. Un criterio di taglio dei costi mal progettato potrebbe compromettere l\u2019approfondimento delle indagini e la qualit\u00e0 delle risposte. E in assenza di tale criterio, la decisione di tagliare qualcosa non verr\u00e0 presa dall\u2019architetto o dal CISO durante la fase di progettazione del sistema, ma dall\u2019analista di turno alle 3 di notte. In alternativa, potrebbe trattarsi di un limitatore automatico impostato dal fornitore del sistema.<\/p>\n

Alcuni semplici principi possono aiutare a evitare sforamenti dei costi prevedibili e gestire al meglio le situazioni veramente imprevedibili.<\/p>\n

Non immettere nel modello di intelligenza artificiale elementi che possono essere verificati con una query standard. <\/strong>Tutto ci\u00f2 che \u00e8 ripetitivo e noto in anticipo dovrebbe essere gestito alla vecchia maniera, con regole e query di dati. Questi possono essere sviluppati utilizzando l\u2019IA, ma devono operare in modo deterministico. Il modello deve essere utilizzato solo quando \u00e8 veramente necessaria la valutazione di una situazione ambigua.<\/p>\n

Utilizzare limiti rigorosi e avvisare in modo aggressivo gli utenti quando vengono superati. <\/strong>I limiti devono essere combinati: un limite per attivit\u00e0, un limite giornaliero e cos\u00ec via. Gli avvisi di superamento dei limiti devono raggiungere immediatamente sia gli analisti in servizio che i responsabili del sistema nel suo insieme.<\/p>\n

Decidere in anticipo cosa succede quando viene raggiunto un limite. <\/strong>Se fermarsi e risparmiare, perdendo un po\u2019 il controllo, o continuare e pagare, \u00e8 una decisione che deve essere presa prima che si verifichi un incidente.<\/p>\n

Limitare le autorizzazioni degli agenti e il set di strumenti a loro disposizione. <\/strong>Meno azioni ha accesso il sistema, pi\u00f9 efficacemente lavora su un\u2019attivit\u00e0 ristretta, minori sono le opportunit\u00e0 che ha di gonfiare i costi e meno \u00e8 probabile che venga \u201csfruttato\u201d da un estraneo.<\/p>\n

Eseguire la scansione rigorosa dei dati esterni non attendibili. <\/strong>Richieste, messaggi e commenti in entrata, nonch\u00e9 vari campi tecnici in grado di contenere testo arbitrario (record DNS, intestazioni HTTP, nomi di file) possono non solo causare prompt injection, ma anche gonfiare deliberatamente il carico di lavoro. Limitarne le dimensioni e monitorare il carico che generano.<\/p>\n

Per evitare interruzioni del servizio da parte di provider esterni e mantenere il controllo completo sui dati dell\u2019organizzazione, valutare la possibilit\u00e0 di utilizzare modelli locali distribuiti in locale<\/strong> almeno per esigenze di sicurezza delle informazioni. Sebbene questi modelli potrebbero non essere all\u2019avanguardia, la loro ristretta specializzazione e l\u2019ottimizzazione con i dati dell\u2019azienda forniranno prestazioni decenti senza errori imprevisti.<\/p>\n

In un\u2019architettura pi\u00f9 complessa, l\u2019utilizzo degli LLM pu\u00f2 essere suddiviso in diversi livelli di criticit\u00e0<\/strong>. La prima linea di difesa (routing, filtro del rumore, arricchimento dei dati) \u00e8 gestita da modelli on-premises compatti. Questo riduce significativamente la volatilit\u00e0 del budget. Il secondo livello \u00e8 costituito da un grande modello locale che gestisce il lavoro di merito: collegare gli eventi, testare ipotesi e ricostruire un quadro coerente di un incidente. Inoltre, non viene fatturato in base alla richiesta, ma il relativo throughput \u00e8 limitato; pertanto, anzich\u00e9 superare il budget, potrebbero verificarsi sovraccarichi e code di eventi. Solo i casi isolati e veramente difficili vengono inoltrati a modelli avanzati basati sul cloud, preferibilmente con l\u2019approvazione esplicita di un analista umano. In questo schema i costi variabili permangono, ma sono limitati a un ristretto numero di casi e ognuno rappresenta una scelta consapevole piuttosto che l\u2019effetto collaterale di un script eseguito durante la notte.<\/p>\n

In sostanza, tutto ci\u00f2 replica il classico modello SOC a pi\u00f9 livelli, in cui la prima riga filtra e la terza riga esamina, solo che i ruoli sono interpretati dai modelli anzich\u00e9 dalle persone.<\/p>\n\n","protected":false},"excerpt":{"rendered":"

Esaminiamo l’impatto della dipendenza dall’IA sulla cybersecurity di un’organizzazione. <\/p>\n","protected":false},"author":2722,"featured_media":31074,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[2364,2955,2956],"tags":[1516,2661,2620,638,3546,2963,3966,67,753],"class_list":["post-31073","post","type-post","status-publish","format-standard","has-post-thumbnail","category-business","category-enterprise","category-smb","tag-ai","tag-budget","tag-ia","tag-minacce","tag-ml","tag-soc","tag-soc-autonomo","tag-suggerimenti","tag-tecnologia"],"hreflang":[{"hreflang":"it","url":"https:\/\/www.kaspersky.it\/blog\/tokenomics-ai-and-cybersecurity\/31073\/"},{"hreflang":"en-in","url":"https:\/\/www.kaspersky.co.in\/blog\/tokenomics-ai-and-cybersecurity\/31131\/"},{"hreflang":"en-ae","url":"https:\/\/me-en.kaspersky.com\/blog\/tokenomics-ai-and-cybersecurity\/26165\/"},{"hreflang":"en-gb","url":"https:\/\/www.kaspersky.co.uk\/blog\/tokenomics-ai-and-cybersecurity\/30971\/"},{"hreflang":"ru","url":"https:\/\/www.kaspersky.ru\/blog\/tokenomics-ai-and-cybersecurity\/42810\/"},{"hreflang":"x-default","url":"https:\/\/www.kaspersky.com\/blog\/tokenomics-ai-and-cybersecurity\/56523\/"},{"hreflang":"ru-kz","url":"https:\/\/blog.kaspersky.kz\/tokenomics-ai-and-cybersecurity\/31135\/"},{"hreflang":"en-au","url":"https:\/\/www.kaspersky.com.au\/blog\/tokenomics-ai-and-cybersecurity\/36876\/"},{"hreflang":"en-za","url":"https:\/\/www.kaspersky.co.za\/blog\/tokenomics-ai-and-cybersecurity\/36545\/"}],"acf":[],"banners":"","maintag":{"url":"https:\/\/www.kaspersky.it\/blog\/tag\/ai\/","name":"AI"},"_links":{"self":[{"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/posts\/31073","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/users\/2722"}],"replies":[{"embeddable":true,"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/comments?post=31073"}],"version-history":[{"count":1,"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/posts\/31073\/revisions"}],"predecessor-version":[{"id":31075,"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/posts\/31073\/revisions\/31075"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/media\/31074"}],"wp:attachment":[{"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/media?parent=31073"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/categories?post=31073"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.kaspersky.it\/blog\/wp-json\/wp\/v2\/tags?post=31073"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}