Em 4 de agosto de 2026, o Tribunal de Apelação do Nono Circuito dos EUA revogou a liminar que, desde março, impedia o navegador agente Perplexity Comet de acessar as contas dos usuários na Amazon. Formalmente, trata-se de uma disputa entre duas corporações sobre compras via IA. Na prática, é a primeira decisão de apelação que responde a uma questão importante muito além do comércio de agentes: quem exatamente "obtém acesso" ao servidor de outra pessoa quando um pedido é enviado por automação. E a resposta do tribunal, surpreendentemente, não se baseou no direito, mas na arquitetura da rede.
O que aconteceu: da ação à revogação da liminar
A cronologia da disputa é a seguinte:
- Novembro de 2025 — A Amazon processa a Perplexity AI, citando a Lei Federal de Fraude e Abuso de Computadores (CFAA) e seu equivalente na Califórnia. A alegação: o agente Comet faz login nas contas dos usuários, visualiza produtos e inicia compras, ou seja, opera em uma área protegida por senha sem a autorização da própria plataforma.
- Contexto — segundo a Amazon, a empresa alertou a Perplexity pelo menos cinco vezes desde novembro de 2024, em agosto de 2025 impôs uma barreira técnica, e a Perplexity lançou uma atualização que a contornava em menos de 24 horas. Uma crítica adicional: o agente se disfarçava como uma sessão normal do Google Chrome.
- 9 de março de 2026 — A juíza Maxine Chesney (Distrito Norte da Califórnia) emite uma liminar e ordena a destruição dos dados obtidos da Amazon. Sua fórmula: o acesso foi feito com a permissão do usuário da Amazon, mas sem a autorização da Amazon.
- 4 de agosto de 2026 — O Nono Circuito (caso nº 26-1444) revoga a liminar: a Amazon provavelmente não vencerá a alegação de CFAA.
A Amazon declarou que não concorda com a decisão e continuará a disputa. A Perplexity respondeu que defenderá o direito dos usuários de escolher qualquer IA. O caso, no entanto, não desapareceu: o processo no tribunal de primeira instância continua, e a Amazon pode solicitar uma revisão ou recorrer a instâncias superiores.
Movimento chave: o agente é uma ferramenta, não uma pessoa
A CFAA penaliza o acesso a um "computador protegido" sem autorização. Toda a disputa se resumiu a um verbo: quem cometeu o ato de acesso. A Amazon alegou — Perplexity, porque era seu agente que atuava na plataforma. A Perplexity respondeu — o usuário, que deu a ordem ao agente.
O tribunal de apelação adotou a segunda posição e formulou isso claramente: por mais avançado que seja o agente, para fins da lei "é uma ferramenta, não uma pessoa" — um instrumento, não um indivíduo. Quando o usuário delega ao agente a realização de algo no Amazon.com, o acesso aos computadores da Amazon é feito pelo próprio usuário.
Isso é uma continuação lógica da linha do Supremo Tribunal no caso Van Buren v. Estados Unidos (2021), que restringiu a CFAA: a lei pune a invasão a locais onde não há acesso, e não o uso de acesso legal "para fins não autorizados". O usuário da Amazon possui uma conta e tem o direito de acessá-la. O instrumento que ele utiliza para isso não se torna, por si só, um sujeito de invasão.
Por que a arquitetura do tráfego decidiu tudo
A parte mais interessante da decisão para os profissionais é a técnica. O tribunal analisou como o Comet Assistant é fisicamente estruturado, e isso definiu o resultado.
O funcionamento é o seguinte: o agente faz capturas de tela da janela do navegador na máquina do usuário, envia-as para os servidores da Perplexity, e de lá vêm instruções de navegação — de volta para o computador do usuário, que executa as ações. Os servidores da Perplexity não se comunicam diretamente com os servidores da Amazon. Todo o tráfego que a Amazon vê vem do dispositivo e do endereço IP do próprio usuário.
Daí vem a conclusão do tribunal. Se o pedido fisicamente se origina do usuário, então o "acesso", no sentido da CFAA, foi realizado por ele.
Como isso difere do Power Ventures
Até agora, a história canônica sobre acesso de terceiros com o consentimento do usuário era o caso Facebook v. Power Ventures (2016). Nesse caso, o tribunal decidiu que a plataforma pode revogar o acesso de um serviço de terceiros, mesmo que os usuários tenham voluntariamente fornecido suas credenciais. Foi exatamente nesse precedente que a juíza de primeira instância se baseou, estendendo-o aos agentes de IA.
O Nono Circuito diferenciou esses casos por um único critério — e novamente por uma questão arquitetônica. No Power Ventures, os sistemas do próprio réu enviavam mensagens diretamente para a plataforma Facebook, contornando a máquina do usuário. A Perplexity não possui tal canal. Diferentes topologias de tráfego resultam em respostas diferentes à pergunta "quem obteve acesso".
O significado prático dessa distinção é difícil de subestimar. Isso significa que o design do sistema — um agente cliente no dispositivo do usuário ou um serviço de servidor que acessa a plataforma por conta própria — deixou de ser uma escolha puramente técnica e se tornou um argumento jurídico.
O que a decisão NÃO fez
O tribunal se esforçou ao máximo para limitar o raio de ação e deixou claro que não cria um novo regime jurídico para a IA agente. O que ficou de fora:
- Violação do contrato de usuário. As alegações decorrentes do contrato, delito e regras da plataforma não são encerradas pela decisão — podem ser apresentadas separadamente.
- Ações contra os próprios usuários. Se o acesso é realizado pelo usuário, então a plataforma pode escolher ele como destinatário das alegações.
- Arquiteturas de servidor. A conclusão foi feita com base em um esquema específico. Um scraper em nuvem ou um agente SaaS que acessa a plataforma a partir de sua própria infraestrutura não se enquadra automaticamente nessa lógica.
- Bloqueios técnicos. Nenhuma palavra na decisão proíbe a Amazon de detectar e cortar a automação. O direito de bloquear não desapareceu — desapareceu a possibilidade de sustentar o bloqueio com uma acusação criminal.
Isso, aliás, representa uma reviravolta na imagem habitual: antes, o risco jurídico recaía sobre quem automatizava, enquanto a proteção técnica era considerada uma segunda linha. Agora, para as plataformas, a proteção técnica se tornou a primeira linha.
O que isso muda na prática
Para todos que coletam dados, automatizam contas ou constroem agentes, a decisão traz três conclusões práticas.
1. O ponto de saída do tráfego ganhou peso jurídico
Antes, a escolha entre "passar tudo pelo nosso data center" e "trabalhar a partir de endereços indistinguíveis dos usuários" era uma questão de viabilidade e custo. Agora, é também uma questão de quem é considerado o autor do pedido. A arquitetura, na qual a solicitação à plataforma se origina do lado do usuário, mostrou-se mais defensável em tribunal — e, ao mesmo tempo, historicamente, passa melhor pelos filtros anti-bots. Este é um caso raro em que o estímulo jurídico e técnico coincide e aponta na mesma direção: para proxies residenciais e pontos de saída de usuários em vez de sub-redes de servidores. Para tarefas neutras, como monitoramento de preços públicos ou verificação de resultados por regiões, ainda são suficientes datacenter-proxies — onde não há área logada nem disputa sobre a conta de alguém.
2. CFAA enfraqueceu — contrato e detecção se fortaleceram
Não se deve ler a decisão como "agora é permitido". A mais pesada arma — a acusação federal com potencial criminal — foi removida. Restaram o contrato de usuário, o bloqueio de conta, a ação civil e, principalmente, o stack anti-bot. As plataformas, ao perderem parte de sua alavanca jurídica, compensarão isso com detecção: fingerprinting, análise comportamental e agentes assinados. Sobre como a indústria tenta legalizar "bots bons" por meios técnicos, discutimos no material sobre Web Bot Auth e agentes assinados.
3. O risco se deslocou para o usuário final
A contrapartida da vitória da Perplexity: se o usuário está agindo, então é ele quem responde. Para serviços que oferecem automação como produto, isso é um motivo para esclarecer na documentação em nome de quem e com qual IP as ações são realizadas e quais regras da plataforma estão sendo afetadas.
O que fazer agora
- Descreva sua topologia de acesso. Responda a uma pergunta: qual IP a plataforma alvo vê nos logs — o seu servidor ou o do usuário. Isso afeta tanto a posição jurídica quanto o perfil de detecção.
- Separe o público do logado. Coletar páginas abertas e agir dentro da conta de outra pessoa são histórias fundamentalmente diferentes em termos de risco. Não vale a pena misturá-las em um único pipeline.
- Não se disfarce agressivamente após uma proibição direta. Neste caso, foi exatamente a contornagem da barreira imposta e a substituição do cliente pelo Chrome que forneceram à Amazon os fatos mais fortes. A alegação de CFAA desmoronou, mas as outras bases permanecem.
- Escolha o tipo de saída para a tarefa. A parte prática — como levantar um agente no Playwright ou MCP e redirecionar corretamente seu tráfego — foi detalhadamente discutida no guia sobre proxies para agentes de IA.
Conclusão
O Nono Circuito não legalizou a automação e não deu aos agentes um passe para qualquer lugar. Ele fez algo mais restrito, mas mais importante: vinculou o conceito de "acesso" à origem física do pedido. O instrumento que opera na máquina do usuário não realiza o acesso — isso é feito pela pessoa. A infraestrutura que acessa a plataforma por conta própria permanece na zona de riscos antigos.
Para o mercado, isso significa um deslocamento do centro de gravidade. A disputa legal sobre "se é permitido" cada vez mais se concentrará na questão técnica "qual é o endereço no log". E a própria luta pelo acesso finalmente se desloca para onde sempre esteve — na detecção anti-bot, fingerprinting e qualidade dos pontos de saída.
