TL;DR: se la chiave del tuo provider AI sta nel campo impostazioni di un plugin, sta nel database. Quindi sta anche in ogni backup, in ogni copia di staging e in ogni dump che hai passato a qualcuno. Spostala in wp-config.php e ruotala.

Il problema: la chiave si moltiplica insieme al database

Installi un plugin AI su WordPress, incolli la chiave del provider nel campo delle impostazioni, tutto funziona. Quel campo è quasi sempre un’opzione WordPress, e le opzioni stanno tutte nella tabella wp_options: è la definizione stessa della Options API.

Da quel momento la chiave non è più in un posto solo. È nel backup notturno, nella copia di staging che nessuno cancella, nel dump che hai mandato all’agenzia per una consulenza, nell’export che il cliente si è scaricato prima di cambiare hosting. Nessuna di queste è un’anomalia: sono operazioni normali di manutenzione. Il punto è che il segreto viaggia insieme ai contenuti, e i contenuti si copiano per mestiere.

Una chiave AI, poi, non è una credenziale come le altre: è consumo a contatore. Chi la trova non deve bucare niente. Gli basta fare richieste, sul tuo account.

La soluzione: una costante in wp-config.php

wp-config.php è il file di configurazione di WordPress e non entra nel dump del database. Definisci lì la chiave, sopra la riga /* That's all, stop editing! */:

define( 'LR_AI_API_KEY', 'la-chiave-nuova' );

Poi serve che il codice la legga da lì. Prima di scrivere qualcosa, cerca nella documentazione del plugin il nome di una costante o di un filtro: diversi plugin AI lo prevedono proprio per questo scenario. Se invece la chiamata all’API la fai tu, la lettura è una riga sola:

$key = defined( 'LR_AI_API_KEY' ) ? LR_AI_API_KEY : '';

I passaggi essenziali

  1. Ruota la chiave dal pannello del provider. Quella vecchia è già dentro i backup esistenti: spostarla non la richiama indietro. Ne generi una nuova e revochi la precedente.
  2. Metti la nuova chiave in wp-config.php, sopra “stop editing”, e controlla che il file non sia leggibile dall’esterno.
  3. Svuota il campo nelle impostazioni del plugin e verifica che nel database non sia rimasto niente.
  4. Prova una chiamata reale dal sito, non solo il pulsante “test connessione” del plugin: quello a volte legge ancora il valore in cache.

Per il punto 3, se hai WP-CLI, la verifica è diretta:

wp db query "SELECT option_name FROM $(wp db prefix)options
  WHERE option_value LIKE '%sk-%';"

Due dettagli che fanno la differenza fra un controllo e un placebo. Il prefisso della tabella lo chiedi a WP-CLI invece di scrivere wp_: se il sito è stato installato con un prefisso personalizzato, la query scritta a mano fallisce con “table doesn’t exist” e sembra un risultato vuoto. E il pattern non è ancorato all’inizio del valore, perché quasi tutti i plugin salvano le impostazioni in un’unica opzione serializzata: la chiave sta in mezzo alla stringa, non al primo carattere.

La rete è larga di proposito e prende anche qualche falso positivo. Va bene: quello che ti interessa è la colonna option_name, e leggerla ti dice quanti plugin conservavano una copia di una chiave che credevi di avere in un posto solo.

L’errore da evitare

Spostare la chiave senza ruotarla. È mezzo lavoro fatto con la soddisfazione di averlo finito: il valore vecchio resta valido in ogni copia del database già esistente, e quelle copie non le controlli più. L’altro errore, più banale e più frequente, è mettere wp-config.php sotto versionamento. Vale la stessa regola che OpenAI mette nero su bianco nelle sue linee guida: la chiave non si committa in un repository, nemmeno privato.

Take finale

Un segreto va tenuto dove non si copia per lavoro. Il database si copia per lavoro tutti i giorni, il file di configurazione quasi mai: è tutta qui la differenza, e non richiede nessuno strumento nuovo. È lo stesso criterio con cui conviene partire dalle automazioni AI read-only o farsi dare dall’AI una patch invece di un file intero: prima si riduce il danno possibile, poi si aggiunge comodità.

Fonti