Una chiave API di un modello AI finita dentro un file di tema WordPress, dentro un plugin o dentro un container non viene soltanto usata da qualcun altro: viene rivenduta, fa girare i carichi di lavoro di un attaccante a spese tue, e ogni richiesta risulta partita da te. Non è uno scenario teorico. Il report Detecting and countering misuse of AI: September 2026, pubblicato da Anthropic il 10 settembre 2026 e riferito ad attività bloccate tra dicembre 2025 e agosto 2026, elenca esattamente questi tre effetti con tre parole: loot (le chiavi rubate hanno un mercato), compute (i carichi girano sul conto della vittima), cover (l’attività viene attribuita al titolare legittimo della credenziale). Una campagna hacktivist descritta nel report ha operato per un mese interamente su chiavi rubate.
Il report è anche chiaro su dove nascono quelle chiavi: da clienti legittimi che le hanno esposte nei propri prodotti, applicazioni e codice pubblico, cioè GitHub, file di installazione di app mobili, immagini Docker, siti e chatbot. Per chi costruisce siti, questa è la frase che riguarda il lavoro di tutti i giorni.
Il criterio del confronto
La domanda operativa non è “dove sta la chiave” ma quanto dura e quanto costa l’incidente il giorno in cui esce dal tuo controllo. Su questo criterio confronto le due architetture che vedo davvero nei progetti PMI: la chiave dentro l’installazione WordPress e la chiave dietro un proxy server-side che il sito interroga.
Opzione A: la chiave dentro WordPress
È il default di quasi ogni plugin AI: costante in wp-config.php oppure campo nella pagina opzioni, quindi riga in wp_options. Messa in opera: dieci minuti, zero infrastruttura aggiuntiva, zero costo ricorrente.
Il prezzo si paga sul raggio d’azione. Quella chiave è leggibile da chiunque ottenga lettura del filesystem o del database: un plugin vulnerabile, un backup lasciato accessibile, un tema comprato su un marketplace, un accesso FTP di un fornitore che non lavora più con te. Peggio ancora se il plugin la espone lato client per chiamare il modello dal browser: lì la chiave è pubblica per definizione, e gli attaccanti descritti nel report scandagliano proprio quelle superfici in modo industriale, arrivando a scaricare gli APK dal Play Store per cercarci dentro token.
C’è poi il dettaglio che rende l’incidente lungo: quella chiave in genere è una sola e sta nello stesso posto per tutti gli usi. Revocarla significa spegnere contemporaneamente il chatbot, la generazione delle descrizioni prodotto e lo script di traduzione. Nella pratica si esita, e l’esitazione è tempo in cui il conto cresce.
Opzione B: la chiave dietro un proxy server-side
Il sito non conosce nessuna chiave: chiama un endpoint tuo, autenticato, che inoltra la richiesta al modello aggiungendo la credenziale. Messa in opera: una mezza giornata la prima volta, più un servizio da mantenere, monitorare e aggiornare.
Il vantaggio reale non è la segretezza in sé: è che il proxy è l’unico punto in cui puoi mettere un limite prima del modello. Quota per utente, whitelist dei prompt di sistema, log delle chiamate con il loro costo, kill switch che non richiede di toccare il sito. Se il sito WordPress viene compromesso, l’attaccante eredita un endpoint con un tetto, non una chiave con il plafond della tua carta.
Dove il proxy non salva nessuno
Qui va detta la parte scomoda, perché è documentata nello stesso report. Il gateway non è una zona sicura: è un bersaglio nuovo, e nel 2026 è stato colpito. Anthropic descrive più attori che hanno compromesso l’implementazione di LiteLLM di alcuni servizi wrapper, usando prompt injection per esfiltrare le chiavi di produzione conservate nei loro container cloud. L’attore tracciato come GTG-50020 ha fatto la stessa cosa contro la sandbox di valutazione automatica di un vendor AI: ottenute le chiavi di produzione, ha proseguito gli attacchi usando quelle della vittima al posto delle proprie, e una campagna successiva dalla stessa infrastruttura ha colpito circa trenta aziende AI in circa quattro giorni.
Tradotto per chi mette un proxy davanti a un sito: se quel proxy esegue prompt che arrivano da input non fidati (un form, un commento, un PDF caricato) e ha la chiave in ambiente, hai spostato il bersaglio di un piano, non lo hai tolto. Ne ho scritto in il pezzo sui caratteri invisibili nei form WordPress: l’input che arriva dal web non diventa fidato perché passa da un tuo server.
Il controllo che decide davvero: tetto e revoca
Entrambe le architetture reggono o crollano sulla stessa cosa, ed è un lavoro di console che costa cinque minuti e quasi nessuno fa.
Su Anthropic esistono i workspace: fino a 100 per organizzazione nella configurazione di default, ognuno con il proprio tetto di spesa mensile, i propri rate limit e le proprie chiavi. Archiviare un workspace disattiva e archivia ogni chiave creata al suo interno nel giro di pochi secondi, ed è irreversibile. Su OpenAI la struttura equivalente sono i progetti, con spend limit per progetto e service account dedicati invece di chiavi personali. In tutti e due i casi c’è una trappola identica: sul Default Workspace di Anthropic non si possono impostare limiti, e al progetto di default di OpenAI non si possono aggiungere membri o service account, perché eredita la configurazione dell’organizzazione.
Da qui viene la take che mi interessa più del confronto stesso: la chiave non è il perimetro, il tetto di spesa lo è. E il posto peggiore dove far girare la produzione è proprio il workspace o il progetto di default, cioè l’unico dove il tetto non si può mettere e la revoca non è chirurgica. Chi lascia tutto lì ha scelto, senza accorgersene, l’unica configurazione in cui un incidente non ha né un limite di costo né un interruttore.
Cosa farei, in ordine
Su un sito piccolo con una sola automazione, l’opzione A è accettabile a tre condizioni: chiave in una costante di wp-config.php e mai in wp_options, chiave dedicata dentro un workspace o progetto separato con tetto mensile pari a due o tre volte la spesa attesa, alert di spesa attivo. Con un chatbot esposto al pubblico, dati di clienti o più fornitori che toccano il sito, si passa all’opzione B, sapendo che il proxy va trattato come un componente di sicurezza e non come un inoltro: input separato dalle istruzioni, log, quota per chiamante.
La prova che la configurazione funziona è una sola, e si fa oggi: prendi la chiave che usa il tuo sito, archiviala dalla console e guarda quanto tempo passa prima che qualcuno se ne accorga. Se la risposta è “un mese”, il problema non era dove stava la chiave.