Una coda può esplodere anche senza un attacco. Un nuovo studio ha raccolto 84 possibili casi di aumento anomalo delle richieste verso servizi pubblici in 11 giurisdizioni. Gli autori vedono segnali coerenti con l’uso dell’AI, ma precisano che il metodo non dimostra un rapporto causale. Per una PMI il problema è già concreto: se un modello riduce a pochi secondi il costo di compilare un form, aprire un ticket o chiedere un preventivo, il collo di bottiglia si sposta dal visitatore a chi deve verificare la richiesta.

La decisione tecnica è questa: aggiungere attrito per bloccare l’automazione oppure progettare un canale strutturato che la accetti sotto controllo. Il criterio di confronto non è “quale soluzione ferma più bot”, ma quale mantiene sostenibile il costo per richiesta valida quando il volume cresce.

Approccio A: CAPTCHA e limiti sul form pubblico

Il primo approccio protegge l’interfaccia esistente. Sul form WordPress si aggiungono un challenge come Cloudflare Turnstile, un limite per IP o sessione, una lunghezza massima dei campi e una coda per l’invio di email o notifiche. È la strada più rapida quando il problema è già in corso.

Turnstile, però, non è un adesivo da mettere sul frontend. La documentazione Cloudflare richiede la validazione server-side del token: il widget da solo non protegge il form. Il token è monouso e scade dopo cinque minuti. Anche il rate limiting va considerato una protezione operativa, non una garanzia matematica: Cloudflare avverte che alcuni eccessi possono raggiungere l’origine prima dell’aggiornamento dei contatori.

I pro sono concreti: intervento veloce, nessun nuovo contratto API per il cliente e buona riduzione dello spam più banale. I contro emergono appena le richieste hanno valore. Un limite per IP non identifica una persona o un’azienda; un testo generato bene può superare i controlli formali; più attrito significa più abbandoni anche tra gli utenti legittimi. Il paper sull’agentic flooding nota inoltre che i rate limit riducono il volume, ma non risolvono il carico qualitativo di richieste più lunghe e complesse.

Approccio B: endpoint agent-ready con identità e quote

Il secondo approccio separa il form umano dal canale macchina. Invece di lasciare che un agente navighi la pagina e scriva testo libero, gli si offre un endpoint con schema dichiarato: tipo di richiesta, identificativo del cliente, campi obbligatori, allegati ammessi e risposta asincrona. L’accesso richiede una credenziale revocabile; la quota si applica all’identità, non soltanto all’indirizzo IP.

Su WordPress non significa aprire tutto il REST API. Significa creare un endpoint minimo per una singola operazione, con permission_callback, sanitizzazione, validazione e capacità dedicate. Le Application Passwords di WordPress sono pensate per richieste esterne via HTTPS, ma vanno assegnate a un utente con privilegi strettamente necessari. Per evitare doppie richieste serve anche una chiave di idempotenza, lo stesso controllo che conviene applicare ai webhook AI collegati a WordPress.

Qui i vantaggi sono qualità dei dati, tracciabilità e controllo del costo. Puoi rifiutare un payload prima di inviare email, interrogare un CRM o chiamare un modello a pagamento. OWASP raccomanda limiti espliciti su dimensione degli input, numero di operazioni, tempo di esecuzione e spesa verso servizi terzi. Lo svantaggio è il costo iniziale: schema, autenticazione, gestione delle chiavi, documentazione e monitoraggio diventano parte del prodotto.

Il confronto operativo

Criterio A: barriera sul form B: canale agent-ready
Tempo di messa in opera Ore o pochi giorni Progetto e integrazione dedicati
Identità IP, sessione, challenge Credenziale revocabile e quota per soggetto
Qualità dell’input Testo libero da verificare dopo Schema validato prima del lavoro costoso
Crescita Più blocchi e più falsi positivi Coda, backpressure e limiti per operazione
Costo iniziale Basso Più alto

Il punto che spesso manca è il costo downstream. Cento richieste che superano il CAPTCHA possono generare cento email, cento record nel CRM e cento classificazioni AI. Il perimetro va quindi chiuso dopo il gateway: limite sugli allegati, tetto alle chiamate esterne, timeout e coda con concorrenza controllata. È lo stesso principio discusso nella gestione di spesa e permessi degli agenti AI: una credenziale valida non autorizza consumo illimitato.

Come applicarlo a una PMI

Per un sito vetrina con pochi contatti al giorno sceglierei una soluzione ibrida, non un progetto API completo. Il form pubblico resta accessibile, ma valida Turnstile sul server, limita dimensione e frequenza, non invia direttamente verso servizi a consumo e assegna un identificativo univoco a ogni richiesta. Le ripetizioni con lo stesso identificativo non producono nuovo lavoro.

Per assistenza clienti, ordini B2B, richieste documentali o preventivi ad alto volume aggiungerei invece il canale agent-ready. L’output del modello non deve diventare automaticamente una decisione: può classificare, estrarre campi e proporre una priorità, mentre regole deterministiche gestiscono duplicati, completezza e soglie economiche. I casi fuori standard restano a una persona.

Le metriche utili sono quattro: richieste valide per identità, percentuale di duplicati, costo medio di lavorazione e tempo fino alla decisione. Contare soltanto i blocchi del WAF porta a ottimizzare il rumore, non il servizio.

Take finale: proteggi subito, ridisegna ciò che vale

Se il canale raccoglie spam anonimo e a basso valore, l’approccio A è sufficiente: challenge, rate limit e limiti server-side. Se ogni richiesta può diventare un cliente, un ordine o una pratica, continuare ad aggiungere attrito è una falsa economia. In quel caso sceglierei B: endpoint ristretto, identità revocabile, schema, idempotenza e quota applicativa.

Gli agenti rendono più economico chiedere. Il sito deve rendere più economico verificare, senza trasformare ogni visitatore legittimo in un sospetto.

Fonti