Agentes de inteligência artificial já não ficam restritos a uma janela de conversa. Eles consultam páginas, chamam ferramentas, preenchem formulários e repetem tarefas em sequência. Essa autonomia pode economizar tempo, mas também cria um novo problema para quem monitora a internet: distinguir o tráfego produzido por pessoas, sistemas automatizados comuns e grupos de agentes capazes de agir em escala.
Uma reportagem publicada pelo TechCrunch em 5 de outubro de 2026 descreveu a observação de uma frota de agentes associada a uma infraestrutura da Tencent e direcionada ao serviço de mapas Amap, da Alibaba. Os pesquisadores evitaram chamar o conjunto de enxame porque não encontraram sinais de comunicação entre os agentes. A expressão usada foi frota de agentes, muitos sistemas fazendo tarefas parecidas em paralelo.
O episódio é um alerta útil para desenvolvedores brasileiros porque mostra que a segurança de um agente não termina no modelo de linguagem. Ela inclui a forma como o sistema navega, consulta APIs, lida com limites e deixa rastros. Mesmo quando a atividade observada não parece maliciosa, o padrão pode revelar como agentes estão aprendendo a ocupar serviços online.
Frota não é o mesmo que enxame
A diferença entre os termos parece semântica, mas muda a interpretação técnica. Um enxame sugere coordenação, troca de mensagens e uma estratégia distribuída. Uma frota pode ser apenas um conjunto de processos semelhantes, executando instruções independentes. No caso descrito pelo TechCrunch, os pesquisadores observaram consultas paralelas, mas não identificaram uma camada de comunicação entre elas.
Essa cautela é importante porque a palavra enxame costuma sugerir um sistema mais avançado do que as evidências permitem afirmar. Em segurança, exagerar o diagnóstico pode ser tão ruim quanto ignorar o comportamento. Uma equipe precisa registrar o que foi observado, o que é hipótese e qual informação ainda falta.
Os agentes estavam fazendo consultas a entradas de locais públicos, como parque, zoológico e hospital, no serviço de mapas da Alibaba. A reportagem não descreve uma ação destrutiva. Ainda assim, a repetição em escala pode pressionar uma API, contornar limites ou consumir dados de uma forma que o provedor não autorizou.
Como os pesquisadores encontraram os rastros
Um dos sinais veio do monitoramento do URLquery, serviço que carrega endereços na web e registra a atividade para análise. Agentes usam ferramentas desse tipo quando não conseguem acessar diretamente uma página ou quando precisam observar o resultado de uma consulta. O registro de acessos pode ajudar investigadores a entender a origem, a frequência e o padrão de uma automação.
O método revela uma característica dos agentes atuais: muitos ainda operam de forma relativamente visível. Eles usam serviços públicos, seguem rotas repetidas e deixam requisições com pouca tentativa de ocultação. Isso facilita a pesquisa, mas não deve ser tratado como uma garantia. À medida que agentes forem usados em operações mais sofisticadas, os sinais podem mudar.
Para o defensor, o ponto central é ampliar a observabilidade. Logs de aplicação, registros de API, padrões de navegação, limites por identidade e detecção de comportamento anormal precisam ser analisados em conjunto. Uma única requisição raramente prova alguma coisa. Uma série de consultas com horários, parâmetros e destinos semelhantes pode mostrar uma automação coordenada.
O risco de contornar regras de API
Interfaces de programação, conhecidas como APIs, são contratos que definem como um serviço pode ser consultado. Elas limitam frequência, formato de dados, permissões e finalidade de uso. Quando um agente usa um caminho alternativo para obter a mesma informação, a empresa que o opera pode estar violando as regras mesmo sem explorar uma vulnerabilidade tradicional.
Esse tipo de comportamento é diferente de um ataque que instala malware, rouba credenciais ou altera um banco de dados. Ainda assim, pode produzir impacto. Um volume alto de consultas eleva custos, reduz a qualidade do serviço para outros usuários e pode permitir a criação de cópias de dados que o provedor tenta controlar.
O caso também ajuda a separar capacidade de intenção. O agente pode estar seguindo uma instrução mal configurada, tentando completar uma tarefa legítima ou buscando uma forma mais barata de obter dados. O sistema não precisa ter uma intenção humana para causar consequências. Basta que a combinação entre objetivo, ferramenta e permissão não tenha sido testada.
O que isso ensina sobre agentes autônomos
Um chatbot que apenas produz texto tem uma superfície de risco diferente da de um agente. Quando o sistema pode abrir endereços, consultar serviços e repetir ações, cada passo vira uma oportunidade de erro. A avaliação precisa simular falhas de rede, respostas ambíguas, limites de uso e instruções contraditórias.
O primeiro controle é o princípio do menor privilégio. O agente deve receber apenas a credencial e o acesso necessários para executar a tarefa. Se precisa consultar uma agenda, não deve acessar o armazenamento inteiro. Se precisa buscar uma rota, não deve poder modificar dados de conta. A separação reduz o estrago quando o comportamento sai do esperado.
O segundo controle é a aprovação em pontos de risco. Uma consulta de leitura pode ser automática, enquanto o envio de uma mensagem, a compra de um serviço ou a alteração de dados exige confirmação. O sistema deve explicar o que pretende fazer e mostrar os parâmetros usados. Uma aprovação genérica para toda a sessão é menos segura do que uma decisão clara para cada ação sensível.
O terceiro controle é a interrupção. Limites de tempo, número de chamadas, orçamento e volume de dados impedem que um agente continue operando por horas depois de perder o contexto. Um botão de parada precisa funcionar de verdade e os registros devem permitir reconstruir o que aconteceu.
Como equipes brasileiras podem se preparar
Empresas que adotam agentes devem começar com ambientes de teste. O sistema pode usar APIs simuladas, dados falsos e contas sem acesso a informações pessoais. Antes de ser conectado a serviços reais, o agente precisa demonstrar que respeita limites, lida com falhas e registra suas decisões.
A observabilidade também deve ser um requisito de compra. O fornecedor precisa informar que eventos registra, por quanto tempo guarda os dados, quem pode consultar os logs e como responde a um incidente. Em integrações com dados de clientes, a equipe deve mapear quais informações entram no contexto e quais podem ser exportadas pelo agente.
Para desenvolvedores, é útil testar o sistema contra instruções de páginas externas. Um site consultado pode conter texto que tenta redirecionar o agente para outra tarefa. A aplicação precisa separar dados lidos de comandos autorizados e evitar que uma página consiga alterar as regras internas da execução.
Leia também
- Bots da OpenAI colocam a infraestrutura aberta da Wikipédia sob pressão
- Circuit Breaker Labs testa agentes de IA para encontrar falhas antes do lançamento
Conclusão
A frota de agentes observada por pesquisadores não é uma prova de que uma operação maliciosa sofisticada esteja em curso. Ela é, porém, uma demonstração de que sistemas autônomos já produzem atividade distribuída que merece monitoramento. A fronteira entre automação útil e abuso de serviços depende de limites, transparência e contexto.
Para o leitor, a lição é direta: agentes precisam ser tratados como software com acesso a ferramentas, não como assistentes mágicos. Quem os desenvolve deve controlar permissões, registrar ações e testar cenários adversos. Quem os utiliza deve saber quais serviços estão conectados e que consequências podem surgir de uma tarefa repetida em escala.
Fonte original: TechCrunch, Researchers are tracking a Chinese AI agent fleet. Crédito da imagem: Carol Yepes/Getty Images, via TechCrunch.
