Il 4 agosto 2026, la Corte d'Appello del Nono Circuito degli Stati Uniti ha annullato il divieto preliminare che da marzo impediva all'agente browser Perplexity Comet di accedere agli account degli utenti su Amazon. Formalmente si tratta di una controversia tra due aziende riguardo agli acquisti tramite intelligenza artificiale. In realtà, è la prima decisione di appello che risponde a una domanda importante ben oltre il commercio degli agenti: chi esattamente "ottiene accesso" a un server altrui quando una richiesta è inviata da un'automazione. E la risposta della corte si è inaspettatamente basata non sul diritto, ma sull'architettura di rete.
Cosa è successo: dalla causa all'annullamento del divieto
La cronologia della controversia è la seguente:
- Novembre 2025 — Amazon presenta una causa contro Perplexity AI, citando il Computer Fraud and Abuse Act (CFAA) federale e il suo equivalente californiano. L'accusa: l'agente Comet accede agli account degli utenti, visualizza i prodotti e avvia acquisti, ovvero opera in una zona protetta da password senza autorizzazione da parte della piattaforma stessa.
- Antefatti — secondo Amazon, l'azienda ha avvertito Perplexity almeno cinque volte a partire da novembre 2024, a agosto 2025 ha imposto una barriera tecnica, e Perplexity ha rilasciato un aggiornamento che la eludeva entro un giorno. Un'altra accusa: l'agente si mascherava come una normale sessione di Google Chrome.
- 9 marzo 2026 — il giudice Maxine Chesney (Distretto Settentrionale della California) emette un divieto preliminare e ordina la distruzione dei dati ottenuti da Amazon. La sua formula: l'accesso avveniva con il permesso dell'utente Amazon, ma senza autorizzazione da parte di Amazon.
- 4 agosto 2026 — il Nono Circuito (caso n. 26-1444) annulla il divieto: è improbabile che Amazon vinca nel merito delle accuse CFAA.
Amazon ha dichiarato di non essere d'accordo con la decisione e continuerà la controversia. Perplexity ha risposto che difenderà il diritto degli utenti di scegliere qualsiasi intelligenza artificiale. La questione, nel frattempo, non è scomparsa: il processo di primo grado continua, e Amazon può chiedere una revisione o andare oltre.
Passo chiave: l'agente è uno strumento, non una persona
Il CFAA punisce l'accesso a un "computer protetto" senza autorizzazione. L'intera controversia si è ridotta a un solo verbo: chi ha compiuto l'atto di accesso. Amazon sosteneva — Perplexity, perché era il suo agente a operare sulla piattaforma. Perplexity rispondeva — l'utente, che ha dato istruzioni all'agente.
La Corte d'Appello ha adottato la seconda posizione e l'ha formulata chiaramente: per quanto avanzato possa essere l'agente, ai fini della legge "è uno strumento, non una persona". Quando un utente incarica un agente di fare qualcosa su Amazon.com, l'accesso ai computer di Amazon è effettuato proprio dall'utente.
Questa è una logica continuazione della linea della Corte Suprema nel caso Van Buren v. United States (2021), che ha ristretto il CFAA: la legge punisce l'intrusione in luoghi dove non c'è accesso, e non l'uso di un accesso legittimo "non conforme". L'utente di Amazon ha un account e il diritto di accedervi. Lo strumento con cui lo fa non diventa di per sé un soggetto di hacking.
Perché tutto si è deciso sull'architettura del traffico
La parte più interessante della decisione per i praticanti è quella tecnica. La corte ha esaminato come è fisicamente strutturato Comet Assistant, e proprio questo ha determinato l'esito.
Il funzionamento è il seguente: l'agente fa screenshot della finestra del browser sul computer dell'utente, li invia ai server di Perplexity, e da lì arrivano istruzioni di navigazione — di nuovo sul computer dell'utente, che esegue le azioni. I server di Perplexity non comunicano direttamente con i server di Amazon. Tutto il traffico che Amazon vede proviene dal dispositivo e dall'indirizzo IP dell'utente stesso.
Da qui la conclusione della corte. Se la richiesta proviene fisicamente dall'utente, allora anche "l'accesso" nel senso del CFAA è stato effettuato da lui.
In cosa si differenzia da Power Ventures
Fino ad ora, la storia canonica di accesso di terzi con il consenso dell'utente era il caso Facebook v. Power Ventures (2016). Lì la corte ha deciso che la piattaforma può revocare l'accesso a un servizio di terzi, anche se gli utenti hanno volontariamente fornito le proprie credenziali. Proprio su questo precedente si è basata la giudice di primo grado, estendendolo agli agenti di intelligenza artificiale.
Il Nono Circuito ha distinto questi casi su un unico criterio — e ancora una volta per motivi architettonici. In Power Ventures, i sistemi del convenuto inviavano direttamente messaggi alla piattaforma Facebook, bypassando il computer dell'utente. Perplexity non ha un tale canale. Una topologia del traffico diversa implica una risposta diversa alla domanda "chi ha ottenuto accesso".
Il significato pratico di questa distinzione è difficile da sovrastimare. Significa che il design del sistema — un agente client sul dispositivo dell'utente o un servizio server che accede alla piattaforma da solo — ha smesso di essere una scelta puramente ingegneristica ed è diventato un argomento legale.
Cosa la decisione NON ha fatto
La corte ha cercato di limitare al massimo il raggio d'azione e ha chiaramente affermato che non crea un nuovo regime legale per l'intelligenza artificiale agenti. Cosa è rimasto fuori dai margini:
- Violazione del contratto utente. Le pretese derivanti dal contratto, dal delitto e dalle regole della piattaforma non sono chiuse dalla decisione — possono essere presentate separatamente.
- Cause contro gli utenti stessi. Se l'accesso è effettuato dall'utente, la piattaforma può scegliere di indirizzare le pretese a lui.
- Architetture server. La conclusione è stata fatta per uno schema specifico. Un scraper cloud o un agente SaaS che accede alla piattaforma dalla propria infrastruttura non rientra automaticamente in questa logica.
- Blocchi tecnici. Nessuna parola nella decisione vieta ad Amazon di rilevare e bloccare l'automazione. Il diritto di bloccare non è scomparso — è scomparsa la possibilità di giustificare il blocco con un articolo penale.
Questo, per inciso, rappresenta un'inversione della situazione abituale: prima il rischio legale era a carico di chi automatizzava, mentre la protezione tecnica era considerata una seconda linea. Ora per le piattaforme la protezione tecnica è diventata la prima linea.
Cosa cambia nella pratica
Per tutti coloro che raccolgono dati, automatizzano account o costruiscono agenti, dalla decisione derivano tre conclusioni operative.
1. Il punto di uscita del traffico ha acquisito peso legale
In passato, la scelta tra "far passare tutto attraverso il proprio data center" e "lavorare da indirizzi indistinguibili da quelli degli utenti" era una questione di fattibilità e costo. Ora è anche una questione di chi si considera l'azione della richiesta. L'architettura, in cui la richiesta alla piattaforma proviene dal lato dell'utente, si è rivelata più difendibile in tribunale — e per di più storicamente supera meglio i filtri anti-bot. Questo è un caso raro in cui gli stimoli legali e tecnici coincidono e puntano nella stessa direzione: verso proxy residenziali e punti di uscita utente invece di subnet server. Per compiti neutrali come il monitoraggio dei prezzi pubblici o la verifica dei risultati per regione, continuano a essere sufficienti proxy datacenter — lì non ci sono zone di accesso né controversie su account di qualcuno.
2. Il CFAA si è indebolito — il contratto e il rilevamento si sono rafforzati
Non bisogna leggere la decisione come "ora si può". È stata rimossa la mazza più pesante — l'articolo federale con potenziale penale. Rimangono il contratto utente, il blocco dell'account, la causa civile e, soprattutto, il pacchetto anti-bot. Le piattaforme, avendo perso parte del potere legale, compenseranno con il rilevamento: fingerprinting, analisi comportamentale e agenti firmati. Abbiamo discusso di come l'industria cerca di legalizzare i "buoni" bot con mezzi tecnici nel materiale su Web Bot Auth e agenti firmati.
3. Il rischio si è spostato verso l'utente finale
Il rovescio della medaglia della vittoria di Perplexity: se agisce l'utente, allora è l'utente a rispondere. Per i servizi che offrono ai clienti automazione come prodotto, è un motivo per discutere onestamente nella documentazione a nome di chi e con quale IP vengono eseguite le azioni e quali regole della piattaforma vengono coinvolte.
Cosa fare subito
- Descrivi la tua topologia di accesso. Rispondi a una domanda: quale IP vede la piattaforma target nei log — il tuo server o quello dell'utente. Da questo dipende sia la posizione legale che il profilo di rilevamento.
- Separa pubblico e autenticato. La raccolta di pagine aperte e le azioni all'interno di un account altrui sono storie fondamentalmente diverse per rischio. Non è consigliabile mescolarle in un unico pipeline.
- Non mascherarti in modo aggressivo dopo un divieto diretto. In questo caso, proprio l'aggiramento della barriera imposta e la sostituzione del client con Chrome hanno fornito ad Amazon i fatti più forti. L'accusa CFAA è crollata, ma le altre basi rimangono.
- Scegli il tipo di uscita in base al compito. La parte pratica — come avviare un agente su Playwright o MCP e instradare correttamente il suo traffico — è stata esaminata in dettaglio nella guida ai proxy per agenti di intelligenza artificiale.
Conclusione
Il Nono Circuito non ha legalizzato l'automazione e non ha dato agli agenti un pass per andare ovunque. Ha fatto qualcosa di più ristretto, ma più importante: ha legato il concetto di "accesso" a dove fisicamente proviene la richiesta. Uno strumento che opera sul computer dell'utente non compie accesso — lo compie una persona. L'infrastruttura che accede alla piattaforma da sola rimane nell'ambito dei vecchi rischi.
Per il mercato, questo significa uno spostamento del centro di gravità. La controversia legale su "se sia possibile" si concentrerà sempre più sulla questione ingegneristica "di chi è l'indirizzo nel log". E la lotta per l'accesso si sposta definitivamente dove è sempre stata, — nel rilevamento anti-bot, nel fingerprinting e nella qualità dei punti di uscita.