Sicurezza chatbot AI: cosa c’è sotto il cofano di Sabriel AI

Un widget di chat sembra una cosa semplice: si apre, scrive, risponde. Quello che decide se fidarsi o no non si vede mai in quella finestra. Sta in cosa succede quando qualcuno prova a violare l’account amministratore duecento volte in un minuto, in cosa succede quando qualcuno prova a far scrivere al bot un prezzo che non esiste, in dove finisce la chiave API del motore scelto. La maggior parte delle pagine che vendono un assistente AI non ne parla mai. Questa guida sì, con i meccanismi veri, non la versione riassunta per il pubblico generico.

La sicurezza chatbot AI si misura in dettagli come questi, non negli annunci sulla pagina di vendita.

Chi ha già letto la presentazione di Sabriel AI sa cosa fa l’assistente: prenota appuntamenti, prepara preventivi, qualifica i contatti caldi e freddi. Qui si parla di come è costruito perché lo faccia senza diventare il punto debole del sito su cui vive, e senza poter essere raggirato da chi ci prova.

Chi cerca la panoramica generale di cosa fa un assistente AI WordPress può partire da lì; qui l’attenzione è tutta sulla sicurezza chatbot AI del sistema che c’è dietro.

Un plugin fatto di moduli, non un blocco unico

Non esiste un unico file enorme che fa tutto. Ogni funzione, dalla gestione dei preventivi al termometro che classifica i contatti, dal motore di conoscenza del sito alla dashboard, vive nel proprio modulo separato, con la propria classe e le proprie responsabilità. Un difetto in un modulo, per esempio quello dei preventivi PDF, non può propagarsi al modulo che gestisce gli accessi al sito, perché non condividono lo stesso spazio di codice.

Questa separazione tra moduli è la prima vera scelta di sicurezza chatbot AI del progetto, prima ancora di qualunque controllo esplicito.

Sopra questa struttura vive un livello di base condiviso, che gestisce le impostazioni, gli orari di apertura e le funzioni comuni a tutti i moduli, cifratura compresa: il punto in cui converge la logica che deve restare identica ovunque.

Un errore in questo livello condiviso si ripercuoterebbe su ogni modulo collegato: è per questo che conta quanto gli altri per la sicurezza chatbot AI.

Tre motori AI, diciassette modelli, e i problemi che nascono proprio lì

Sabriel AI non ha un motore AI incorporato: si collega direttamente alle API di Anthropic Claude, OpenAI e Google Gemini, con la chiave che sceglie e paga chi possiede il sito. Sono tre integrazioni native separate, ognuna con il proprio formato di richiesta e le proprie stranezze, non un unico adattatore generico che tratta tutti i fornitori allo stesso modo sperando che funzioni.

Gestire ogni fornitore per conto proprio, invece di un adattatore unico, isola anche i problemi: un guasto di un motore non tocca la sicurezza chatbot AI degli altri due.

Chi possiede il sito sceglie il modello esatto da un elenco di diciassette, sei per Gemini, sei per OpenAI, cinque per Claude, ciascuno con il proprio prezzo per milione di token dichiarato in chiaro accanto al nome, dal più economico consigliato per un widget di chat a quelli più potenti per chi vuole il massimo. E se un fornitore rilascia un nuovo modello che ancora non compare nell’elenco, non serve aspettare un aggiornamento del plugin: c’è una voce “Modello personalizzato” che apre un campo dove scrivere l’identificativo esatto a mano, validato e usato subito.

Un modello aggiunto a mano non salta questo controllo: resta sotto la stessa sicurezza chatbot AI degli altri sedici.

Le stranezze tra i tre fornitori sono reali. Google Gemini non permette di abbassare la temperatura del modello abbastanza da garantire una risposta in puro JSON quando il plugin ne ha bisogno per motivi interni: va richiesto esplicitamente all’API, e se un modello specifico lo rifiuta il plugin se lo ricorda e la volta successiva evita di riproporlo. I modelli più recenti di OpenAI, quelli che ragionano prima di rispondere, consumano parte del budget di risposta per un ragionamento invisibile al visitatore: il plugin distingue questo caso e allarga il margine a disposizione, senza che questo costi di più a chi paga, perché si paga solo quello che il modello usa davvero.

C’è poi il problema dei tempi. Prima che questo comportamento venisse limitato con un tetto preciso, un singolo messaggio poteva tenere impegnato il server fino a 44 secondi con Gemini o fino a 88 con OpenAI tra i vari tentativi, ben oltre il limite di esecuzione che quasi tutti gli hosting impongono. Il risultato per il visitatore non era un errore chiaro, ma una connessione che si chiudeva da sola con un messaggio che sembra un guasto di rete. Il tetto attuale è calibrato sul tempo di un solo tentativo: il primo, quello con più probabilità di riuscire, non viene mai accorciato.

I tempi di risposta sono a tutti gli effetti sicurezza chatbot AI: decidono se il server resta stabile o si blocca.

Il bot non decide da solo cosa è vero

Un assistente che parla con i clienti e prepara documenti con prezzi reali è utile solo se non può essere convinto a inventare qualcosa. Sabriel AI separa con cura due cose che in molti chatbot restano mescolate: quello che l’assistente dice in conversazione, e quello che succede davvero sul sito.

Questa distinzione tra parlare e agire è al centro della sicurezza chatbot AI di tutto il sistema.

L’assistente non tocca mai direttamente un calendario o un listino: propone un’azione, e un codice separato la verifica contro i dati reali prima che succeda qualcosa. Il prezzo che finisce in un preventivo PDF viene sempre dal listino scritto da chi possiede il sito nelle impostazioni, mai da quello che l’assistente ha scritto in chat. E se nonostante questo un preventivo generato riporta un totale insolitamente alto rispetto al listino configurato, il proprietario riceve un’email con oggetto “ATTENZIONE IMPORTO ALTO” e un avviso esplicito: controllare che sia un preventivo reale e non un tentativo di far scrivere al bot una cifra a caso, prima di considerarlo valido. È un controllo pensato apposta per il caso in cui qualcuno provi a convincere l’assistente a promettere qualcosa che non dovrebbe.

Il controllo sul prezzo è sicurezza chatbot AI applicata al punto più delicato: dove un testo generato diventa un documento con valore economico.

Lo stesso principio vale sulle capacità dichiarate: l’assistente descrive solo le funzioni davvero attive su quella specifica installazione, non un elenco generico di tutto quello che Sabriel AI potrebbe fare. Se il controllo del sito o i preventivi PDF non sono configurati su un’installazione, l’assistente non li nomina nemmeno come possibilità futura: prometterli sarebbe scorretto verso il cliente che ci parla. E se qualcuno gli chiede quale tecnologia lo fa funzionare, risponde con il nome dell’attività per cui lavora, non con il nome del motore AI sottostante: meno informazioni un estraneo ha su cosa c’è dietro, più difficile è costruire un tentativo su misura per raggirarlo.

Non rivelare il motore sottostante è una forma minima ma reale di sicurezza chatbot AI, pensata per non semplificare il lavoro a chi vuole ingannarlo.

Ogni PDF ha una firma, non un numero di serie

I preventivi e gli altri documenti generati dal bot non sono file raggiungibili da chiunque conosca o indovini un indirizzo. Ogni link di scarico porta con sé un token firmato, calcolato sul documento specifico e sull’email del cliente a cui appartiene: il server lo verifica prima di consegnare qualsiasi cosa, e senza una firma valida per quel documento preciso il download semplicemente non parte. Non basta quindi incrementare un numero in un URL per aprire il preventivo generato per qualcun altro, un errore che su altri sistemi capita più spesso di quanto si pensi.

Firmare ogni documento, invece di affidarsi a un numero progressivo, è tra gli esempi più concreti di come la sicurezza chatbot AI protegga i dati dei clienti.

Quello che potrebbe fallire in silenzio, e non fa

Un tema che attraversa tutto il plugin è cosa succede quando qualcosa smette di funzionare senza che nessuno se ne accorga. Le chiavi API vengono cifrate con AES-256-CBC usando una chiave derivata da quella unica generata da WordPress per ogni installazione, con un vettore di inizializzazione casuale a ogni salvataggio. Su alcuni server, spesso quelli con configurazioni più economiche, l’estensione necessaria per cifrare non è disponibile: in quel caso la chiave viene comunque salvata, perché l’alternativa sarebbe un bot che smette di rispondere, ma il pannello lo dice esplicitamente al proprietario invece di lasciargli credere che tutto sia cifrato quando non lo è.

Dichiarare quando la cifratura non è disponibile, invece di darla per scontata, fa parte della sicurezza chatbot AI tanto quanto applicarla davvero.

Lo stesso approccio vale per la posta. Sabriel AI manda email in cinque momenti diversi: conferme di prenotazione, trascrizioni della chat, preventivi, iscrizioni alla newsletter e recupero della cronologia per il cliente. Se il server non riesce a inviarle, normalmente fallirebbero tutte senza che nessuno se ne accorga: il pannello continua a funzionare e i clienti semplicemente non ricevono nulla. Per questo esiste un controllo dedicato che registra l’ultimo invio fallito e il motivo esatto, visibile nella pagina di stato del sistema, invece di lasciare che il problema si scopra solo quando un cliente si lamenta di non aver ricevuto niente.

Un’email di preventivo mai arrivata è, in fondo, un tema di sicurezza chatbot AI tanto quanto un accesso bloccato: un cliente ignorato senza che nessuno lo sappia.

La stessa pagina di stato riassume in un colpo d’occhio se le protezioni di sicurezza sono davvero attive, quante sullo standard nove su nove, se la cifratura è disponibile e funzionante, se i documenti dei clienti sono al riparo da accessi esterni: non affermazioni generiche, ma controlli veri eseguiti sull’installazione in quel momento.

Questa pagina di stato è dove la sicurezza chatbot AI smette di essere una promessa scritta e diventa un numero verificabile.

Sicurezza chatbot AI: cosa succede quando qualcuno prova a entrare senza permesso

Oltre a proteggere se stesso, Sabriel AI protegge anche il sito su cui vive, con un sistema di blocco degli accessi costruito su due scale indipendenti che lavorano insieme.

Questo doppio blocco è probabilmente il pezzo più visibile della sicurezza chatbot AI, perché ferma un attacco mentre sta succedendo.

La prima scala guarda la connessione da cui arrivano i tentativi: 5 errori fanno scattare una pausa di 15 minuti, altri 5 la portano a un’ora, altri 5 ancora fanno scattare un blocco di 30 giorni, non permanente. La seconda scala guarda l’account preso di mira, con la stessa progressione, ma al terzo scalino l’account resta chiuso finché non lo riapre il proprietario, che riceve subito un’email con un link per farlo da solo in pochi secondi.

La sicurezza chatbot AI lascia comunque una via d’uscita a chi ha diritto di entrare, non solo a chi vuole entrare senza permesso.

Le due scale servono entrambe, e non è ridondanza. Bloccare solo la connessione non basta: verificato direttamente nel codice, cento reti diverse riuscivano a far passare cinquecento tentativi di password senza mai attivare un blocco, perché ogni rete ripartiva da zero. Bloccare solo l’account non basta nemmeno, perché chiunque potrebbe chiudere fuori il vero proprietario bombardando il suo nome utente da indirizzi diversi, trasformando una difesa in un’arma contro la persona che dovrebbe proteggere. Messe insieme, chi tenta un attacco si blocca sulla connessione prima di riuscire a bloccare l’account di qualcun altro.

Si vede qui la differenza fra una misura di sicurezza chatbot AI dichiarata e una verificata davvero nel codice.

Restano sempre attive alcune vie di uscita: un dispositivo già riconosciuto salta ogni blocco, chi è già dentro il sito resta dentro, e una riga in wp-config.php permette di disattivare tutto in caso di emergenza. Dopo 24 ore senza nuovi errori il conteggio si azzera da solo.

Prevedere queste eccezioni è ciò che distingue una sicurezza chatbot AI pensata bene da una semplicemente rigida.

Sicurezza chatbot AI: quattro modi per scoprire uno username, tutti chiusi

Scoprire il nome utente di un amministratore è spesso il primo passo di un attacco. Sabriel AI chiude quattro strade attraverso cui WordPress tende a rivelarlo di default: le richieste REST API filtrate per autore, i dati restituiti dal sistema di oEmbed, la mappa XML degli autori generata dalle sitemap, e il vecchio trucco dell’indirizzo con ?author=1.

Nascondere lo username sembra un dettaglio minore, ma chiude quasi sempre il primo passo di un attacco più grande: è sicurezza chatbot AI, non semplice prudenza.

Su quest’ultimo vale un dettaglio che mostra la differenza fra bloccare qualcosa e bloccarlo bene. La sitemap degli autori, disattivata nel modo più ovvio, non restituisce un errore: restituisce la home page del sito con un codice di successo, sotto un indirizzo che finisce in .xml. Sembra funzionare ma non lo fa fino in fondo: il nome utente non esce comunque, però un motore di ricerca si ritrova a indicizzare una copia duplicata della home page. Sabriel AI restituisce invece lo stesso identico segnale di pagina non trovata che WordPress userebbe con le sitemap spente del tutto.

È un esempio preciso di come la sicurezza chatbot AI si giochi nei dettagli, non nell’aver spuntato la casella giusta nelle impostazioni.

XML-RPC, intestazioni e le protezioni che quasi nessuno controlla fino in fondo

XML-RPC è il canale storico con cui WordPress comunica con applicazioni esterne, ed è anche uno dei bersagli più sfruttati per attacchi automatizzati su larga scala. Il modo in cui la maggior parte dei plugin di sicurezza lo disattiva, con un semplice interruttore sul filtro xmlrpc_enabled, lascia scoperti sette comandi su settantasette, perché non tutti passano da quel controllo. Fra questi sette c’è pingback.ping, il comando usato per amplificare gli attacchi di massa che l’interruttore dovrebbe fermare. Sabriel AI svuota l’intero elenco dei comandi disponibili con la priorità più alta possibile, così nessun altro plugin può rimetterne dopo.

Chiudere anche i comandi che un altro plugin potrebbe riaprire per errore serve a una sicurezza chatbot AI che dura nel tempo, non solo il giorno dell’installazione.

Sono tutte misure che compaiono anche nella documentazione ufficiale di hardening di WordPress: non trovate esotiche, ma la base che ogni installazione seria dovrebbe avere, qui applicata in modo verificato invece che dichiarata soltanto. A queste si aggiungono intestazioni HTTP contro il clickjacking e l’interpretazione forzata dei file, l’occultamento della versione di WordPress in uso, e un controllo reale, non solo dichiarato, su readme e file di licenza ancora esposti dal server.

Ognuna di queste misure aggiunge un livello alla sicurezza chatbot AI complessiva dell’installazione.

Chi vuole il quadro più ampio delle vulnerabilità comuni su un’installazione WordPress può leggere la nostra guida sulla sicurezza del sito WordPress: quanto descritto qui riguarda specificamente cosa protegge l’assistente stesso, non sostituisce un audit generale dell’installazione.

Qui restiamo nel perimetro più stretto della sicurezza chatbot AI, non dell’installazione in generale.

Le rotte aperte al pubblico, protette lo stesso

Un assistente che parla con un visitatore anonimo ha bisogno di funzioni raggiungibili senza autenticazione: gli orari disponibili, la creazione della prenotazione, la conversazione stessa con il motore AI.

Restare aperte non significa restare indifese, e non significa nemmeno restare senza controllo. Restare aperte per forza di cose non le esclude dalla sicurezza chatbot AI: anche loro sono protette, solo in modo diverso.

Ecco cosa protegge queste rotte pubbliche:

– Limite di messaggi in 24 ore, calcolato insieme su indirizzo di rete, dispositivo ed email fornita, così che aggirarne uno solo dei tre non basti per superare il limite
– Pulizia di ogni campo inviato prima di essere salvato, con gli indirizzi email usa e getta riconosciuti e respinti nel modulo di prenotazione
– Verifica di autenticità della richiesta per tutto ciò che modifica dati, presente in dieci file distinti del plugin
– Controllo permessi amministrativi per le funzioni riservate al proprietario, dalle impostazioni ai risultati dell’audit tecnico, usato in diciannove file
– Query parametrizzate invece di testo composto a mano per ogni interrogazione al database con dati esterni, la difesa standard contro le iniezioni SQL

Messe insieme, queste misure sono la parte meno visibile ma più costante della sicurezza chatbot AI, quella che lavora anche quando nessuno se ne accorge.

Perché lo raccontiamo con questo livello di dettaglio

Un assistente che prende appuntamenti veri, genera documenti con dati fiscali e parla con i clienti di un’azienda è un pezzo di infrastruttura, e va giudicato con gli stessi criteri con cui si giudica un’infrastruttura, non con quelli con cui si giudica un widget grafico.

È lo stesso motivo per cui la sicurezza chatbot AI merita una pagina a parte, invece di due righe in fondo alla presentazione.

La versione gratuita di Sabriel AI è pubblica su WordPress.org, con un registro delle versioni che non dice genericamente che sono stati corretti dei bug: dice quale difetto, come si manifestava, e cosa vedeva chi lo usava. Buona parte dei dettagli raccontati in questa pagina, dal tetto sui tempi di attesa alla mappa dei nomi dei modelli superati, nasce esattamente da lì: da un comportamento reale osservato e corretto, non da una lista di funzionalità immaginate a tavolino.

Un changelog che dice davvero cosa si è rotto è, di fatto, sicurezza chatbot AI resa verificabile da chiunque, non solo dichiarata.

Se stai valutando un assistente AI per il sito della tua attività, la pagina di Sabriel AI mostra prezzi e piani, mentre la versione gratuita si scarica da WordPress.org e si può verificare da soli, riga per riga, prima ancora di installarla su un sito vero.

Verificare la sicurezza chatbot AI con i propri occhi, prima di installarla, è esattamente il punto di questo articolo. Vuoi installare Sabriel AI sul tuo sito o valutare un progetto su misura? Richiedici una consulenza gratuita.