Salta al contenuto principale
GLOSSARIO

Web Bot Auth

Toshendra Sharma

Di Toshendra SharmaFondatore e CEO, AgentCredia · Updated November 13, 2026

Un gruppo di lavoro dell'IETF e un lavoro su Internet-Draft su come bot e agenti AI possono firmare crittograficamente le richieste HTTP, così i siti possono verificare chi le ha inviate.

Cos'è Web Bot Auth

Web Bot Auth è il nome di un gruppo di lavoro IETF e del relativo lavoro su Internet-Draft per autenticare il traffico web automatizzato. L'idea è semplice: crawler, assistenti AI e agenti autonomi firmano le proprie richieste HTTP usando HTTP Message Signatures (RFC 9421), e pubblicano le chiavi pubbliche che verificano tali firme sotto un identificatore che controllano. Un sito web può quindi confermare che una richiesta provenga davvero dall'operatore che indica, invece di affidarsi a una stringa user-agent che chiunque può copiare. Per capire cosa significa questo per un team di prodotto, vedi Web Bot Auth per i team di prodotto; per i passaggi di implementazione, vedi la guida su come verificare le richieste firmate degli agenti AI.

A novembre 2026, il documento principale del gruppo di lavoro è draft-ietf-webbotauth-httpsig-protocol, che definisce un header Signature-Agent per la discovery delle chiavi in-band, un formato di directory delle chiavi basato su JSON Web Key Sets e un URI well-known da cui viene servita quella directory. La pagina dei documenti del gruppo di lavoro lo elenca insieme ad altri draft individuali correlati. Si tratta di Internet-Draft, quindi lavori in corso. Dettagli come il modo in cui vengono scoperte le chiavi, quali componenti della richiesta devono essere firmati e quali header trasportano le informazioni dell'operatore possono cambiare tra una versione e l'altra. Chi implementa dovrebbe seguire i draft correnti, non una qualsiasi istantanea.

Perché è importante

Siti web e API hanno a lungo identificato i bot tramite stringhe user-agent e intervalli IP. Entrambi hanno limiti: le stringhe user-agent si falsificano facilmente (vedi user-agent spoofing), e gli intervalli IP cambiano e sono condivisi tra provider cloud. Man mano che gli agenti AI iniziano a navigare, chiamare API e usare MCP servers per conto delle persone, le applicazioni hanno bisogno di un modo più solido per distinguere i client automatizzati cooperativi da quelli anonimi.

Le richieste firmate offrono questa base più solida. Una firma verificata consente a un'applicazione di riconoscere in modo coerente un operatore noto, offrirgli un percorso strutturato invece di un'interfaccia modellata per un umano, e misurare la sua attività con precisione.

Come funziona a livello generale

  1. L'operatore genera una coppia di chiavi e pubblica la chiave pubblica in una posizione legata alla propria identità, in genere il percorso well-known http-message-signatures-directory sotto il proprio dominio.
  2. Ogni richiesta include gli header Signature-Input e Signature che coprono componenti selezionati della richiesta, più un identificatore di chiave, e un header Signature-Agent che punta alla directory delle chiavi.
  3. Il sito ricevente recupera o mette in cache le chiavi pubblicate dall'operatore, ricostruisce la signature base e verifica la firma.
  4. In caso di esito positivo, il sito sa che la richiesta è stata prodotta dal possessore di quella chiave, associata a quell'identificatore pubblicato.

Cosa stabilisce e cosa non stabilisce

Una firma Web Bot Auth autentica il client automatizzato. Non risponde a:

  • se l'operatore è autorizzato a fare ciò che chiede (autorizzazione dell'agente),
  • se una persona ha istruito o approvato l'azione (autorità delegata),
  • se l'azione è sicura o il contenuto restituito verrà usato in modo appropriato.

Queste restano decisioni dell'autenticazione, dell'autorizzazione e della policy della stessa applicazione ricevente. Il nostro articolo sul blog cosa provano le richieste firmate degli agenti AI, e cosa no approfondisce questo confine.

Idee sbagliate comuni

  • "Ogni bot firmerà presto." L'adozione cresce client per client. Le applicazioni vedranno per molto tempo un mix di traffico firmato, dichiarato e anonimo, quindi serve un modo chiaro per gestire ciascuno.
  • "Una firma rende un bot buono." Rende un bot noto. Noto è il punto di partenza per una policy, non la policy stessa.
  • "Il draft è definitivo." È un Internet-Draft in evoluzione. Costruisci sulla base del testo corrente ed aspettati revisioni.

Come si collega Proof of Actor

Proof of Actor tratta una firma validata come evidenza con base Verified, limitata alla chiave e all'identificatore che dimostra. La mantiene separata dai nomi dichiarati e dai segnali inferiti, e non trasforma mai l'identità in autorizzazione. Proof of Actor è progettato per verificare richieste firmate man mano che questi standard maturano; le tue policy in Route decidono cosa può fare un agente verificato.

Scopri come si inserisce in API e MCP servers, oppure richiedi l'accesso anticipato.

Fonti

Vedi l'intelligence degli actor nella tua app.

Preferisci parlare prima? Parla con i fondatori