L’avvertimento di Google sul LLM-jacking rivela un mercato nero dell’accesso AI rubato

Google ha avvertito che gli attacchi di LLM-jacking sono in forte aumento, mentre i criminali rubano sempre più spesso account AI, credenziali API e capacità cloud aziendale.

Secondo quanto riportato, venditori nei circuiti clandestini pubblicizzano accessi non autorizzati a modelli di Google, Anthropic e OpenAI con sconti fino al 97%. Questa cifra descrive inserzioni osservate nei marketplace, non un prezzo medio di transazione verificato in modo indipendente.

La conclusione più importante va oltre il titolo. L’accesso all’AI è diventato un bene criminale scambiabile, al pari di carte di pagamento rubate, account cloud e connessioni proxy residenziali.

Google Threat Intelligence Group afferma di aver osservato un numero maggiore di acquirenti e venditori di account AI nel corso del 2026. La domanda si è concentrata sulle credenziali di Claude e Gemini, insieme a prodotti di coding AI come Cursor Pro e Devin.

Non si tratta semplicemente di frode sugli abbonamenti. Gli aggressori possono rubare una chiave API o un’identità cloud, instradare le richieste attraverso l’account di un’altra azienda e lasciare alla vittima la responsabilità dell’attività.

L’esposizione che ne deriva combina consumi imprevisti, fuga di dati, interruzione dei servizi e uso criminale di infrastrutture affidabili. Mette inoltre in difficoltà i programmi di sicurezza che continuano a trattare la spesa per l’AI come un budget software anziché come una risorsa di calcolo controllata.

Le precedenti campagne di dirottamento delle risorse puntavano di solito al mining di criptovalute o alla capacità proxy. Il LLM-jacking reindirizza la stessa logica economica verso l’inferenza dei modelli, gli agenti per sviluppatori e l’infrastruttura necessaria per farli funzionare.

Il conflitto è quindi più ampio di quello tra criminali e fornitori di AI. Si tratta di accesso rubato contro controllo aziendale, con ogni chiave non tracciata o carico di lavoro con privilegi eccessivi che amplia l’offerta del mercato.

Cosa dice realmente l’avvertimento di Google sul LLM-jacking

Le prove di Google mostrano che i criminali stanno costruendo una filiera attorno all’accesso AI compromesso, non semplicemente sperimentando con singoli account rubati.

Il tracker delle minacce AI di settembre 2026 dell’azienda descrive un aumento del furto, dell’esfiltrazione e della vendita di account AI nelle comunità del cybercrime.

Google afferma che nel 2026 un numero maggiore di identità nei circuiti clandestini ha cercato account legati all’AI. Ha inoltre osservato più venditori che pubblicizzavano tali account rispetto all’anno precedente.

Secondo i post monitorati da Google, i prezzi medi per account nei marketplace sono più che raddoppiati nel corso del 2026. Tale aumento suggerisce una crescita della domanda, anche se alcune singole inserzioni promettevano sconti estremi.

L’apparente contraddizione ha senso in un mercato illecito. Gli acquirenti attribuiscono valore all’accesso perché l’inferenza legittima e il calcolo ad alte prestazioni richiedono risorse scarse e fatturabili.

Un account rubato può trasferire tali costi alla vittima. Un venditore può quindi offrire prezzi inferiori all’accesso legittimo senza gestire un’infrastruttura comparabile.

Le segnalazioni di sconti fino al 97% sembrano descrivere le offerte clandestine più aggressive. Il rapporto pubblico di Google non stabilisce tale percentuale come media dell’intero mercato.

Inoltre, non divulga un numero totale di vittime, una perdita finanziaria aggregata o un volume di transazioni verificato. Queste omissioni limitano ogni tentativo di misurare le dimensioni complete del mercato.

Tuttavia, l’attività di fondo è documentata in modo più solido rispetto alla percentuale riportata nel titolo. Google ha osservato un aumento della domanda, furti mirati di credenziali e compromissioni cloud a supporto di carichi di lavoro AI non autorizzati.

L’azienda chiama la versione infrastrutturale “LLMJacking.” Il termine comprende il dirottamento di risorse cloud aziendali per eseguire modelli AI o consumare servizi di modelli ospitati senza autorizzazione.

Google identifica anche metodi di acquisizione degli account che vanno oltre il furto diretto. Gli attori delle minacce utilizzano registrazioni automatizzate, pooling di account, relay proxy e middleware che aggrega più chiavi.

Questi sistemi possono distribuire le richieste tra gli account e nasconderne l’origine. Possono inoltre sostituire le credenziali disabilitate senza modificare l’interfaccia dell’acquirente.

Questa struttura trasforma l’accesso compromesso in un servizio. Gli acquirenti non devono sapere quale organizzazione paga la fattura sottostante.

Secondo quanto riportato, il mercato include credenziali per account AI rivolti ai consumatori, assistenti di coding e API di modelli. Tali risorse differiscono significativamente per ciò che possono esporre.

Un account chat rubato può rivelare la cronologia delle conversazioni e i documenti caricati. Una credenziale API può fornire accesso programmabile a una quota, a un modello o a un progetto cloud connesso.

Un’identità cloud compromessa presenta il rischio più ampio. Può consentire a un intruso di predisporre infrastruttura, individuare credenziali archiviate o raggiungere servizi aziendali adiacenti.

L’avvertimento di Google collega questi livelli in un’unica economia. Gli account rubati forniscono accesso immediato, mentre l’infrastruttura compromessa offre capacità di calcolo durevole.

Questa combinazione spiega perché la minaccia conta oltre un singolo fornitore. Google, Anthropic e OpenAI competono per clienti legittimi, ma i criminali possono scambiare l’accesso a tutti e tre come inventario intercambiabile.

Perché l’accesso AI è diventato un prezioso inventario criminale

L’ascesa del LLM-jacking riflette un cambiamento economico fondamentale: l’accesso ai modelli offre ora capacità di calcolo utile e scalabile che i criminali non vogliono finanziare direttamente.

I gruppi criminali rubano da tempo infrastruttura quando la risorsa sottratta può generare entrate. Il mining di criptovalute ha reso preziosi i processori compromessi perché la potenza di calcolo si traduceva direttamente in asset digitali.

Il proxyjacking ha creato un altro mercato instradando il traffico attraverso i sistemi delle vittime. Gli aggressori potevano vendere banda e indirizzi residenziali o aziendali dall’aspetto affidabile.

Il LLM-jacking estende questo modello all’inferenza. La risorsa rubata è la capacità di inviare prompt, generare output, gestire agenti o eseguire modelli su hardware dirottato.

MITRE classifica questo comportamento più ampio come resource hijacking. Il suo framework include l’abuso di calcolo, banda, messaggistica e servizi cloud.

L’AI rende l’opportunità più flessibile. Una sola credenziale può supportare generazione di codice, ricognizione, produzione di contenuti, traduzione, preparazione di phishing o un flusso di lavoro offensivo automatizzato.

La stessa credenziale può inoltre fornire accesso a limiti o capacità più elevati, non disponibili tramite un account gratuito anonimo. Questa differenza conta quando un’operazione dipende da un’automazione continuativa.

Google afferma che l’accesso premium e il calcolo ad alte prestazioni rimangono ostacoli importanti per gli aggressori. Rubare tali risorse abbassa la barriera senza richiedere ai criminali di costruire una piattaforma AI.

Il mercato può servire diversi tipi di acquirenti. Alcuni desiderano un accesso economico ai modelli generalisti, mentre altri cercano account che tollerino un utilizzo ad alto volume o in violazione delle policy.

I gruppi più capaci possono collegare l’accesso rubato a sistemi di orchestrazione. Questi sistemi selezionano automaticamente gli account, ruotano gli endpoint, ritentano le richieste fallite e distribuiscono il lavoro.

La ricerca sulle minacce di Google del maggio 2026 ha documentato relay proxy e pipeline di registrazione automatizzata utilizzati per industrializzare l’accesso a modelli commerciali.

Il rapporto ha descritto browser anti-detect, pool di account e middleware personalizzato progettati per eludere vincoli di fatturazione o controlli delle piattaforme. Questi meccanismi riducono la dipendenza da una singola credenziale.

Complicano inoltre l’attribuzione. Il traffico che raggiunge un fornitore può passare attraverso relay e progetti compromessi prima di produrre altrove un risultato dannoso.

Per una vittima aziendale, il primo segnale evidente potrebbe essere un consumo anomalo del modello. Eppure, l’aggressore potrebbe essere entrato attraverso un dispositivo di sviluppo giorni prima.

Un infostealer, ovvero un malware progettato per raccogliere credenziali e dati di sessione, può cercare nei file locali informazioni di configurazione AI. Può quindi esportare tutto ciò che risulta utile al proprio controllore.

Google ha osservato controllori di ACRSTEALER prendere di mira archivi di configurazione associati a Cline e Continue AI. Tali file possono contenere chiavi API in chiaro o endpoint di instradamento personalizzati.

Questo dettaglio rende particolarmente importanti gli ambienti AI per sviluppatori. Gli assistenti di coding si trovano spesso vicino a repository di codice sorgente, registri di pacchetti, terminali e strumenti cloud.

Una credenziale rubata da tale ambiente può offrire più del solo accesso ai modelli. Può aiutare gli aggressori a mappare lo stack di sviluppo o a individuare una via d’accesso ai sistemi di produzione.

Il mercato in crescita mette quindi sotto pressione contemporaneamente i responsabili della sicurezza, i manager dell’ingegneria e i team finanziari cloud. Ogni gruppo vede un frammento diverso dell’incidente.

La sicurezza vede un’identità compromessa. L’ingegneria vede richieste fallite o quote esaurite. La finanza vede consumi inspiegabili dopo che l’accesso è già stato monetizzato.

Senza un monitoraggio condiviso, questi frammenti potrebbero non diventare mai un unico incidente. Il mercato nero beneficia di tale ritardo organizzativo.

L’avvertimento di Google sul LLM-jacking mette sotto pressione i controlli delle identità

Il problema centrale non è che i modelli siano improvvisamente diventati facili da violare. Gli aggressori stanno rubando le identità e l’infrastruttura che li circondano.

La ricerca di Google distingue gli attacchi alle risorse AI dalle compromissioni riuscite dei modelli di frontiera stessi. L’attività osservata si concentra soprattutto su credenziali, connettori, configurazioni per sviluppatori, progetti cloud e livelli di orchestrazione.

Questa distinzione conta perché i controlli di sicurezza dei modelli non possono revocare una chiave aziendale divulgata. Non possono neppure correggere un ruolo di identità che concede accesso non necessario in un ambiente cloud.

Una credenziale bearer consente al suo detentore di agire con i permessi assegnati alla credenziale. Il sistema potrebbe non sapere se la richiesta provenga dal proprietario o da un ladro.

Le chiavi API a lunga durata rendono questa debolezza più difficile da gestire. Spesso sopravvivono a cambiamenti del personale, prototipi abbandonati e migrazioni tra fornitori di AI.

Gli sviluppatori possono copiarle nei file di configurazione locali per comodità. Gli strumenti automatizzati possono inoltre generare chiavi senza inserirle in un inventario di sicurezza consolidato.

Il risultato è la proliferazione delle credenziali. Le organizzazioni sanno quali strumenti AI hanno approvato, ma non necessariamente quali identità, chiavi, estensioni e agenti locali possono accedervi.

Il LLM-jacking trasforma questa lacuna di governance in inventario per i criminali. Ogni credenziale riutilizzabile diventa un potenziale prodotto.

La sfida per la sicurezza cresce quando le organizzazioni collegano i modelli ai dati interni. Un assistente AI può avere accesso a codice sorgente, documenti tecnici, registri di assistenza o discussioni sui progetti.

Se un intruso ruba la sessione dell’assistente, l’incidente potrebbe esporre conversazioni archiviate o risorse connesse. Se l’aggressore ruba solo una chiave API, l’esposizione diretta dei dati dipende dai suoi permessi.

Questi scenari non dovrebbero essere ridotti a un’unica affermazione. Una chiave compromessa non concede automaticamente accesso a ogni prompt o sistema interno.

Tuttavia, i team non dovrebbero nemmeno presumere che l’uso non autorizzato generi soltanto un problema di fatturazione. Log, output dei modelli, strumenti connessi e contesto applicativo possono tutti contenere informazioni sensibili.

Il rischio diventa più acuto con gli agenti. Un agente può richiamare strumenti, recuperare documenti, eseguire azioni approvate e preservare il contesto operativo lungo un flusso di lavoro.

Queste capacità sono utili perché riducono il lavoro manuale. Sono pericolose quando l’identità sottostante non dispone di permessi limitati e di piste di audit affidabili.

Google ha riferito che gli attaccanti si stanno muovendo verso operazioni agentiche con minori ritardi umani. In un caso del secondo trimestre, una risorsa cloud compromessa ha sostenuto una campagna di raccolta massiva di credenziali in meno di sei ore.

Quell'esempio non dimostra che ogni account AI rubato alimenterà un attacco autonomo. Mostra perché le lente catene di approvazione manuale non possono restare l'unico meccanismo difensivo.

Le aziende devono sapere quali identità possono utilizzare i modelli, quali applicazioni ne sono titolari e quale sia un consumo normale. Devono inoltre disporre di un metodo rapido per sospendere l'accesso.

Questo richiede coordinamento oltre il centro operativo di sicurezza. I team di piattaforma devono rendere osservabili le credenziali, mentre quelli di approvvigionamento devono collegare le fatture a proprietari e carichi di lavoro specifici.

Gli sviluppatori necessitano anche di percorsi approvati per l'archiviazione e la rotazione che restino pratici. Se il processo sicuro crea troppi attriti, le alternative locali non gestite continueranno a diffondersi.

Il vincitore di questo conflitto non sarà l'azienda con la policy di utilizzo accettabile più lunga. Sarà quella in grado di identificare, limitare e revocare rapidamente l'accesso all'AI.

La catena di attacco inizia prima del primo prompt sospetto

L'LLM-jacking di solito riesce attraverso il furto di credenziali e l'abuso del cloud, per poi usare il consumo AI come livello di monetizzazione.

Un percorso comune inizia su una workstation di sviluppo. Phishing, software malevolo, un pacchetto compromesso o un'estensione browser ingannevole possono distribuire un infostealer.

Il malware cerca nei browser, nelle directory di configurazione, nelle cronologie dei comandi, nei file di ambiente e negli archivi delle applicazioni. Gli strumenti di sviluppo AI creano ulteriori bersagli perché molti richiedono credenziali per i modelli.

Una volta rubata, una chiave può essere testata automaticamente. Gli operatori criminali possono identificarne il provider, la quota disponibile, le restrizioni e verificare se la credenziale funziona ancora.

Le credenziali utili possono essere vendute direttamente o caricate in un relay. Un relay accetta richieste dai clienti e le inoltra attraverso uno o più account compromessi.

Il cliente vede un endpoint di servizio stabile. Dietro le quinte, l'operatore può sostituire una credenziale revocata, distribuire il consumo o instradare carichi di lavoro specifici verso modelli diversi.

Questa separazione protegge l'acquirente dall'instabilità dei singoli account rubati. Consente inoltre al venditore di monetizzare una raccolta di credenziali presso molti clienti.

La compromissione del cloud crea un altro percorso. Gli attaccanti possono ottenere un'identità che consente loro di attivare servizi per modelli o distribuire infrastrutture autogestite.

Possono quindi utilizzare l'inferenza ospitata attraverso il progetto della vittima. In alternativa, possono usare capacità di calcolo rubata per eseguire direttamente un modello.

La società di sicurezza Sysdig ha coniato il termine LLMjacking nel 2024 per l'uso di credenziali cloud rubate per consumare servizi di modelli a pagamento. La sua successiva ricerca sull'LLMjacking descrive un'evoluzione verso carichi di lavoro agentici offensivi.

I modelli autogestiti creano un'esposizione correlata. Un server di inferenza accessibile da Internet e privo di autenticazione può offrire capacità gratuita a chiunque lo scopra.

Questo percorso non richiede una chiave API rubata. La debolezza risiede in un servizio esposto e in controlli di rete inadeguati.

Il risultato può comunque assomigliare all'LLM-jacking, perché un soggetto esterno consuma l'infrastruttura AI di un'organizzazione. Tuttavia, la correzione differisce da un'indagine sul furto di account.

I team devono distinguere almeno tre tipi di incidente: sessioni utente compromesse, credenziali di modelli rubate e infrastruttura cloud o autogestita dirottata.

Il furto di sessione richiede la revoca dell'account, l'indagine sul dispositivo e la revisione dei contenuti esposti. Il furto di chiavi API richiede la rotazione delle chiavi, l'analisi dei log e la convalida delle autorizzazioni associate.

La compromissione dell'infrastruttura richiede una risposta agli incidenti più ampia. Gli investigatori devono stabilire come sia entrato l'attaccante, quali risorse siano state create e se resti una persistenza.

Le anomalie di consumo possono rivelare tutti e tre i casi, ma da sole non sono sufficienti. Anche il lancio legittimo di un prodotto può creare improvvisamente traffico verso i modelli.

Un rilevamento utile combina volume, identità, geografia, tempistiche, selezione del modello e comportamento dell'applicazione. Un carico di lavoro che cambia più dimensioni contemporaneamente merita una revisione rapida.

I team dovrebbero anche monitorare le richieste respinte dai controlli di sicurezza. Questi eventi possono indicare abusi, sebbene attaccanti sofisticati possano usare attività innocue o i propri modelli.

I controlli migliori riducono sia la probabilità sia l'impatto. Le credenziali a breve durata riducono la finestra temporale, mentre le identità specifiche per carico di lavoro limitano ciò che una credenziale rubata può raggiungere.

Le restrizioni di rete possono bloccare l'uso da ambienti inattesi. Quote e limiti di consumo possono rallentare l'abuso mentre chi risponde indaga.

Nessuno di questi controlli offre certezza. Insieme, rendono l'accesso rubato meno affidabile e quindi meno prezioso per i venditori clandestini.

Cosa non dimostra l'affermazione di uno sconto del 97%

Lo sconto eclatante è un utile segnale d'allarme, ma non misura le dimensioni effettive del mercato, la sua affidabilità o il suo impatto finanziario.

Un annuncio clandestino non equivale a una vendita conclusa. I venditori possono esagerare la qualità dell'accesso, il tipo di account, la quota residua o la durata prima della revoca.

Il prodotto pubblicizzato potrebbe inoltre differire dall'accesso legittimo. Gli acquirenti potrebbero ricevere un proxy condiviso, una sessione browser o un account di breve durata invece di un abbonamento trasferibile.

Questa distinzione modifica il calcolo dello sconto. Confrontare un relay criminale instabile con un accesso affidabile e supportato può produrre una percentuale fuorviante.

La cifra inoltre non rivela chi abbia assorbito il consumo sottostante. Parte dell'accesso può provenire da credenziali rubate, mentre altre offerte possono sfruttare prove gratuite o la creazione automatizzata di account.

Google ha documentato tutti questi percorsi di acquisizione. Le evidenze pubbliche non assegnano una percentuale del mercato a ciascuno di essi.

Il rapporto non stabilisce neppure che gli attaccanti abbiano violato l'infrastruttura centrale dei modelli di Google, Anthropic o OpenAI. Il mercato osservato dipende in gran parte da clienti compromessi e dagli ecosistemi degli account.

Questa sfumatura dovrebbe orientare la risposta. Le aziende non possono attendere che i provider risolvano ogni caso, perché molte vulnerabilità esistono nelle identità e nei dispositivi gestiti dai clienti.

I provider mantengono comunque una responsabilità significativa. Possono rilevare la condivisione di account, relay sospetti, schemi d'uso impossibili e abusi coordinati nella registrazione sulle loro piattaforme.

Google afferma di usare la threat intelligence per rafforzare le salvaguardie e disabilitare progetti o account malevoli. Questa applicazione delle regole può aumentare il costo di mantenere un servizio clandestino.

L'azione dei provider introduce però un'altra incertezza. Un blocco automatico aggressivo può interrompere infrastrutture condivise legittime o team di sviluppo distribuiti a livello globale.

I sistemi di sicurezza necessitano quindi di evidenze che vadano oltre un singolo picco di traffico. Devono distinguere rapidamente tra il lancio di un prodotto, un'applicazione configurata erroneamente e una credenziale rubata.

L'assenza di dati aggregati sulle perdite limita anche i confronti con ransomware, cryptojacking e altre minacce cloud. L'LLM-jacking potrebbe essere diffuso pur generando perdite modeste per vittima.

È possibile anche il modello opposto. Un numero minore di compromissioni cloud potrebbe generare un'esposizione grave perché l'identità rubata raggiunge dati e infrastrutture di valore.

La telemetria di Google rappresenta un ulteriore limite. Offre forte visibilità sul proprio ecosistema e sul lavoro di risposta agli incidenti, ma non su ogni provider o transazione clandestina.

La ricerca indipendente aiuta a confermare il modello di attacco. Non può comunque trasformare osservazioni frammentate in una stima completa del mercato globale.

La conclusione difendibile è più circoscritta e più utile. Esiste una domanda criminale, i venditori stanno rispondendo e l'accesso AI rubato ha ora un percorso di monetizzazione ripetibile.

Questa conclusione non richiede di accettare ogni inserzione del dark web al valore nominale. Richiede di trattare le credenziali AI come asset che gli attaccanti cercano attivamente.

Una lettura scettica rafforza dunque la lezione operativa. I team dovrebbero rispondere a meccaniche di attacco verificate, non costruire policy attorno a un solo dato promozionale di un venditore illecito.

Tre segnali mostreranno se l'LLM-jacking continuerà a crescere

La prossima fase diventerà visibile attraverso il targeting da parte dei credential stealer, l'applicazione delle regole da parte dei provider e le anomalie di consumo aziendale.

Il primo segnale è se gli infostealer amplieranno il loro targeting ai file di configurazione AI. Google ha già osservato controller malware alla ricerca di segreti specifici di assistenti alla programmazione.

Nuove regole rivolte ad agenti aggiuntivi, router di modelli e strumenti locali per sviluppatori indicherebbero che gli attaccanti continuano a trovare lì credenziali preziose.

I team di sicurezza dovrebbero quindi esaminare i rilevamenti sugli endpoint alla ricerca di ricerche insolite nelle directory di configurazione. Dovrebbero inoltre inventariare le applicazioni che memorizzano localmente credenziali per modelli.

Il secondo segnale è l'applicazione delle regole da parte dei provider. Occorre osservare le comunicazioni su pool di account disabilitati, reti di relay smantellate, controlli di registrazione più rigidi e opzioni di autenticazione più limitate.

Una maggiore applicazione delle regole confermerebbe che i provider rilevano abusi coordinati su una scala significativa. Potrebbe anche spingere i criminali verso modelli autogestiti e la compromissione diretta del cloud.

Questo spostamento conta. Bloccare gli account consumer rubati non elimina la domanda di capacità di calcolo a basso costo.

Il terzo segnale è la telemetria aziendale. Aumenti inspiegabili nelle richieste di inferenza, nuovo utilizzo di modelli, aree geografiche sconosciute o consumo al di fuori delle finestre di distribuzione possono esporre accessi compromessi.

Il modello MITRE per il dirottamento di servizi cloud raccomanda di cercare cambiamenti improvvisi nelle risorse e consumo non autorizzato di servizi. I team AI possono adattare questa logica a token, richieste, endpoint e famiglie di modelli.

Le linee guida di Google sulle chiavi API raccomandano restrizioni, monitoraggio dell'utilizzo, chiavi isolate, rotazione periodica e autenticazione più forte dove disponibile.

I team dovrebbero tradurre questi principi in regole di proprietà. Ogni credenziale per modelli necessita di un'applicazione nominata, un team responsabile, un ambiente approvato e un percorso di revoca documentato.

Evitate di condividere una sola chiave tra persone e carichi di lavoro. Credenziali separate creano migliori tracce di audit e riducono la portata di una singola compromissione.

Non conservate segreti di produzione in repository, notebook, codice accessibile dal browser o file locali gestiti in modo approssimativo. Usate un archivio di segreti gestito e automatizzate la distribuzione delle credenziali.

Preferite credenziali di identità a breve durata dove i provider le supportano. Una credenziale temporanea offre agli attaccanti meno tempo per testare, confezionare e rivendere l'accesso.

Impostate avvisi di consumo a livello di carico di lavoro, non solo per l'account cloud complessivo. La fatturazione aggregata può nascondere abusi all'interno della normale crescita aziendale.

Monitorate le richieste respinte e i cambiamenti bruschi nella selezione dei modelli. Un'applicazione compromessa che richiama improvvisamente modelli diversi può rivelare la sperimentazione di un attaccante.

Limitate quali servizi, applicazioni, reti e metodi ciascuna identità può utilizzare. Il privilegio minimo trasforma una chiave rubata da credenziale master in un asset limitato.

Esaminate gli strumenti connessi all'AI con la stessa disciplina applicata ai repository di codice sorgente e alle console cloud. Gli agenti possono ereditare autorizzazioni sensibili attraverso connettori che i team trascurano.

Mantenete un playbook di risposta agli incidenti per le credenziali AI. Dovrebbe includere revoca, conservazione dei log, ispezione degli endpoint, notifica al provider e verifiche dell'accesso cloud adiacente.

Una base di conoscenza tecnica ricercabile può aiutare i team a conservare registri di proprietà e procedure di risposta. Non dovrebbe mai contenere segreti attivi.

L’avvertimento di Google sul LLM-jacking cambia la domanda che le aziende dovrebbero porsi. Il problema non è più se i criminali attribuiscano valore all’accesso all’AI, perché il mercato clandestino dimostra che lo fanno.

La domanda pratica è se la vostra organizzazione sia in grado di identificare ogni credenziale che raggiunge un modello, rilevare utilizzi anomali e revocare l’accesso prima che diventi merce di scambio.

Verificate ora queste credenziali. Assegnate un responsabile a ogni chiave ancora attiva, rimuovete gli accessi abbandonati e testate il processo di revoca in condizioni realistiche.