LLMjacking: chiavi AI rubate, servizi usati da altri e la fattura arriva a voi

Un'azienda attiva un modello AI in cloud per un progetto pilota. Lo sviluppatore che lo integra genera una chiave API, la credenziale con cui le applicazioni chiamano il modello e su cui il fornitore addebita i consumi. La chiave finisce in un file di configurazione, il file in un repository condiviso. Il pilota si chiude, la chiave resta valida. Mesi dopo arriva una fattura che nessuno sa spiegare.

È lo schema che Google Threat Intelligence Group e Mandiant, la società di sicurezza di Google, descrivono in un rapporto del 2 novembre 2026, il fenomeno noto come LLMjacking: un attaccante si procura le credenziali dei servizi AI di un'azienda e li usa, spesso rivende l'accesso ad altri, e la fattura la paga l'azienda. Mandiant scrive di aver gestito nel 2026 più casi di questo tipo.

Quanto può costare

Secondo il rapporto, in singoli casi i costi hanno superato i 100.000 dollari in un giorno, e in alcune aziende hanno raggiunto in tutto un milione di dollari prima che l'accesso venisse scoperto e revocato. In un caso sono state fatte più di 500.000 richieste ai modelli in meno di otto ore.

La velocità è la differenza rispetto ad altri abusi del cloud, che consumano risorse un po' alla volta: qui la spesa può esplodere in poche ore.

La soluzione: tre decisioni da prendere prima

Il rischio non sta nell'intelligenza artificiale. Sta in tre decisioni che un'azienda prende già per il resto del cloud e che per i servizi AI, attivati spesso in fretta, nessuno ha ancora preso.

Quanto si può spendere. Ogni servizio AI deve avere un tetto ai consumi, cioè un numero massimo di richieste, e un avviso quando la spesa supera una soglia. Attenzione: in molti cloud l'avviso di spesa avvisa ma non ferma nulla. Quello che ferma i consumi è il tetto alle richieste.

Chi tiene le chiavi. Le chiavi stanno in un archivio protetto, fatto apposta, non nei file dei programmi né nei documenti condivisi. Si cambiano a intervalli regolari, così una chiave finita in mani sbagliate smette presto di funzionare. Ogni chiave serve a uno scopo preciso: una chiave per le prove non apre i modelli più costosi. E una chiave pubblicata per errore va disattivata subito: cancellare il file non basta, perché può essere già stata copiata.

Chi controlla. Ogni persona e ogni programma ha solo gli accessi che gli servono. Gli accessi alle console del cloud sono protetti da un secondo fattore che resiste al phishing, come una chiavetta di sicurezza. I log delle attività restano accesi e c'è una persona incaricata di guardarli: l'attivazione di un servizio AI che nessuno ha chiesto è un allarme, non una curiosità.

Come entrano

Secondo il rapporto, la via d'ingresso più frequente sono credenziali cloud esposte o rubate: credenziali IAM, chiavi di service account, Personal Access Token (PAT) di GitHub, token di sessione attivi. Un'altra sono gli endpoint dei modelli lasciati aperti su Internet. Fra i casi descritti:

• Chiavi API in repository pubblici. Un gruppo ha raccolto chiavi API aziendali dei modelli da repository pubblici su GitHub e le ha validate in automatico con richieste da un solo token (max_tokens=1): abbastanza per sapere se la chiave funziona, troppo poco per far scattare gli allarmi sui volumi di EDR e SIEM.
• Chiave di service account configurata male. Nel 2026 il gruppo che Google chiama UNC6993 è entrato in un'istanza cloud con la chiave di un service account configurato male, e da lì si è concesso l'accesso alle API di un modello.
• Furto del token di sessione. Lo stesso gruppo ha messo online una pagina che si presentava come il portale per entrare in un gruppo di utenti di un servizio LLM. La pagina mandava l'utente sul sito vero del servizio e gli chiedeva di incollare il JSON con il token di accesso della sua sessione attiva. Con quel token gli attaccanti aggiravano password e autenticazione a più fattori.
• Credenziali IAM e token di federazione. Un altro attore ha usato credenziali IAM compromesse di utenti aziendali e token di federazione per generare via codice nuove chiavi di accesso, aggirando l'obbligo di MFA.
• PAT di GitHub e vulnerabilità applicativa. Un altro ancora è entrato combinando un PAT rubato, che gli apriva i repository privati, con una probabile vulnerabilità di un'applicazione web in un ambiente cloud a container.
• Endpoint Ollama esposti. Server Ollama raggiungibili da Internet sono stati sondati con uno script automatico che chiamava l'endpoint /api/create, per registrare e far girare i propri modelli sull'infrastruttura altrui.

Una volta dentro, gli attaccanti non si sono limitati a usare l'AI. Hanno cercato altre password nel codice e negli archivi, hanno creato utenze nascoste (una si spacciava per uno strumento interno di controllo dei costi), hanno provato ad attivare altri servizi, uno di loro ha acceso macchine con GPU, fra le più costose del cloud. In un caso un secondo gruppo ha ottenuto da chi aveva fatto il primo accesso chiavi virtuali già verificate di un gateway LiteLLM, e ha sfruttato una vulnerabilità dell'endpoint /key/regenerate (CVE-2026-40217) per trasformarle in credenziali di amministrazione del proxy (PROXY_ADMIN): il controllo completo del gateway. Il danno quindi non è solo la fattura: chi entra per usare l'AI può trovare anche codice, password e dati.

Poi l'accesso viene rivenduto. Google descrive servizi che mettono insieme chiavi rubate a più aziende e le vendono come abbonamenti: uno offriva un piano «illimitato» per circa 60 dollari al mese. Secondo Google, chi lo alimentava è lo stesso attaccante delle 500.000 richieste in otto ore, e ha scaricato su una sola azienda quasi un milione di dollari di costi.

Che cosa vale per una PMI

Non serve un grande progetto di intelligenza artificiale per essere esposti. Basta una chiave creata per una prova, un account cloud aperto per un pilota, uno strumento installato da uno sviluppatore senza dirlo a nessuno. Gli strumenti attivati in fretta, fuori da ogni elenco, sono proprio quelli che nessuno controlla, e Google raccomanda di cercarli attivamente.

Il primo passo è quindi un elenco: quali servizi AI sono attivi, quali chiavi esistono, chi le usa, dove sono salvate e quale tetto le limita. Le chiavi create per prove e progetti pilota, mai cambiate e senza tetto, sono quelle da controllare per prime.

Aggiornato al 10 novembre 2026. Fatti e cifre sono riportati come descritti nel rapporto di Google Threat Intelligence Group e Mandiant; le traduzioni dall'inglese sono a cura dell'autore. Articolo informativo, non consulenza tecnica sul caso specifico.