Il browser AI di Perplexity ha messo in crisi l’autenticazione web

Il browser Comet di Perplexity usa i cookie di sessione dell’utente senza passare da OAuth

Sessantatré miliardi di dollari l’anno. È la perdita stimata da traffico non valido su tutti i canali media, con un tasso di invalidità dell’8,5% secondo l’analisi di PPC Land sul caso Perplexity. Ma dietro questa cifra c’è un problema tecnico molto più insidioso del bot tradizionale che martella le API: un browser come Comet di Perplexity è letteralmente indistinguibile da un utente umano nei log dei server. Il vero nodo non è il volume del traffico automatizzato — è che i modelli di autenticazione del web sono stati progettati per riconoscere sessioni, non intenzioni. E questo, oggi, è un problema.

Il grimaldello del login

Il caso legale tra Amazon e Perplexity porta questa questione tecnica in aula. Già a novembre 2024, Amazon aveva citato in giudizio Perplexity, e la causa di Amazon contro Perplexity ha ora coinvolto anche il Ninth Circuit. La questione centrale che il tribunale si è trovato ad affrontare è quasi filosofica: il browser Comet accede all’account Amazon dell’utente con il permesso di quest’ultimo, ma senza autorizzazione di Amazon. Come ha scritto il tribunale stesso, Amazon «ha fornito prove solide che Perplexity, tramite il browser Comet, accede — con il permesso dell’utente Amazon ma senza autorizzazione da parte di Amazon — all’account protetto da password dell’utente».

Per chi lavora su sistemi di autenticazione, questa distinzione non è un cavillo legale: è una falla architettonica. Il protocollo OAuth, che governa la delega delle autorizzazioni sul web moderno, prevede che un servizio di terze parti ottenga un token di accesso esplicitamente approvato dal provider (in questo caso Amazon) tramite un flusso di consenso standardizzato. Comet non fa questo. L’agente opera dentro la sessione autenticata dell’utente — usa i cookie di sessione esistenti, il token JWT già presente nel browser — senza mai presentarsi ad Amazon come entità separata che richiede permessi. È come se qualcuno prestasse le proprie chiavi di casa a un assistente: l’assistente può entrare, ma il condominio non sa chi è. Il paradosso è netto: l’agente è autorizzato dall’utente, ma non dal servizio. Chi ha torto?

La risposta dipende da come si interpreta il contratto implicito tra utente e piattaforma. I Termini di Servizio di Amazon vietano l’accesso automatizzato, ma l’utente — che ha accettato quei termini — sta delegando un’azione che potrebbe compiere manualmente. Dal punto di vista tecnico, il traffico generato da Comet è semanticamente identico a quello umano: stesso User-Agent, stessa sequenza di richieste HTTP, stesso fingerprint TLS. Come segnala il report di The Register, browser AI come Comet e strumenti di sviluppo come Firecrawl o Browserless sono ormai indistinguibili dagli umani nei log dei siti. Nessun rate limiter, nessun captcha, nessuna euristica comportamentale riesce a separarli con certezza.

A rendere il quadro ancora più complesso, il 29 aprile 2026 la Digital Content Next (DCN) ha depositato una memoria amicus curiae a sostegno di Amazon. Secondo il sostegno degli editori ad Amazon documentato da Press Gazette, DCN argomenta che concedere agli agenti AI un accesso non regolamentato a contenuti protetti minaccia l’accesso pubblico alle informazioni erodendo gli investimenti nel giornalismo. Il General Invalid Traffic — il traffico automatizzato rilevabile — è cresciuto dell’86% anno su anno nella seconda metà del 2024. Non è un trend trascurabile.

La prossima frontiera dell’autenticazione

Per chi progetta software, la domanda pratica è immediata: come si autorizza un agente in modo che il servizio possa distinguere automazione legittima da scraping? Il mercato degli agenti AI è già affollato. Già a gennaio 2025, OpenAI aveva annunciato con il lancio di Operator un agente capace di navigare il web ed eseguire compiti per conto dell’utente, competitor diretto di Comet nel segmento dei browser agentici. La competizione non farà che accelerare il deployment di questi strumenti, e con esso la pressione sui modelli di autenticazione esistenti.

Il problema strutturale è che il web non ha mai avuto un meccanismo nativo per identificare gli agenti come classe distinta di client. HTTP conosce User-Agent, ma è un campo auto-dichiarato e non verificabile. OAuth gestisce la delega, ma presuppone che il provider voglia partecipare al flusso. Quello che manca è uno strato intermedio: un protocollo che consenta all’utente di delegare in modo verificabile a un agente specifico, con scope granulari, e che il servizio possa validare crittograficamente senza dover riconoscere ogni singolo agente a priori. Alcune proposte — come i model context protocol token o le estensioni ai flussi PKCE — si muovono in questa direzione, ma nessuno standard è emerso.

Il prossimo aggiornamento di Chrome potrebbe chiederti il permesso esplicito prima di eseguire un agente su un sito che richiede autenticazione? Tecnicamente non è impossibile: il browser sa già distinguere le richieste originate da script da quelle originate dall’interazione umana diretta. Basterebbe esporre questa informazione al server in modo verificabile e opt-in. Ma richiede coordinamento tra browser vendor, piattaforme e sviluppatori di agenti — esattamente il tipo di lavoro lento e poco spettacolare che il settore tende a rimandare finché qualcuno non finisce in tribunale.

Il caso Perplexity non è solo una battaglia legale: è la prova che il web sta entrando in una fase in cui il token di sessione non basta più come unità di fiducia. Chi costruisce servizi autenticati deve iniziare a ragionare su un modello in cui l’identità del client include anche la sua natura — umano, agente, automazione — e in cui quella natura sia verificabile, non semplicemente dichiarata. Progettare per gli agenti non significa bloccarli: significa riconoscerli.