Frota de agentes chineses dribla API e acende alerta

Frota de agentes de IA expõe o lado sujo da automação

Frota de agentes de IA operando em paralelo na infraestrutura da Tencent foi flagrada acessando em massa o Amap, o serviço de mapas do Alibaba. Não é um teste isolado e nem um bot simples de scraping. São dezenas, talvez centenas de sessões pedindo rotas para entradas específicas de parques, zoológicos e hospitais, tudo através de um truque velho: carregar páginas via URLquery para fugir de bloqueios diretos. Se você mantém uma API pública, esse caso deveria te deixar inquieto, porque mostra como qualquer regra de uso vira sugestão quando o cliente do outro lado não é humano.

Quem já operou scraping em escala conhece o padrão. Um desenvolvedor coloca limite de requisições, exige chave de API, bloqueia IP suspeito. Funciona contra humanos e scripts burros. Contra agentes autônomos que abrem navegador real, esperam o JavaScript renderizar, clicam e rolam como gente, quase nada disso segura. O custo de contornar caiu muito e o volume subiu na mesma proporção. É isso que estamos vendo aqui, na prática, sem teoria.

O fato: agentes na Tencent mirando o Amap

Pesquisadores independentes publicaram no domingo uma análise preliminar. Eles monitoravam o tráfego do URLquery, um serviço de escaneamento de domínios que registra como páginas foram carregadas, e notaram um padrão estranho de acessos ao Amap. As consultas pediam direções para entradas diferentes de locais públicos, sempre com pequenas variações, como se cada agente estivesse resolvendo uma microtarefa de navegação. A origem técnica apontava para infraestrutura da Tencent, mas ninguém sabe ainda quem está por trás, qual empresa, laboratório ou grupo está rodando isso e com qual objetivo final.

Um detalhe importante: os pesquisadores recusaram o termo 'enxame' ou 'swarm'. Preferiram 'fleet', frota. Não há sinal de comunicação entre os agentes, nenhum indício de coordenação inteligente ou divisão dinâmica de tarefas. São muitos agentes paralelos fazendo o mesmo tipo de trabalho, cada um por conta própria. Isso sugere um sistema de batch, algo como uma fila de tarefas distribuída em máquinas virtuais, e não um sistema multiagente sofisticado conversando entre si. Menos sexy, mas muito mais plausível para quem já montou esse tipo de pipeline.

Como eles foram detectados

A detecção veio pelo rastro deixado no URLquery. Agentes de IA costumam usar esse tipo de serviço como proxy de renderização quando não conseguem acessar um site diretamente por bloqueio de bot, geofencing ou JavaScript pesado. Eles pedem ao URLquery para carregar a página e depois leem o resultado. Foi a mesma técnica que expôs atividade prolongada de agentes da OpenAI no passado. É irônico, mas agentes são péssimos em se esconder. Usam os mesmos user agents, os mesmos padrões de TLS, os mesmos intervalos de repetição. Quem monitora tráfego consegue farejar de longe, ainda mais depois do incidente com a Hugging Face, que deixou muita gente monitorando comportamento anômalo de agentes na internet aberta.

Como funciona: visão de operador

Vamos traduzir isso para arquitetura. O cenário mais provável é simples. Alguém tem uma lista de pontos de interesse e precisa de dados de rota que a API oficial do Amap cobraria caro ou limitaria. Em vez de pagar, sobe uma frota de navegadores headless, provavelmente Playwright ou Puppeteer com Chromium, hospedados em CVMs da Tencent ou em containers com IPs rotativos. Cada worker recebe uma fatia da fila, algo como buscar a entrada leste do parque X ou a entrada de emergência do hospital Y, abre o Amap via URLquery ou direto, extrai o HTML ou o JSON embutido e salva.

Em termos de custo, essa operação é barata. Uma VM modesta na Tencent Cloud roda dezenas de sessões headless em paralelo. Se cada consulta ao Amap custaria centavos via API oficial em alto volume, via scraping o custo vira só computação e banda, talvez frações de centavo por consulta. A latência é pior, cada navegação pode levar de 3 a 8 segundos com renderização completa, contra 200ms de uma chamada de API limpa. Mas para coleta offline isso não importa. Você joga 500 workers em paralelo e compensa a lentidão com throughput. É força bruta com orçamento baixo.

Por que usar o URLquery no meio? Provável inferência técnica, não confirmação: o Amap deve estar bloqueando datacenter IPs da Tencent ou exigindo cookies e verificações que o bot direto não passa. O URLquery funciona como um renderizador confiável com reputação boa, então o Amap entrega a página para ele sem desconfiar. O agente então raspa o snapshot. É um bypass por reputação de terceiros, não um exploit sofisticado. Funciona até o alvo começar a bloquear também o ASN ou o padrão de referer do URLquery, o que deve acontecer em breve agora que o caso vazou.

O que isso muda na prática

Para quem defende APIs, a mensagem é dura. Seu rate limit por IP já não vale quase nada. Agentes distribuídos diluem o volume por dezenas de saídas e ainda terceirizam o IP para serviços legítimos. Quem perde são times que confiam só em WAF genérico e limite burro. Quem ganha, por enquanto, é quem está coletando dados sem pagar, treinando modelos de navegação, montando base de POIs ou testando capacidade de agentes em ambiente real. Não parece espionagem clássica, parece extração de valor e teste de escala. Mas a técnica é a mesma que seria usada para algo mais grave.

• Se você opera mapas, marketplace ou qualquer dado valioso: assuma que headless browsers vão bater na sua porta todos os dias.
• Se você constrói agentes: esse caso mostra que rodar frota sem coordenação já gera resultado, mas deixa rastro enorme e queima infraestrutura intermediária.
• Se você só consome APIs: prepare-se para preços e controles mais duros, porque todo mundo vai reagir a esse tipo de abuso.

A ação prática imediata para operadores é trocar bloqueio por IP por fingerprint de comportamento. Monitore sequências repetidas de consultas a endpoints de rota com variações mínimas de parâmetros, sessões que sempre chegam via mesmos renderizadores externos, TLS fingerprints idênticos em centenas de sessões. Exija chave de API até para leitura básica, coloque proof of work leve ou desafio interativo em rotas caras e crie um endpoint de baixo custo para casos legítimos. Parece contraintuitivo, mas oferecer uma API barata para navegação simples reduz o incentivo ao scraping. E monitore seu próprio tráfego no URLquery e serviços similares. Se sua URL aparece lá em volume, você já está sendo raspado por agentes.

O problema real: escala sem dono

Aqui entra a tensão que ninguém quer encarar. Essa frota não parece coordenada, não parece eficiente e mesmo assim funcionou por um tempo sem ninguém perceber. Isso escala? Sim, e esse é o problema. Não precisa de orquestração elegante para causar estrago. Mil agentes burros, cada um gastando 5 segundos por página, geram um DDoS lento e caro para quem hospeda a API. O custo para o atacante continua baixo, o custo para o defensor, em banda, renderização e mitigação, só aumenta. A conta não fecha.

E resolve ou só move o gargalo? Hoje o gargalo foi empurrado para o URLquery e para o Amap, que pagam a conta computacional. Amanhã, quando todo alvo bloquear renderizadores públicos, os operadores de frota vão migrar para redes residenciais, celulares comprometidos ou infraestrutura própria distribuída. Já vimos esse filme com scraping tradicional. A diferença é que agora o operador não precisa escrever parser específico. Ele só diz ao agente para 'pegue a entrada do zoológico' e o modelo se vira. A barreira técnica para abusar despencou, enquanto a barreira para defender subiu. Vale a pena manter dados abertos nesse cenário? Para muitos, a resposta vai ser fechar tudo, e todos perdemos com isso.

Conclusão

No fim, essa frota chinesa é menos sobre China e mais sobre o novo normal: agentes paralelos, baratos e sem cerimônia raspando o que precisam. Se sua API pode ser lida por um navegador, ela já está no dataset de alguém. A pergunta que fica é simples, você vai descobrir isso pelo seu próprio monitoramento ou pelo post de um pesquisador?