Gli agenti invisibili sono già arrivati sul tuo sito

Un agente invisibile implica un'operazione di automazione che viene effettuata tramite un normale browser o una sessione cliente senza fornire un'identità dell'agente verificabile. Può trattarsi di un assistente legittimo che agisce per conto di un cliente, un agente non autorizzato che oltrepassa il suo mandato o uno strumento automatizzato per scopi dannosi che imita il comportamento degli agenti. 

Quando si svolgono attività umane e automatizzate all'interno della stessa sessione autenticata, distinguere le due attività diventa complicato. Senza un'identificazione esplicita degli agenti, le aziende devono fare affidamento su segnali comportamentali e tecnici che non sempre dicono tutta la verità: se allenti i controlli per consentire l'accesso agli agenti legittimi, rischi di esporre le tue attività aziendali agli strumenti automatizzati per scopi dannosi; se invece li rendi più rigorosi, rischi di bloccare le operazioni autorizzate dai clienti. 

Nella maggior parte della storia della gestione dei bot, ogni automazione veniva annunciata come un qualcosa che valeva la pena adottare. I crawler di ricerca hanno pubblicato i loro agenti utente e i loro intervalli IP. Ad esempio, un sito poteva cercare Googlebot, verificarne l'autenticità e trattarlo in modo diverso rispetto a uno scraper anonimo. Questo meccanismo funzionava perché l'operatore del bot desiderava essere riconosciuto.

Gli agenti destinati ai consumatori hanno involontariamente compromesso tale meccanismo perché sono stati progettati per utilizzare il web esattamente come farebbe una persona: gestiscono un browser, navigano tra le pagine, compilano moduli e superano gli ostacoli proprio come farebbe un essere umano. 

• Muse viene eseguito in una macchina virtuale nel cloud di Meta con un browser integrato. 

• Instinct mantiene un desktop cloud persistente e lo gestisce con le credenziali memorizzate dell'utente, inclusi i dettagli relativi ai programmi di e-mail e pagamento. 

• Dots viene eseguito come agente cloud di OpenAI. 

Dal punto di vista del server, ciascuna sessione è una sessione del browser: La stringa User-Agent indica il browser, mentre il suo comportamento segnala se si tratta o meno di uno strumento automatizzato.

I rapporti vengono presentati in due modi, a seconda che l'agente operi nel settore bancario o in quello del commercio.

Bloccare ogni agente è la risposta più rapida e più facile da difendere internamente. Al momento dell'accesso e per il trasferimento di denaro, anche il blocco può risultare la decisione più appropriata per garantire la sicurezza al momento.  Se applicato a un intero sito, tuttavia, il blocco non è più una decisione per la sicurezza, ma acquista una valenza commerciale. Se l'agente sta agendo per un cliente che vuole acquistare qualcosa, il blocco finisce per ricadere su quel cliente. Gli acquirenti che si imbattono nel blocco non giungono alla conclusione che il loro agente abbia bisogno di credenziali migliori, ma si rivolgono, invece, a un sito che funziona.

L'accesso in sola lettura rappresenta una soluzione più ponderata e solida, sebbene risponda a un quesito più circoscritto di quanto possa sembrare. Accedere ad un account anche in sola lettura non è un'operazione priva di rischi se l'agente, basandosi su quanto ha letto, compie azioni in altri sistemi; esistono infatti numerose azioni utili che non rientrano né nella semplice lettura né nel trasferimento di denaro, come effettuare una prenotazione, modificare un appuntamento, cambiare un indirizzo o riscattare un premio. L'accesso in sola lettura consente di guadagnare tempo, senza però stabilire una policy definitiva in merito.

Una singola categoria di bot basati sull'AI non può essere oggetto di una policy uniforme perché il traffico che vi rientra persegue obiettivi contrapposti. Un crawler che raccoglie le descrizioni dei tuoi prodotti per addestrare un modello, un crawler di ricerca che indicizza il tuo sito affinché il tuo brand appaia in una risposta generata dall'AI e un assistente che recupera una singola pagina perché un tuo cliente ha posto una domanda rappresentano tre tipologie di interazione fondamentalmente diverse.

Ad agosto 2026, abbiamo suddiviso questa categoria della nostra Akamai Bot Directory in tre sottocategorie:

• Crawler di addestramento dell'AI: raccolgono contenuti su vasta scala per addestrare i modelli (ad es. GPTBot, ClaudeBot e Meta-ExternalAgent).

• Crawler di ricerca basata sull'AI: siti di indicizzazione per la ricerca basata sull'AI e citazioni dell'origine (ad esempio, OAI-SearchBot, Claude-SearchBot e PerplexityBot).

• Agenti e strumenti che raccolgono i dati dell'AI: raggiungono una pagina in tempo reale per rispondere a una domanda o completare un'attività (ad esempio, ChatGPT-User, ChatGPT Agent, GoogleAgent-Mariner e agenti invisibili sospetti).

Questa suddivisione offre alle aziende un controllo più granulare su azioni che, altrimenti, risulterebbero in contraddizione tra loro: limitare i crawler di addestramento per proteggere i contenuti che l'organizzazione non ha concesso in licenza; adottare i crawler di ricerca in modo che i contenuti rimangano visibili nelle risposte dell'AI; e trattare gli agenti in tempo reale come traffico generato dai clienti: una policy per ciascuna categoria, definita dall'azienda.

Anche la visibilità deve estendersi oltre il catalogo. Il traffico che preoccupa una banca non è quello relativo alla semplice navigazione, bensì quello che avviene dopo aver effettuato l'accesso. Monitorare le attività degli agenti nelle sessioni autenticate è un tipo di misurazione diverso rispetto al tracciamento di queste attività sulle pagine dei contenuti; un'azienda ha bisogno di entrambe queste prospettive per poter iniziare a gestire la propria esposizione al rischio.

Le categorie rivelano il tipo di traffico ricevuto. La questione successiva riguarda il modo con cui si ottengono informazioni su ciascun agente e, a tal proposito, esistono due risposte molto diverse.

Alcuni agenti si dichiarano in un modo che può essere controllato: pubblicano una chiave, firmano le proprie richieste e possono essere verificati sull'edge anziché limitarsi a far fede sulla loro parola. Questi agenti sono noti e, in quanto tali, possono portare con sé la propria policy (anche al momento del pagamento) poiché il loro riconoscimento non dipende da ciò che può essere copiato.

Tutto il resto viene invece dedotto. Attribuiamo una classificazione agli agenti basandoci su caratteristiche osservate e li etichettiamo come "sospetti"; ecco perché nei rapporti compare una dicitura del tipo "Muse Agent (sospetto)" anziché un'identità confermata. Questa etichetta è davvero utile perché indica che un agente sta accedendo al tuo sito, fornisce una stima del volume di tale traffico e mostra verso quali risorse è diretto. Tuttavia, non garantisce che una richiesta successiva, che presenta lo stesso schema, provenga dallo stesso agente; pertanto, basare una policy su un simile presupposto porterà, prima o poi, a concedere l'accesso a risorse che non intendevi rendere disponibili

La valutazione dei rischi comportamentali è ciò che resta quando non è possibile risalire all'identità dell'utente; si tratta di un meccanismo di controllo che rimane efficace anche quando gli agenti utilizzano tecniche ingannevoli. Analizzando le dinamiche di una sessione anziché le dichiarazioni fornite dall'agente, l'analisi comportamentale è in grado di smascherare sia un software progettato per simulare un browser, sia un bot creato per apparire come un normale acquirente. 

È anche per questo motivo che, talvolta, gli agenti legittimi vengono bloccati al momento del pagamento. Questo risultato indica che il sistema funziona correttamente come previsto: finché gli agenti non saranno in grado di autenticarsi, una parte del loro traffico legittimo finirà nel gruppo dei dati non verificati.

La conseguenza pratica per un team addetto alla sicurezza è quella di considerare insieme i due segnali di categoria/etichetta e comportamento: la categoria e l'etichetta indicano chi sta effettuando l'accesso e con quale volume, mentre il comportamento rivela cosa sta facendo quella specifica sessione in un dato momento. Se, invece, vengono presi singolarmente, nessuno dei due sarà sufficiente per definire una policy.

La pagina di un catalogo e la pagina relativa ad un pagamento comportano rischi diversi. Un agente che legge le descrizioni dei prodotti per un cliente compie un'operazione che hanno sempre eseguito i browser standard. Solitamente, le aziende accettano questo traffico perché conduce ad una vendita e perché gli assistenti AI stanno diventando un canale attraverso cui individuare i prodotti. 

Tuttavia, lo stesso agente che inoltra un ordine compie un'azione che comporta lo spostamento di prodotti nell'inventario e di denaro, il che richiede lo stesso livello di controllo che viene applicato a qualsiasi altra automazione. La fase di login è più vicina al check-out che al catalogo e lo stesso vale per qualsiasi operazione in grado di modificare un account.

Pertanto, le azioni selettive, in pratica, stabiliscono: 

• Una policy per i contenuti, in cui è possibile monitorare o consentire la maggior parte del traffico dell'AI 

• Una policy distinta a livello di transazione, in cui ogni richiesta viene valutata per determinare se sia automatizzata, a prescindere da come si definisce. 

• Una policy politica a livello di autenticazione, in cui la questione non è se la sessione sia automatizzata, bensì se la persona che la sta utilizzando sia effettivamente il titolare dell'account e se si tratti di un'azione riconoscibile

In questo modo, il risultato è simile a quello che la maggior parte dei retailer già vede: un agente può sfogliare un catalogo per un cliente, ma viene bloccato quando tenta di acquistare un prodotto. Questo approccio mantiene aperto il percorso di individuazione, applica i controlli esistenti laddove si trova il denaro e lascia all'azienda la libertà di cambiare idea su un endpoint, senza dover rimettere in discussione l'intera policy.

La stessa logica risponde all'interrogativo che ci viene posto più di frequente, ossia come consentire ad uno specifico agente di completare un acquisto. La soluzione efficace non consiste in un'esenzione basata su una firma, poiché chiunque in grado di imitare tale firma finirebbe per ereditare l'esenzione stessa. In questo caso, gli strumenti che funzionano sono solo l'autenticazione e la verifica: dopo aver dimostrato la propria identità, un agente potrà disporre di una propria policy (anche al momento del pagamento) e l'azienda potrà concedere l'accesso a un soggetto verificato, anziché a un semplice schema di comportamento.

Ogni aspetto di questo problema ha origine dallo stesso tassello mancante: un agente non è in grado di dimostrare chi è o per chi lavora, quindi, i siti si affidano a deduzioni; tuttavia, le deduzioni non sono una base solida per i processi decisionali che le aziende intendono mettere in atto.

È questo tassello che attualmente è in fase di costruzione. Web Bot Auth, una bozza della IETF (Internet Engineering Task Force) da noi supportata, consente a un agente di firmare le proprie richieste, in modo che un sito possa verificarne l'origine crittograficamente anziché affidarsi a un'intestazione.. 

Il protocollo TAP (Trusted Agent Protocol) di Visa si basa sullo stesso approccio di firma utilizzato per i pagamenti, che abbiamo integrato per consentire agli esercenti di stabilire se un agente sta navigando o effettuando un pagamento e di collegare tale agente al consumatore che rappresenta. Know Your Agent di Skyfire aggiunge il livello di identità che lega un agente a un'organizzazione o a un utente che sono stati verificati e a cui noi abbiamo aderito, entrando a far parte dell'ecosistema Experian Agent Trust. A giugno 2026, abbiamo integrato questi elementi  in un sistema di sicurezza agentico, che include identità, osservabilità, fiducia e applicazione delle policy sull'edge.

Le quattro operazioni che devi effettuare subito sono: 

1. Scoprire chi è già entrato nel tuo sito

2. Impostare una policy per ciascun endpoint

3. Considerare la verifica come un modo per dare il proprio consenso

4. Lasciare aperta la porta per la navigazione mentre si stabilisce l'identità degli agenti

Le aziende che riusciranno a gestire bene questo aspetto non saranno quelle che avranno indovinato di quali agenti fidarsi, ma saranno invece quelle capaci di comprendere il tipo di traffico in arrivo, di stabilire quale parte di questo traffico sia possibile verificare e di intervenire su ciascun endpoint senza influire sulle altre attività aziendali.

Per discutere delle attuali categorie di traffico dell'AI e delle policy transazionali, contatta un esperto di Akamai.