Web Bot Auth per i team di prodotto: cosa significano le richieste firmate degli agenti per la vostra roadmap

Per anni, l'unico modo per un client automatizzato di dire a un sito web chi fosse è stato il nome nell'intestazione User-Agent e, per alcuni grandi operatori, un elenco pubblicato di indirizzi IP o un controllo reverse DNS. I nomi sono facili da copiare. Gli elenchi di rete coprono solo gli operatori che li mantengono. Man mano che gli agenti AI iniziano ad agire per persone reali sul web, questo divario è diventato un problema di prodotto, non solo di sicurezza.

Web Bot Auth è l'iniziativa principale per colmarlo. Offre ai client automatizzati un modo per firmare le proprie richieste con una chiave che controllano e pubblicano, così un sito può verificare la firma invece di fidarsi di un nome. Questa spiegazione è per product manager e responsabili di engineering che devono capire di cosa si tratta, cosa cambia e cosa non cambia, senza leggere le specifiche dalla fine alla fine.

La versione breve

• Che cos'è: un gruppo di lavoro IETF, webbotauth, e l'approccio che sta standardizzando per autenticare client HTTP automatizzati.
• Come funziona: il client firma parti di ogni richiesta usando HTTP Message Signatures (RFC 9421) e indica una directory delle proprie chiavi pubbliche. Il sito recupera la chiave e verifica la firma.
• Cosa prova: quale chiave ha firmato la richiesta e che le parti firmate non sono state modificate durante il transito.
• Cosa non prova: che l'agente sia autorizzato a fare ciò che chiede, che agisca per un utente specifico o che si comporti bene.
• Stato a novembre 2026: RFC 9421 è un Proposed Standard pubblicato. Il documento di protocollo Web Bot Auth è un Internet-Draft del gruppo di lavoro, non ancora un RFC.
• Cosa fare: pianificate di trattare le firme valide come prova forte, continuate a gestire il traffico non firmato e mantenete le decisioni di autorizzazione nel vostro codice.

Che cos'è il lavoro IETF su Web Bot Auth

L'IETF ha charterato il gruppo di lavoro Web Bot Auth per standardizzare metodi di autenticazione crittografica per client automatizzati e per dare ai siti web più informazioni sugli operatori che li gestiscono. Il charter si concentra sui siti che servono principalmente persone e indica un insieme ampio di client nel perimetro: crawler, web archiver, link checker, crawler per il training AI e agenti AI che agiscono per utenti finali.

Nel charter ci sono due esclusioni da tenere presenti per i team di prodotto. L'autenticazione dell'utente finale è fuori perimetro, quindi questo non è un modo per effettuare il login di una persona. Anche il monitoraggio della reputazione dei bot è fuori perimetro, quindi lo standard vi dice chi ha firmato una richiesta, non se quell'operatore sia affidabile.

Il charter elenca tre tipi di deliverable:

1. Documenti in standards track su tecniche per autenticare client automatizzati verso siti web pensati per persone.
2. Documenti in standards track su come trasmettere più informazioni su un bot richiedente usando un identificatore esistente come un nome di dominio o una URL.
3. Documenti di best current practice o informativi su temi operativi come gestione delle chiavi, ciclo di vita e deployment.

A che punto sono i documenti, a novembre 2026

A novembre 2026, il gruppo di lavoro ha un solo documento adottato: draft-ietf-webbotauth-httpsig-protocol, intitolato "HTTP Message Signatures for automated traffic", alla revisione 01, datato 29 ottobre 2026. È un Internet-Draft, quindi è un lavoro in corso che può ancora cambiare. Non è un RFC.

Altri draft individuali sono associati al gruppo e sono in discussione, incluse proposte su un registry e sul formato agent card, sull'autenticazione anonima dei bot, su un formato JSON per pubblicare gli intervalli IP dei client automatizzati e su un header per i metadati firmati degli agenti. I draft individuali sono proposte; nessuno di questi è stato adottato dal gruppo a questa data.

Il charter ha fissato nel 2026 tappe per inviare le specifiche all'IESG per l'approvazione. A novembre 2026, il documento di protocollo resta un draft del gruppo di lavoro. Potete seguire lo stato attuale sulla pagina IETF datatracker del gruppo di lavoro e sul draft di protocollo.

Come funzionano HTTP Message Signatures

Web Bot Auth si basa su RFC 9421, HTTP Message Signatures, pubblicato nel febbraio 2024 come Proposed Standard. RFC 9421 è un meccanismo generale: definisce come firmare parti selezionate di un messaggio HTTP e come trasportare la firma negli header. Web Bot Auth lo profila per i client automatizzati.

In termini semplici, una richiesta firmata di un agente funziona così:

1. L'operatore crea una coppia di chiavi. Mantiene segreta la chiave privata e pubblica la chiave pubblica.
2. Il client sceglie cosa firmare. Seleziona componenti della richiesta, come l'host o la URI di destinazione e un tempo di creazione. Il draft attuale richiede di coprire l'autorità o la URI di destinazione, così una firma per un sito non può essere semplicemente riprodotta su un altro.
3. Il client firma e invia. La richiesta contiene un header Signature-Input che descrive che cosa è stato firmato e con quale chiave, e un header Signature con il valore della firma. Il draft usa un tag web-bot-auth e si aspetta tempi di creazione e di scadenza per ogni firma.
4. Il sito verifica. Trova la chiave pubblica, ricostruisce i componenti firmati dalla richiesta ricevuta e controlla la firma. Se il controllo supera, la richiesta è stata firmata dal possessore di quella chiave e le parti coperte non sono state alterate.

Il draft permette anche a un sito di chiedere una firma. Un origin può inviare un header Accept-Signature, in genere con un rifiuto, per segnalare che desidera richieste firmate.

L'idea della directory delle chiavi

Una firma è utile solo se il sito riesce a trovare la chiave pubblica corretta. Web Bot Auth risponde a questo con una directory delle chiavi.

Nel draft attuale del gruppo di lavoro, il client aggiunge un header Signature-Agent contenente una URL HTTPS. Quella URL serve una directory delle chiavi pubbliche dell'operatore come JSON Web Key Set. Il sito recupera la directory, seleziona la chiave che corrisponde all'identificatore della chiave nella firma e verifica. Il draft definisce anche un percorso well-known, /.well-known/http-message-signatures-directory, dove un operatore può servire la propria directory.

L'idea utile per i team di prodotto è che la URL diventa l'identità. Un operatore di agenti viene identificato da dove pubblica le proprie chiavi, il che lega la firma a un dominio controllato dall'operatore. La rotazione delle chiavi funziona pubblicando una nuova chiave accanto a quella vecchia e poi rimuovendo la vecchia.

I siti che verificano devono gestire le directory con attenzione: fare cache seguendo le normali regole HTTP, impostare limiti di dimensione e timeout e evitare il recupero da indirizzi di rete privati. Sono considerazioni ingegneristiche standard e sono uno dei motivi per cui molti team preferiscono un componente che esegua la verifica per loro.

Cosa prova una firma valida e cosa non prova

Questa è la sezione più importante per chi scrive policy di prodotto.

Una firma valida prova:

• La richiesta è stata firmata dal possessore di una specifica chiave privata.
• Quella chiave è pubblicata in una URL di directory controllata dall'operatore.
• Le parti firmate della richiesta non sono state modificate durante il transito e la firma è entro la sua finestra di validità.

Una firma valida non prova:

• Che l'agente sia autorizzato a eseguire l'azione. Essere identificabile non equivale ad avere il permesso. Vedi autorizzazione dell'agente.
• Che l'agente agisca per una persona specifica o entro l'autorità che quella persona gli ha concesso. Vedi autorità delegata.
• Che l'operatore sia affidabile o che l'agente si comporti bene. La reputazione è esplicitamente fuori perimetro per il gruppo di lavoro.
• Qualsiasi cosa sulle richieste che non sono firmate. Il traffico non firmato richiede comunque una propria gestione.

Trattate una firma valida come una forte evidenza di chi ha inviato una richiesta, poi lasciate che il vostro controllo degli accessi decida che cosa quel mittente può fare.

Cosa dovrebbero fare i team di prodotto

Non dovete aspettare un RFC per pianificare. Il traffico di agenti firmati è qualcosa per cui potete prepararvi già ora, sapendo che alcuni dettagli del draft potrebbero cambiare.

1. Misurate prima di decidere

Capite quanta parte del vostro traffico è automatizzata, quali route usano gli agenti e quanta parte di essa è firmata. Iniziate in observation mode così la misurazione non cambia nulla per i vostri utenti.

2. Separate le evidenze dalla policy

Registrate ciò che dice l'evidenza, verified, declared, inferred o unknown, separatamente da ciò che decidete di fare. In questo modo le policy restano leggibili e potete irrigidirle o allentarle senza reimplementare la strumentazione. La voce evidence basis spiega i quattro livelli.

3. Date agli agenti verified un percorso migliore

Dove ha senso, servite agli agenti verified contenuti strutturati o un flusso adatto agli agenti invece di pagine pensate per le persone. La guida su servire contenuti strutturati agli agenti AI copre i pattern.

4. Mantenete l'autorizzazione nel vostro codice

Usate la firma per sapere chi sta chiedendo. Usate i permessi, gli scope e le conferme già esistenti per decidere che cosa può fare. Le azioni ad alto impatto possono richiedere comunque una conferma umana, chiunque abbia firmato la richiesta. Vedi proteggere le azioni sensibili senza bloccare gli agenti.

5. Pianificate per il traffico non firmato e Unknown

Il supporto alla firma varia tra agenti e strumenti, quindi aspettatevi per un certo periodo una combinazione di richieste firmate e non firmate. Decidete per ciascun route che cosa succede al traffico declared, inferred e Unknown, invece di scegliere una sola regola valida per tutto il sito. La guida su gestire il traffico Unknown spiega il percorso.

Come Proof of Actor usa Web Bot Auth

Proof of Actor indica alla vostra applicazione chi o cosa sta agendo in ogni interazione, Human, Human + AI, Agent o Unknown, e specifica la base dell'evidenza. Le firme Web Bot Auth sono una delle sue fonti di evidenza più forti.

Quando un agente firma la propria richiesta con HTTP Message Signatures, Proof of Actor verifica la firma rispetto alla chiave pubblicata dall'operatore. Se il controllo supera, il risultato riporta una base verified, insieme alle evidenze che il vostro team può esaminare. Se un client si limita a dichiararsi in un header, il risultato è declared. Se la conclusione si basa su segnali comportamentali o contestuali, viene etichettata come inferred. Se l'evidenza non è sufficiente, il risultato è Unknown.

La vostra applicazione decide cosa fare con quel contesto. Le policy sono scritte per route, per classe di attore e per base, con esiti come allow, adapt, challenge, review e rate-limit. Nulla viene imposto di default: vedete in anteprima una policy sul traffico reale e la applicate route per route, nel vostro codice.

I team fondatori possono raccogliere evidenze tramite middleware Node.js, Next.js, un'integrazione edge, un collector del browser su pagine approvate, la HTTP API generica o un'integrazione MCP server. Vedi integrazioni e la guida su verificare richieste di agenti firmate per i passaggi pratici.

Proof of Actor segue lo stesso limite dello standard: una firma verified vi dice quale chiave ha firmato la richiesta, non se l'agente sia autorizzato. L'autorizzazione resta nelle vostre mani. La pagina evidence and limits descrive esattamente che cosa ogni risultato può e non può supportare.

Iniziare

Proof of Actor è in private beta. I team selezionati del Founding Developer Program possono ricevere fino a 12 mesi di accesso gratuito entro limiti di utilizzo concordati, senza fatturazione automatica. Richiedi l'accesso anticipato e indicaci quali route prevedete che gli agenti firmati utilizzino e cosa volete farne.