Il traffico che nessuno riesce a nominare
Osserva da vicino i log di un'applicazione e troverai richieste che resistono a ogni spiegazione. Provengono da client senza contesto del browser. Le loro stringhe user-agent sono generiche, vuote o copiate da un browser diffuso. Non firmano le loro richieste. Non dicono chi le ha inviate. Alcune sono script innocui. Alcune sono agent che lavorano per utenti reali. Alcune sono strumenti che preferiresti non servire affatto.
Questo è unknown automated traffic, e la maggior parte dei team lo gestisce in uno di due modi. O viene conteggiato silenziosamente come umano, falsando le analisi e lasciando passare attività rischiose, oppure viene trattato come ostile per impostazione predefinita, bloccando utenti e agent legittimi insieme a tutto il resto. Entrambi gli approcci condividono lo stesso difetto: sostituiscono l'assenza di evidenze con un'ipotesi.
Proof of Actor adotta la prospettiva opposta. Se le evidenze non supportano una determinazione affidabile, la risposta corretta è Unknown, e Unknown deve essere visibile, misurabile e gestito intenzionalmente. Il post del blog perché Unknown è un risultato valido per il traffico AI espone il caso completo.
Perché Unknown è un risultato di prima classe
Proof of Actor classifica ogni interazione in una di quattro classi: Human, Human + AI, Agent o Unknown. Unknown non è uno stato di errore né una lacuna del prodotto. È un risultato deliberato con un significato preciso: le evidenze disponibili non supportano una determinazione affidabile.
Questa onestà ha vantaggi pratici.
- Le tue analisi restano accurate. I conteggi di Human e Agent includono solo le interazioni con evidenze a supporto, quindi significano ciò che dichiarano.
- La tua copertura è misurabile. La quota di Unknown su ciascuna route ti dice esattamente dove servono più evidenze.
- Le tue policy sono più sicure. I casi incerti confluiscono in un fallback che hai scelto, invece di essere trattati in silenzio come affidabili o bloccati per supposizione.
Unknown non viene mai convertito in Human e non viene mai trattato come malevolo per impostazione predefinita. Puoi approfondire nella voce del glossario classificazione Unknown, in Detection & Limitations e in perché Unknown è un risultato valido per il traffico AI. I casi d'uso websites e APIs mostrano come i team impostano i fallback di Unknown nella pratica.
Da dove proviene il traffico automatizzato sconosciuto
Capire le origini aiuta a decidere come gestirlo.
Client automatizzati non firmati
La firma delle richieste con HTTP Message Signatures, definita in RFC 9421, è opzionale, e il gruppo di lavoro IETF Web Bot Auth sta ancora standardizzando il modo in cui i client automatizzati dovrebbero autenticarsi in questo modo. Senza una firma, l'identità di un client dipende da ciò che sceglie di dire di sé stesso.
User agent copiati o generici
Le stringhe user-agent sono facili da impostare. Un client che dichiara di essere un browser o un crawler noto potrebbe esserlo davvero, oppure potrebbe imitarlo. La voce user-agent spoofing spiega perché questo header da solo non può sostenere una classificazione. È anche il motivo per cui i motori di ricerca documentano metodi di verifica separati: Google descrive controlli DNS inversi e diretti più intervalli IP pubblicati per verificare Googlebot, e Bing descrive lo stesso controllo DNS per verificare Bingbot.
Route senza integrazione
Se una route non ha un'integrazione lato browser e nessun contesto lato server oltre al minimo indispensabile, semplicemente c'è meno da osservare. Unknown su quelle route è un segnale di copertura, non di minaccia.
Evidenze mancanti o in ritardo
Un timeout, uno script bloccato o una richiesta incompleta possono lasciare un risultato senza evidenze sufficienti. Proof of Actor lo riporta con onestà invece di colmare il vuoto.
Come Proof of Actor rende gestibile Unknown
Proof of Actor organizza il proprio lavoro in tre capacità. Ognuna aiuta con il traffico automatizzato sconosciuto.
Detect: mantieni separato Unknown
I segnali vengono controllati e etichettati per base: Verified, Declared, Inferred o Unknown. Quando non supportano una determinazione, il risultato è Unknown con un riepilogo di ciò che era e non era disponibile. Nulla viene indovinato dentro un'altra classe.
Understand: vedi dove vive Unknown
La vista Understand mostra Unknown in ogni scomposizione, per route e nel tempo. Puoi vedere quali route hanno più attività sconosciuta, come cambia dopo aver aggiunto un'integrazione e quali evidenze erano presenti per le singole interazioni. Questo trasforma una preoccupazione vaga in una mappa concreta.
Route: scegli il fallback per route
Route diverse meritano fallback diversi. Un punto di partenza ragionevole per molte applicazioni:
- Pagine pubbliche e documentazione: consenti Unknown con i tuoi limiti di rate standard.
- Registrazione e onboarding: mantieni i controlli esistenti e aggiungi review solo quando le tue condizioni lo richiedono.
- Modifiche all'account e altre azioni sensibili: affidati all'autenticazione esistente e ai controlli di step-up, mai a una supposizione sull'actor.
- Operazioni API ad alto impatto: richiedi le credenziali o i controlli più forti che la tua API già supporta.
La guida su come gestire il traffico sconosciuto illustra la progettazione di questi fallback, incluse le scelte fail-open e fail-closed per ciascun livello di rischio.
Ridurre Unknown nel tempo
L'obiettivo non è eliminare Unknown da un giorno all'altro. È renderlo più piccolo ogni mese, per i motivi giusti.
- Aggiungi integrazioni dove conta. Un'integrazione browser sulle pagine chiave e un'integrazione lato server sulle route chiave aumentano le evidenze disponibili.
- Supporta le richieste firmate. Man mano che gli operatori di agent adottano HTTP message signatures, il traffico che era Unknown diventa traffico Agent verificato.
- Registra le dichiarazioni nella tua app. Quando la tua applicazione sa che è coinvolta assistenza AI, dillo. Quell'evidenza è precisa ed economica.
- Offri agli agent una porta d'ingresso. Pubblicare un percorso strutturato per gli agent li incoraggia a identificarsi invece di mimetizzarsi.
Poiché Proof of Actor traccia Unknown per route, puoi vedere ciascuno di questi cambiamenti nei numeri.
Come funziona
Ogni interazione segue lo stesso percorso evidence-first, descritto per intero in Come funziona: la tua applicazione riceve una richiesta o un evento, l'integrazione raccoglie i segnali disponibili in quel contesto, i segnali vengono normalizzati e classificati con una base esplicita, il risultato viene registrato per l'analisi e la tua applicazione applica la propria policy oppure si limita a osservare.
Timeout e telemetria mancante vengono gestiti esplicitamente. La tua integrazione usa il fallback che hai scelto per quella route e il risultato non viene mai promosso a Human perché mancavano evidenze.
Come appare un buon risultato dopo alcuni mesi
I team che gestiscono bene il traffico automatizzato sconosciuto tendono a raggiungere lo stesso stato sano. Unknown è una quantità nota su ogni route importante, tracciata nella stessa dashboard dell'attività umana e degli agent. Ogni route ha un fallback scritto che i team di prodotto, platform e security hanno concordato insieme. Il traffico Agent verificato cresce man mano che più operatori firmano le proprie richieste, e quegli agent vengono serviti attraverso un percorso strutturato invece di fare scraping delle pagine. Le azioni sensibili sono protette dall'autenticazione e dai controlli di step-up di cui l'applicazione già si fida, con il contesto dell'actor come input aggiuntivo e non come gatekeeper.
La cosa più importante è che nessuno sta indovinando. Quando qualcuno chiede quanta parte del traffico della settimana scorsa fosse automatizzata, la risposta arriva con la sua base: questa parte verified, questa parte declared, questa parte inferred e questa parte ancora Unknown. È un numero su cui un team può pianificare. Cambia anche la conversazione con la leadership, perché la domanda smette di essere se i bot siano un problema e diventa quali route meritano più evidenze e quali fallback devono essere rifiniti.
Parti in modalità di osservazione
Proof of Actor non blocca nulla per impostazione predefinita. In modalità di osservazione, i risultati vengono registrati mentre la tua applicazione risponde esattamente come prima. Il tuo team vede quanta parte del traffico automatizzato sconosciuto riceve ogni route, la confronta con gli esiti che già conosci e progetta i fallback in base a schemi reali. Le policy vengono abilitate una route alla volta, solo quando il tuo team è sicuro che siano adatte.
Unisciti al founding developer program
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, in cambio di feedback pratico sul prodotto, con supporto diretto all'integrazione da parte dei nostri ingegneri.
Se il traffico automatizzato sconosciuto sta offuscando le tue analisi o le tue decisioni di sicurezza, richiedi l'accesso anticipato. Raccontaci della tua applicazione e delle route in cui Unknown è più importante.
Esplora Proof of Actor, leggi come funziona oppure vedi che cosa le evidenze possono stabilire.
Fonti
- RFC 9421: HTTP Message Signatures, IETF, February 2024.
- Web Bot Auth (webbotauth) working group charter, IETF.
- Verifying Googlebot and other Google crawlers, Google Search Central.
- How to verify that Bingbot is Bingbot, Bing Webmaster Blog.