Rilevamento di agenti AI per i website, con le evidenze dietro ogni risultato

Il tuo website ora ha più di un tipo di visitatore

Per gran parte della storia del web, un website poteva assumere un modello semplice: una persona apre un browser, naviga, e magari effettua l'accesso. Analytics, limiti di rate, flussi di onboarding e controlli di sicurezza erano tutti progettati attorno a quella persona.

Quel modello non descrive più il traffico reale. Oggi un singolo website serve persone che navigano da sole, persone che chiedono a un assistente AI di riassumere o compilare qualcosa per loro, agenti autonomi che leggono pagine e chiamano endpoint per conto di qualcun altro, e una lunga coda di crawler e script. I provider di AI documentano loro stessi diversi di questi visitatori: OpenAI, ad esempio, pubblica user agent separati per il suo search crawler, il crawler di training e il fetcher che visita le pagine quando un utente di ChatGPT pone una domanda (documentazione crawler di OpenAI), e Anthropic fa lo stesso per ClaudeBot, Claude-User e Claude-SearchBot (documentazione crawler di Anthropic). Alcuni di questi visitatori sono benvenuti. Alcuni richiedono un'esperienza diversa. Alcuni richiedono un esame più attento prima di poter fare qualcosa di sensibile.

La sfida è che molte di queste interazioni, a prima vista, sembrano simili. Un accesso ti dice quale account è in uso. Non ti dice se sta cliccando una persona, se un assistant sta agendo attraverso quella sessione o se un client automatizzato sta leggendo la tua pagina dei prezzi per un utente altrove. AI agent detection for websites serve a colmare questo divario con evidenze, così il tuo team può rispondere in modo appropriato a ciascun tipo di actor invece di trattare tutto il traffico allo stesso modo. Per una guida pratica sui segnali coinvolti, leggi come capire se il traffico del website proviene da agenti AI, e vedi il caso d'uso per i website per capire come appare su un sito di produzione.

Perché un singolo punteggio bot non basta

Molti strumenti rispondono a questa domanda con un solo numero: un bot score, un risk score, una percentuale che pretende di descrivere quanto un visitatore sia human. L'attrattiva è evidente. Un solo numero è facile da inserire in una regola.

Il problema è che un singolo numero nasconde il ragionamento. Quando un punteggio dice che una sessione è probabilmente automatizzata, il tuo team non può vedere se quella conclusione si basa su una firma verificata, su una stringa user-agent che chiunque può copiare o su un pattern che corrisponde anche a un dattilografo human molto veloce. Quando quel punteggio guida un blocco o una challenge, erediti ogni errore che commette senza alcun modo di spiegarlo a un cliente, a un collega o a un auditor.

Proof of Actor adotta un approccio diverso. Ogni risultato appartiene a una delle quattro classi chiare, spiegate in Human, AI-assisted o agent: una tassonomia per il traffico delle app, e ogni risultato indica su cosa si basa. Vedi conclusione ed evidenza insieme, il che significa che puoi fidarti dei risultati forti, mettere in discussione quelli deboli e costruire policy che rispecchino la qualità dell'evidenza.

Come rilevare agenti AI sul tuo website in quattro passaggi

Puoi iniziare a rilevare agenti AI sul tuo website con strumenti che hai già. Questi quattro passaggi sono neutrali rispetto al vendor e funzionano sia che tu usi Proof of Actor sia che non lo usi; il post del blog su come capire se il traffico del website proviene da agenti AI approfondisce ciascuno di essi.

1. Elenca gli agenti che si identificano da soli. Cerca nei log del tuo server o CDN i user agent che i provider di AI pubblicano. OpenAI documenta OAI-SearchBot, GPTBot e ChatGPT-User, e indica che ChatGPT-User visita le pagine quando un utente pone una domanda a ChatGPT invece di eseguire il crawling automaticamente. Anthropic documenta ClaudeBot, Claude-User e Claude-SearchBot. Questo ti dà una prima fotografia dichiarata del traffico degli agenti per route.
2. Verifica le dichiarazioni invece di fidarti della stringa. Un user agent è auto-dichiarato e facile da copiare. Confrontalo con il metodo di verifica del gestore: Google descrive una reverse DNS lookup seguita da una forward DNS lookup, oltre a file di intervallo IP pubblicati, per Googlebot (Google: verificare Googlebot); Bing descrive lo stesso controllo DNS reverse e forward per Bingbot (Bing: verificare Bingbot); OpenAI pubblica file di intervallo IP per ciascuno dei suoi user agent. Dove un client firma le proprie richieste con HTTP Message Signatures, definite in RFC 9421, verifica la firma rispetto alla chiave pubblicata dal gestore.
3. Etichetta ogni risultato con la sua evidenza e mantieni Unknown. Registra se ogni conclusione è verified, declared o inferred. Il traffico che non corrisponde ad alcun agente verified o declared e non mostra un chiaro pattern human dovrebbe essere etichettato Unknown, non forzato in human o bot. Questo è il passaggio che separa un report utile da un'ipotesi.
4. Osserva per route prima di agire. Suddividi i risultati per route e workflow per alcune settimane: contenuti pubblici, registrazione, impostazioni dell'account, API. Solo dopo scrivi una policy ristretta per la route in cui il contesto dell'actor conta di più, con un fallback esplicito per Unknown.

Proof of Actor automatizza questi passaggi dentro la tua applicazione: raccoglie i segnali che la tua integrazione può vedere, restituisce una classe con la sua base, tiene traccia di Unknown per route e lascia la policy al tuo codice.

Come Proof of Actor rileva gli agenti AI sui website

Proof of Actor è costruito attorno a un percorso semplice: i segnali che la tua integrazione può osservare, una classificazione con una base esplicita e una decisione che resta nelle tue mani. Puoi leggere il flusso completo nella pagina Come funziona. Ecco la versione breve.

Segnali dalla tua integrazione

Ogni integrazione vede ciò che il suo contesto consente. Un'integrazione server-side vede il contesto della richiesta, i dettagli del protocollo e, quando un client lo supporta, una firma della richiesta. Un'integrazione browser vede i segnali di interazione sulle pagine in cui gira. Un'applicazione può anche registrare le proprie dichiarazioni, ad esempio un utente che contrassegna contenuti come redatti con l'assistenza dell'AI, oppure un client agent che si nomina da solo.

Proof of Actor lavora con l'evidenza che è effettivamente presente. Non pretende di vedere cose che il tuo website non può osservare.

Quattro classi che significano qualcosa di specifico

Ogni interazione finisce in una delle quattro classi:

• Human: i segnali osservabili indicano un'interazione guidata da una persona.
• Human + AI: l'assistenza dell'AI è stata dichiarata, oppure osservata tramite un'integrazione supportata che può vederla.
• Agent: interazione automatizzata o originata da un agent, supportata da un'identità verificabile o da un'inferenza attentamente qualificata.
• Unknown: l'evidenza disponibile non supporta una determinazione affidabile.

Ogni classe ha una definizione chiara e un limite chiaro. Un risultato Human non è un'identità verificata. Un risultato Agent non è una dichiarazione che l'agent sia autorizzato. Un risultato Unknown non è un'accusa. Puoi leggere la tassonomia completa nella pagina Detection & Limitations.

Una base su ogni risultato

Accanto alla classe, ogni risultato riporta la sua base: verified, declared, inferred o unknown. Una richiesta che porta una firma valida da una chiave pubblicata è verified per quel controllo. Un client che si presenta come agent lo ha declared. Un pattern di comportamento coerente con l'automazione è un'inferenza. Questa distinzione è ciò che rende precise le tue policy. Un agent firmato verified su una route di sola lettura e un client self-declared su una pagina di impostazioni dell'account non dovrebbero essere gestiti allo stesso modo, e con Proof of Actor non devono esserlo. La voce del glossario base probatoria spiega ciascuna in maggiore dettaglio.

Cosa ottiene il tuo team: Detect, Understand, Route

Proof of Actor è un unico prodotto con tre funzionalità che lavorano insieme.

Detect

Raccogli i segnali dell'actor disponibili per la tua integrazione e separa le affermazioni verified dalle inferenze comportamentali. Il traffico Unknown resta visibile come categoria propria invece di essere assorbito in un'ipotesi. Sai sempre quali interazioni puoi descrivere con confidenza e quali richiedono più evidenze.

Understand

Vedi il tuo traffico di agenti AI nel contesto. Esplora i tipi di interazione per route e per tempo, segui i trend dell'attività human, AI-assisted, agent e unknown, e apri qualsiasi classificazione per vedere cosa è noto, cosa non è noto e su cosa si basa il risultato. Qui product, platform e security team ottengono una visione condivisa e spiegabile di chi sta usando il website.

Route

Usa le tue policy per allow, adapt, challenge, review o limitare interazioni specifiche. Fornisci una risposta strutturata a un agent verified che legge la tua documentazione. Mantieni l'esperienza standard per le sessioni guidate da persone. Richiedi un controllo più forte su una modifica sensibile dell'account quando le tue condizioni lo prevedono. Scegli un fallback esplicito per i risultati Unknown e per i timeout, route per route. L'enforcement avviene sempre nella tua applicazione, sotto policy confermate dal tuo team.

Progettato per integrarsi nel tuo website, non per sostituirlo

Proof of Actor si affianca agli strumenti che già utilizzi. Non sostituisce la tua autenticazione, il tuo modello di autorizzazione o i tuoi controlli anti-abuso esistenti. Aggiunge a essi il contesto dell'actor.

Una tipica integrazione website inizia sulle route in cui il contesto dell'actor conta di più: contenuti pubblici che gli agent leggono intensamente, flussi di registrazione e onboarding, impostazioni dell'account e altre azioni sensibili, e qualsiasi API che alimenta il sito. I team founding lavorano con i nostri engineer per scegliere quelle route, concordare i segnali inclusi e confermare come vengono gestiti i dati prima che venga rilasciato qualsiasi codice.

Poiché il livello decisionale vive nel tuo codice, resti tu a controllare l'esperienza. Puoi mostrare i risultati in una dashboard interna per settimane prima di cambiare qualsiasi regola, poi attivare una sola policy ristretta per una sola route, e poi espandere tutto quando i risultati avranno guadagnato la tua fiducia. La guida su gestire il traffico Unknown spiega come progettare queste prime regole.

Parti in modalità di osservazione

Il modo più rapido per ottenere valore dal rilevamento di agenti AI è iniziare osservando, non bloccando. In modalità di osservazione, Proof of Actor registra i risultati mentre il tuo website risponde esattamente come farebbe senza di esso. Il tuo team può poi confrontare le classificazioni con esiti che già comprende: ticket di supporto, integrazioni note, strumenti interni e i crawler che già riconosci.

Questo ti offre tre cose prima di qualsiasi enforcement:

1. Una baseline. Quanto del tuo traffico è guidato da persone, assistito dall'AI, guidato da agent o unknown, per route.
2. Fiducia nell'evidenza. Quali segnali sono forti sul tuo website e dove la copertura deve crescere.
3. Policy migliori. Regole progettate attorno a pattern reali invece che a ipotesi, con i falsi positivi esaminati prima che qualcuno ne sia influenzato.

Quando una policy è pronta, la abiliti per il workflow specifico per cui è stata progettata, e mantieni la possibilità di modificarla in qualsiasi momento.

Perché il rilevamento basato sull'evidenza vince sui punteggi opachi

I website servono già agent, assistant e persone che lavorano con AI fianco a fianco. I team che gestiscono bene questa situazione non saranno quelli con i filtri più aggressivi. Saranno quelli che sanno spiegare le proprie decisioni.

I risultati basati sull'evidenza ti danno questa spiegazione. Quando un support agent chiede perché un utente ha visto un passaggio di verifica aggiuntivo, puoi indicare l'evidenza e la policy applicata. Quando un operator di agent chiede perché le sue richieste firmate hanno ricevuto una risposta strutturata, puoi mostrare la base verified. Quando l'evidenza è debole, il risultato dice Unknown, e il tuo fallback lo gestisce nel modo che hai scelto deliberatamente.

Questo approccio scala anche con il web. Man mano che più operator di agent firmano le proprie richieste e lavori di standardizzazione come il gruppo di lavoro IETF Web Bot Auth, incaricato di standardizzare l'autenticazione crittografica per client automatizzati, si basano su HTTP message signatures, una parte maggiore del tuo traffico passa da inferred o unknown a verified, e le tue policy diventano più precise senza dover essere riscritte.

Unisciti al founding developer program

Proof of Actor è in private beta con un piccolo gruppo di team applicativi. I founding developer selezionati possono ricevere fino a 12 mesi di accesso gratuito, entro limiti di utilizzo concordati, in cambio di feedback pratico sul prodotto. Ottieni supporto diretto all'integrazione dai nostri engineer, accesso anticipato alle funzionalità man mano che diventano disponibili e una reale influenza su ciò che costruiremo dopo.

Se il tuo website serve persone, utenti assistiti dall'AI e agent, e vuoi sapere chi lo sta usando prima di decidere cosa succede dopo, richiedi l'accesso anticipato. Raccontaci del tuo website e dell'interazione che vuoi comprendere di più, e valuteremo se è adatto alla beta attuale.

Vuoi vedere prima i dettagli? Esplora Proof of Actor, leggi come funziona, oppure verifica esattamente cosa l'evidenza può e non può stabilire.

Fonti

• RFC 9421: HTTP Message Signatures, IETF, February 2024.
• Web Bot Auth (webbotauth) working group charter, IETF.
• Overview of OpenAI crawlers, OpenAI.
• Does Anthropic crawl data from the web, and how can site owners block the crawler?, Anthropic.
• Verifying Googlebot and other Google crawlers, Google Search Central.
• How to verify that Bingbot is Bingbot, Bing Webmaster Blog.