L'allowlist degli user agent è uno dei pattern più antichi del web. Mantieni un elenco di nomi di crawler e client di cui ti fidi. Quando arriva una richiesta con un header User-Agent corrispondente, la fai passare, salti una challenge o servi una pagina più leggera. Si configura in pochi minuti e tutti nel team lo capiscono.
Questo pattern aveva più senso quando i principali visitatori automatizzati erano pochi crawler di ricerca e alcuni strumenti di monitoraggio. Oggi agent AI, assistenti e client automatizzati raggiungono le applicazioni in numeri crescenti, e molti di loro si presentano con un nome. Alcuni di quei nomi sono reali. Alcuni sono copiati. L'header non può dirti quali.
Proof of Actor adotta un approccio diverso. Tratta una stringa User-Agent per quello che è, una dichiarazione, e la riporta insieme a evidenze più forti quando tali evidenze esistono. Questa pagina spiega i limiti dell'allowlisting per nome, dove aiutano i controlli a livello di rete e come firme verificate e una classe Unknown esplicita cambiano il quadro.
La versione breve
| Allowlist degli user agent | Proof of Actor | |
|---|---|---|
| Evidenza principale | Un nome nell'header User-Agent | Firme, dichiarazioni e segnali, ciascuno etichettato con la propria base |
| Un client può falsificarlo? | Sì, inviando la stessa stringa | Una base dichiarata può essere rivendicata; una base verificata richiede la chiave di firma |
| Output | Nell'elenco oppure no | Human, Human + AI, Agent o Unknown, più una base |
| Traffico poco chiaro | Trattato come non incluso nell'allowlist, o consentito per impostazione predefinita | Unknown, con un fallback che scegli per route |
| Persone assistite dall'AI | Invisibili; usano browser ordinari | Una classe distinta, Human + AI, quando dichiarata o osservata |
| Manutenzione | Aggiornamenti manuali dell'elenco quando i nomi cambiano | Chiavi pubblicate dagli operatori degli agent; policy nel tuo codice |
| Predefinito all'installazione | Tutto ciò che l'elenco consente | Osservazione; nulla cambia finché non aggiungi una policy |
| Ideale per | Instradamento economico di client noti e corretti | Contesto dell'actor basato su evidenze per decisioni di prodotto e policy |
Il resto della pagina spiega ogni riga.
Perché l'allowlisting in base a User-Agent è falsificabile
L'header User-Agent è impostato dal client. Lo imposta un browser, lo imposta uno script, lo imposta un framework per agent. In HTTP nulla verifica che il valore sia vero. Se il tuo allowlist si fida di una stringa, chiunque copi quella stringa ottiene lo stesso trattamento.
Questo si chiama user agent spoofing, ed è comune per un motivo semplice: non costa nulla. Un scraper che vuole evitare una challenge deve solo prendere in prestito il nome di un crawler di cui ti fidi. Un client che si comporta male può dichiararsi come un assistente molto diffuso. Uno strumento legittimo può persino inviare una stringa browser generica perché lo ha fatto il default di una libreria.
Il risultato è che un allowlist degli user agent ha due modalità di fallimento:
- Falsa fiducia: un client non attendibile dichiara un nome attendibile e passa.
- Falso dubbio: un client legittimo invia una stringa inattesa o generica e fallisce.
Nessuno di questi fallimenti è visibile dalla sola header. Questo è il limite fondamentale, e nessuna manutenzione dell'elenco lo elimina.
A cosa serve ancora l'header
Nulla di tutto questo significa che dovresti ignorare le stringhe User-Agent. I crawler e gli agent corretti si presentano in modo onesto, e il nome è un indizio utile per routing, analytics e debugging. Ti dice ciò che un client afferma di essere.
Il posto giusto per questa informazione è come dichiarazione, valutata insieme ad altre evidenze, non come una chiave che sblocca l'accesso da sola. Proof of Actor la registra esattamente in questo modo.
Reverse DNS e liste IP: misure parziali
Molti team rafforzano un allowlist con controlli di rete. Aiutano, ed è utile capirli con precisione.
Verifica reverse DNS
Alcuni operatori di crawler documentano un processo di verifica: cerca il hostname per l'indirizzo IP della richiesta, controlla che appartenga al dominio dell'operatore, poi cerca quel hostname e conferma che risolva nello stesso IP. Quando questo andata-e-ritorno riesce, hai un'evidenza reale che la richiesta proveniva dall'infrastruttura dell'operatore.
I limiti sono pratici. Funziona solo per gli operatori che documentano e supportano questo processo. Aggiunge lookup DNS che devi mettere in cache. E ti dice qualcosa sulla rete, non su quale prodotto o agent abbia effettuato la richiesta su quella rete.
Range IP pubblicati
Altri operatori pubblicano gli intervalli IP usati dai loro client automatici. Confrontare una richiesta con quei range è veloce e fornisce un tipo di evidenza simile al reverse DNS. C'è una discussione in corso in IETF su un formato standard per pubblicare questi range, ma a novembre 2026 non esiste ancora uno standard definito, e la copertura dipende dalla scelta di ciascun operatore di pubblicare o meno.
Anche l'evidenza IP si indebolisce quando più agent girano su infrastruttura cloud condivisa, dietro proxy o dal dispositivo stesso di un utente. Un indirizzo cloud può ospitare molti client non correlati, e un agent che agisce dal browser di una persona appare come la rete di quella persona.
Cosa aggiungono i controlli di rete
Reverse DNS e liste IP trasformano alcune dichiarazioni in qualcosa di più forte per un sottoinsieme di operatori noti. Non coprono la lunga coda di agent e strumenti, e non aiutano affatto con le persone che lavorano insieme all'AI. Sono misure parziali: utili da usare, ma non sufficienti da sole.
Firme versus dichiarazioni
La forma di evidenza più forte è una firma crittografica. Con HTTP Message Signatures, definito in RFC 9421, un client firma parti selezionate di ogni richiesta con una chiave privata. Il verificatore recupera la chiave pubblica pubblicata dall'operatore e controlla la firma. Se la verifica riesce, la richiesta è stata firmata dal possessore di quella chiave e le parti firmate non sono state alterate durante il transito.
Il gruppo di lavoro IETF Web Bot Auth sta standardizzando il modo in cui i client automatici usano queste firme e pubblicano le loro chiavi. Il nostro approfondimento su Web Bot Auth per i team di prodotto copre lo stato attuale.
Proof of Actor usa una firma valida come evidenza verified. Una stringa User-Agent, un client hint o un'autodescrizione nel body di una richiesta contano come declared. I segnali comportamentali e contestuali contano come inferred e vengono etichettati così. Ogni risultato indica su quale base si fonda, così il tuo team non confonde mai un'affermazione con una verifica. Vedi la voce evidence basis per le definizioni complete.
C'è un limite che vale anche per le evidenze verificate. Una firma valida dimostra quale chiave ha firmato la richiesta. Non dimostra che l'agent sia autorizzato a fare ciò che sta chiedendo di fare. Questa è una questione di agent authorization, e resta nella tua applicazione.
Gestire Unknown invece di tirare a indovinare
Un allowlist costringe ogni richiesta in uno di due contenitori: nell'elenco oppure no. In pratica significa che il traffico poco chiaro riceve il valore del tuo default, e il default di solito viene scelto una volta sola per tutto il sito.
Proof of Actor tratta Unknown come un risultato di prima classe. Quando le evidenze non supportano una determinazione affidabile, lo dice invece di fare supposizioni. Le tue policy decidono poi che cosa significhi Unknown per ciascuna route:
- Sulle pagine di documentazione pubblica o di marketing, consentilo.
- Sugli endpoint di ricerca o di listing, consentilo con i tuoi limiti di rate standard.
- Sulle modifiche all'account, mantieni i controlli esistenti.
- Sulle azioni ad alto impatto, invialo in review o richiedi un segnale più forte.
La guida su gestire il traffico Unknown e la voce unknown classification illustrano i pattern. Monitorare nel tempo il tasso di Unknown ti dice anche quanta parte del tuo traffico poggia ancora su evidenze deboli.
E le persone assistite dall'AI?
Un allowlist degli user agent non dice nulla di una persona che usa un assistente AI dentro un browser ordinario. Il loro User-Agent è una normale stringa browser. Eppure molti prodotti vogliono riconoscere quell'interazione, per esempio per etichettare invii redatti con l'aiuto dell'AI o capire come gli utenti assistiti dall'AI si muovono nel onboarding.
Proof of Actor segnala queste interazioni come Human + AI quando l'assistenza è dichiarata o osservata tramite un'integrazione supportata. Non indovina dalla sola stile di scrittura. Leggi di più in AI-assisted interaction.
Passare da un allowlist a policy basate sulle evidenze
Non devi rimuovere il tuo allowlist fin dal primo giorno. Un percorso sicuro è questo:
- Installa in modalità osservazione. Proof of Actor non cambia nulla. Il tuo allowlist continua a funzionare.
- Confronta. Per ogni route, vedi quali richieste presenti nell'allowlist portano evidenze verificate, quali portano solo una dichiarazione e quali finiscono come Unknown.
- Anteprima delle policy. Bozza una policy che tratti in modo diverso agent verificati, agent dichiarati e Unknown, e visualizzane in anteprima l'effetto sul traffico reale.
- Applica route per route. Inizia dalle route in cui un nome falsificato sarebbe più rilevante.
- Mantieni l'allowlist come indizio. I nomi restano utili per routing e analytics, ma ora con la base visibile.
La guida su rollout sicuro di policy consapevoli dell'actor copre ogni passaggio, e verified automated requests spiega come si inseriscono i client firmati.
Quando un allowlist basta
Per routing a basso rischio, come servire una pagina più leggera a un crawler noto su contenuti pubblici, un allowlist degli user agent è spesso sufficiente. Il costo di un nome falsificato è basso.
Quando la decisione ha conseguenze, come saltare una challenge, esporre dati più ricchi o consentire una scrittura, vuoi evidenze che puoi verificare. È lì che entra Proof of Actor, lavorando insieme ai controlli di rete e ai controlli edge che già utilizzi.
Inizia
Proof of Actor è in private beta. I team fondatori selezionati possono ricevere fino a 12 mesi di accesso gratuito entro limiti di utilizzo concordati, senza fatturazione automatica. Richiedi accesso anticipato e facci sapere quali client inserisci oggi nell'allowlist e quali route vuoi proteggere con evidenze migliori.