Web Bot Auth:
visitatori senza occhi

Crawler e agenti non sono la stessa cosa

Qui serve una distinzione che quasi tutti saltano.

Il crawler indicizza: passa, copia, se ne va. È quello che l'IT conosce da vent'anni e blocca per riflesso. L'agente invece agisce per conto di una persona in quel momento: cerca un fornitore per chi ha appena posto una domanda, verifica una disponibilità, compila una richiesta di preventivo. Il rapporto numerico inganna: per ogni visitatore reale che un assistente vi manda, il suo crawler è passato centinaia di migliaia di volte.

Bisogna non guardare (solo) il volume di ricerca, ma l'intento. E se si comprende, si può identificare il potenziale cliente qualificato e profilabile.

Il punto interessante è la conversione

Le rilevazioni indipendenti di questi mesi convergono su un punto che non è scontato: il traffico che arriva da assistenti AI converte da 4 a oltre 20 volte meglio dell'organico tradizionale.

La ragione non è magica. Chi arriva passando da un assistente ha già dato istruzioni, probabile abbia anche già confrontato diverse alternative, sa già cosa "aspettarsi". E quindi arriva l'agente, istruito, che non indugia ma agisce.

Potenzialmente, è un canale con un'economia di valore ma viene ignorato (quasi sempre) solo perché non compare in un grafico.

Bloccare o aprire è la domanda sbagliata

Quando la questione arriva sul tavolo, la discussione si polarizza in mezz'ora. Da una parte chi vuole chiudere tutto, perché scraping e abusi costano. Dall'altra chi vuole spalancare, perché il canale cresce.

Hanno torto entrambi, così non facciamo torti, e per lo stesso motivo: stanno trattando un problema di identità come se fosse un problema di traffico e risorse. Bloccare gli agenti (es tramite il robots.txt & co) vuol dire chiudere un canale di conversione, aprirli vuol dire rischiare abusi. La questione non è chi entra, ma chi entra con quale "intento".

Ma, esiste una terza strada, sperimentale. E si chiama Web Bot Auth.

L'agente firma crittograficamente la propria richiesta con le HTTP Message Signatures (RFC 9421), una chiave Ed25519 e un header che punta alla directory pubblica delle chiavi. Voi verificate la firma e sapete con chi parlate prima di decidere cosa concedere. Non è un esperimento di nicchia: dietro ci sono Cloudflare, Amazon, Akamai e OpenAI, un working group IETF costituito quest'anno e i circuiti di pagamento che la adottano come porta d'ingresso.

La domanda vera non è chi sei, è chi ti manda

Ed è qui che diventa interessante, perché verificare l'agente risolve solo metà della questione.

Un agente che prenota, acquista o apre un ticket non agisce per sé. Agisce con una delega. Le domande a cui la vostra applicazione deve rispondere sono almeno quattro, non una: chi sei, chi ti ha autorizzato, fino a che importo (o altre restrizioni), entro quando.

La direzione c'è già ed è in corso di sviluppo. AP2, il protocollo per i pagamenti agentici emerso quest'anno sotto la FIDO Alliance, scompone l'autorizzazione in tre mandati firmati: l'intento dell'utente, il carrello approvato a quel prezzo, il pagamento. Ognuno è una credenziale verificabile con limiti espliciti e ben delineati.

Se vi suona familiare è perché lo è: è Zero Trust applicato a un attore che non è una persona. La differenza è che stavolta l'attore agisce a velocità macchina e non si stanca.

Quindi tutto da rifare?

No, non serve riscrivere il prodotto. Serve smettere di considerare l'interfaccia grafica l'unico modo per usare il vostro software, ormai è palese che non lo è.

1. Misurare lato server, non nel browser. I log applicativi vedono quello che lo script non vede. Distinguete crawler e agenti attivi, e portate quel numero nella stessa slide dove portate le sessioni di viste & co. Finché non ha un numero, non avrà un budget.

2. Esporre le capacità come contratti, non come pagine. Catalogo, disponibilità, prezzi, prenotazione: se un agente deve dedurli leggendo il DOM, il primo restyling vi taglia fuori. API contract-first, dati strutturati e, dove ha senso, un endpoint MCP (aka WebMCP).

3. Separare identità e delega. Verificate l'agente con la firma, e trattate l'autorizzazione dell'utente come una cosa distinta, con ambito, tetto di spesa e scadenza. Un agente autenticato non è (per forza) autorizzato.

4. Classificare e riconoscere. Un blocco o un rate limit mal definito ha il peso di una decisione commerciale, quindi va valutato bene.

Un effetto collaterale: il collaudo

C'è una cosa che abbiamo notato: quando un agente non riesce a completare un'azione sul vostro prodotto, quasi sempre quell'azione è faticosa anche per una persona. Un flusso di prenotazione con quattro passaggi ambigui è opaco per tutti. Il traffico agentico non è solo un canale, è una convalida non indifferente.

Ed ecco che non bisogna cadere in alcune trappole:

- Chi fa solo frontend ricercherà un sito più bello che gli agenti faran fatica a navigare.

- Chi fa solo sicurezza cercherà di isolare e bloccare i non umani.

- Chi fa solo AI vi consegna un chatbot perché così siete più "smart".

Ma la verità è che, semplicemente, bisogna partire dalle capacità del prodotto così da renderlo utilizzabile, verificabile e delegabile.. di nuovo, per tutti.