I 4 pericoli del client AI di WordPress

Il 22 ottobre ho portato al WordPress Meetup di Padova il talk «I pericoli del nuovo Client AI di WordPress», la versione aggiornata di quello che avevo presentato online al WordPress Meetup Milano il 16 giugno, e prepararlo mi ha costretto a rifare i conti con il client AI di WordPress cinque mesi dopo l’uscita della versione 7.0.

Non è un articolo contro l’AI, che uso ogni giorno: è il lato «cosa può andare storto», quello su cui voglio concentrarmi. I pericoli del client AI di WordPress che racconto nel talk sono quattro, e per ciascuno trovi i numeri aggiornati a fine ottobre e qualche suggerimento per limitare la superficie di attacco.

Cosa è cambiato da giugno

Per il client AI di WordPress poche novità nel core, molte nel plugin AI e una superficie d’attacco nuova: gli agenti che entrano nel sito con le abilities.

Le release 7.0.x uscite tra luglio e agosto non toccano l’AI: sono correzioni e aggiornamenti di sicurezza, alcuni molto seri (la 7.0.2 chiudeva una catena che arrivava all’esecuzione di codice da remoto), quindi il primo consiglio del talk resta il più noioso, cioè aggiornare. La 7.1 «Mary Lou» del 19 agosto lavora soprattutto sull’Abilities API, con nuovi filtri sul ciclo di esecuzione e un’action pensata per l’audit, mentre l’AI Client riceve solo ritocchi.

La real-time collaboration, che doveva essere la stella della fase 3 di Gutenberg, è stata tolta dalla 7.0, non è arrivata nella 7.1 e non è prevista nemmeno nella 7.2, che uscirà a inizio dicembre. Le novità sull’intelligenza artificiale vivono invece quasi tutte nel plugin AI ufficiale, che oggi conta oltre 60.000 installazioni e resta fuori dal core finché non dimostra un’adozione reale: è una scelta prudente, che però conferma il sospetto del mio articolo di maggio sulle priorità di WordPress.

Come funziona il client AI di WordPress

Il client AI di WordPress è un’interfaccia unica nel core: i plugin chiedono «genera questo testo» e WordPress smista la richiesta al modello configurato.

I pezzi sono tre. L’AI Client è l’interfaccia comune che i plugin usano per parlare con i modelli; i Connettori sono la schermata dove si configurano i provider e le loro chiavi; l’Abilities API è il registro delle azioni che il sito sa compiere, ed è la base su cui poggiano gli agenti di cui parlo più avanti.

Il flusso di una richiesta è semplice: l’utente clicca «genera», il plugin decide quale modello usare e quanti token spendere, l’AI Client smista la richiesta, il connettore aggiunge la chiave API e il modello risponde. La frase da tenere a mente è una sola: chi decide modello e token è il plugin, non tu.

C’è poi un dettaglio che nel post di maggio avevo semplificato troppo: nativo non vuol dire pronto all’uso. Il core da solo non parla con nessun modello, servono i plugin dei provider (quello di Anthropic supera le 60.000 installazioni, quelli di OpenAI e Google le 50.000), e prima ancora servono un account, una carta di credito su un servizio estero e una chiave API.

Pericolo 1: il plugin sceglie il modello

Il primo pericolo del client AI di WordPress è architetturale: il modello e i token li sceglie il plugin, e nel core non esiste un tetto di spesa globale.

È il nodo del talk. Chi amministra il sito sceglie quali provider rendere disponibili e quale chiave usare; il plugin decide quale modello chiamare, anche il più costoso, quanti token consumare e se mettere un freno oppure no. Nel core ci sono il filtro wp_ai_client_prevent_prompt, che blocca un singolo prompt con la tua logica, il tetto di token per singola richiesta e il conteggio dei token usati, ma nessuna quota, nessun budget e nessun tetto globale, nemmeno nella 7.1.

Il team AI ha risposto ad alcune critiche, e va detto: nel plugin AI ci sono il Request Logging, che registra provider, modello, token e durata di ogni chiamata, e le Connector Approvals, che stabiliscono quali plugin possono usare quali connettori. La richiesta di introdurre tetti di spesa per plugin, aperta nel repository, è stata però chiusa con il solo logging. E siccome più plugin con la stessa chiave spendono dallo stesso conto, il problema resta tutto lì.

La Beta 1 della 7.2 aggiunge una seconda strada per spendere token, gli embeddings con wp_ai_client_embedding(), bloccabili con il filtro wp_ai_client_prevent_embedding. Il codice lo dice chiaramente: nessun modello viene scelto in automatico, lo indica il plugin. Le funzioni crescono, i freni no.

Pericolo 2: la fattura che non ti aspetti

Il secondo pericolo è la conseguenza del primo: tra il modello più economico e il più potente oggi c’è un fattore cento, a giugno era circa trenta.

Per capire quanto può costare il client AI di WordPress ho rifatto la tabella di giugno con lo stesso criterio: cento articoli da blog, circa 2.000 token di input e 1.500 di output ciascuno, con i prezzi di listino in dollari per milione di token verificati il 19 ottobre sulle pagine ufficiali dei tre provider. I prezzi di giugno sono ancora validi, ma sono arrivati modelli nuovi agli estremi della scala.

Lo stesso lavoro costa quindi da nove centesimi e mezzo a nove dollari e mezzo. Haiku 5.5 mantiene quel prezzo fino a 100.000 token di prompt, oltre costa cinque volte tanto, e Gemini 4 Argon raddoppia a fine promozione: dettagli che un plugin conosce e chi amministra il sito di solito no. Il punto, però, non è più il costo unitario, perché i modelli economici costano pochissimo: è chi sceglie il modello e quanto volume genera.

Nel talk l’ho chiamato lo scenario «fattura shock», quello in cui un plugin poco accorto spende cento volte di più per lo stesso lavoro, e a deciderlo non sei tu.

Pericolo 3: la chiave API in chiaro

Il terzo pericolo: le chiavi del client AI di WordPress salvate dalla schermata Connettori stanno in wp_options in chiaro, mascherate nell’interfaccia ma non cifrate.

Lo dice la dev note della Connectors API, senza giri di parole: le chiavi nel database «are not encrypted but are masked in the user interface». Il nome dell’option segue lo schema connectors_{tipo}_{id}_api_key, per esempio connectors_ai_anthropic_api_key, quindi per chi esegue PHP sul sito la chiave è una riga di codice. A giugno, nelle slide di Milano, avevo usato un nome di fantasia: questo è quello vero.

Una chiave AI non è una password, è uno strumento di pagamento. Ad agosto un plugin AI molto diffuso, AI Engine, mostrava le chiavi API agli utenti con ruolo Editor (CVE-2026-16954), ed è la dinamica che Patchstack aveva previsto già a maggio: vulnerabilità dei plugin più chiavi AI uguale token gratis per chi le ruba. Numeri sul furto di chiavi dai siti WordPress non ne ho trovati, e preferisco dirlo che inventarli.

Il rimedio che puoi applicare oggi è tenere la chiave fuori dal database. WordPress la cerca prima in una variabile d’ambiente, poi in una costante PHP e solo alla fine nell’option; il nome della costante è l’ID del provider in maiuscolo seguito da _API_KEY.

// wp-config.php, prima di «That's all, stop editing!»
define( 'ANTHROPIC_API_KEY', 'sk-ant-...' );
define( 'OPENAI_API_KEY', 'sk-...' );
define( 'GOOGLE_API_KEY', '...' );

// Meglio ancora una variabile d'ambiente, per esempio nel pool di PHP-FPM:
// env[ANTHROPIC_API_KEY] = sk-ant-...

Se la chiave era già nella schermata Connettori, cancellala da lì, perché l’option resta nel database anche quando la costante ha la precedenza, e generane una nuova: quella vecchia è già finita nei backup. La Secrets API della 7.2 cifra i segreti con libsodium, ma i Connettori non la usano ancora (il commit parla di un passaggio successivo) e comunque la chiave per decifrare sta in wp-config.php.

Detto in breve: costante e Secrets API proteggono i dati a riposo, non il sito in esecuzione. Contro un plugin malevolo servono plugin verificati e un tetto di spesa sul provider, l’unico freno che regge anche con la chiave rubata.

Pericolo 4: un agente con le tue chiavi

Il quarto pericolo cambia natura: con l’MCP Adapter non si parla più solo di soldi, ma di un agente che esegue azioni sul sito con i tuoi permessi.

L’MCP Adapter trasforma le abilities registrate in strumenti che un agente, come Cursor, VS Code o un client desktop, può scoprire e chiamare. Non è nel core: è un plugin canonico, arrivato su wordpress.org il 7 ottobre, oggi alla 0.7.1 e ancora dichiarato sperimentale, perché la specifica MCP è in movimento. L’agente entra con una application password, quindi eredita tutte le capability dell’utente con cui si collega, senza ambiti e senza scadenza.

Con Claud.ia abbiamo provato l’adapter su un WordPress 7.1.3 in locale, e tre cose sono emerse con chiarezza. Il trasporto chiede solo di essere loggati, quindi anche un subscriber completa la connessione; le annotazioni readonly e destructive sono solo suggerimenti, tanto che un’ability dichiarata di sola lettura che crea una bozza viene eseguita senza fiatare; il vero freno è il permission_callback di ogni singola ability. Al 28 ottobre due issue di sicurezza dell’adapter sono ancora aperte: la #323 (l’header Origin non viene validato) e la #297 (un tipo MCP sconosciuto diventa uno strumento, quindi un’esclusione può trasformarsi in esposizione).

Le regole che dovremmo tenere a mente sono tre: un utente dedicato per l’agente con il ruolo minimo, solo abilities di lettura esposte su internet e le azioni distruttive in locale o dietro approvazione, audit e freni con gli hook della 7.1.

Come mi difendo dai quattro pericoli

Contro i pericoli del client AI di WordPress la regola d’oro del talk è una: tratta la chiave come una carta di credito aziendale, con un tetto e un solo punto di controllo.

• Una chiave solo per WordPress, dedicata e revocabile, in una costante o in una variabile d’ambiente.
• Un tetto di spesa sul provider: Anthropic, OpenAI e Google permettono di impostarlo per organizzazione o per progetto. Dove il core non frena, frena il provider.
• Rotazione della chiave con cadenza fissa e subito dopo ogni sospetto.
• Audit dei plugin AI: quale modello usano, se mettono un freno, se chiamano servizi esterni; nel plugin ufficiale attiva il Request Logging.

Un’alternativa per mettere il tetto senza fidarsi di un solo provider è OpenRouter: una chiave sola davanti a centinaia di modelli, credito prepagato e un tetto per singola chiave, con una commissione del 5,5% sull’acquisto dei crediti. A giugno lo presentavo come il modo per spendere meno; oggi i modelli economici dei grandi provider costano come i low cost, quindi il vantaggio rimasto è il controllo: una chiave rubata svuota al massimo il credito che ci hai messo tu.

Alcune precisazioni

Rileggendo quello che avevo scritto sul client AI di WordPress ho trovato alcune cose che devo rettificare.

• L’adattatore MCP non è nel core. Nel post su WordPress 7.0 lo elencavo come quarto componente: è un plugin separato, pubblicato su wordpress.org a ottobre.
• I provider non sono pronti all’uso. Il core ha tre connettori ufficiali, ma per parlare con un modello servono i rispettivi plugin dei provider.
• La capability dedicata non è confermata. Il nome che circolava viene dal README di una libreria, non dalla documentazione del core, che parla solo di un controllo ad alto privilegio.

Slide e video del talk

Le slide sul client AI di WordPress sono quelle aggiornate di Padova; il video è la prima versione del talk, registrata al WordPress Meetup Milano di giugno.

Le slide del talk di Padova sono in PDF, 36 pagine con la parte sugli agenti MCP e le verifiche sulla Beta 1 della 7.2. Le trovi qui sotto, sfogliabili, e subito dopo c’è il video di Milano: la tesi è la stessa, mancano la sezione MCP e i numeri di ottobre. Tutti i miei interventi, con slide e video quando esistono, sono raccolti nella pagina conferenze e talk.

Da grandi poteri, grandi bollette

Il client AI di WordPress è infrastruttura fatta bene, ma chi lo vuole usare è meglio che sappia a cosa può andare incontro.

La citazione con cui apro il talk è quella dell’Uomo Ragno, «da grandi poteri derivano grandi responsabilità», e a ottobre la tesi regge: WordPress ha messo l’AI nel core come infrastruttura, ma chi decide modello, token e azioni è il codice di un plugin. Non è un talk contro l’AI, la uso ogni giorno: è un invito a farla passare da un punto che controlli tu, prima di accenderla, e a non affidare la chiave a scatola chiusa.

Se vuoi approfondire, parti dalla guida pratica a Claude Code, dove il tema dei permessi degli agenti torna in un contesto diverso, e dagli articoli della categoria intelligenza artificiale. Il 14 novembre sarò al WordCamp Pisa con un talk diverso, e se vuoi una mano a mettere in sicurezza i plugin AI dei tuoi siti puoi prenotare una call conoscitiva.

Io per il momento non ho ancora acceso il client AI su un sito di produzione, e personalmente non ne sento l’esigenza. Se la pensi diversamente scrivimi, perché il confronto è sempre una cosa utile.

Domande frequenti sul client AI