Roteadores de LLM: o novo elo fraco na cadeia de supply chain de IA
Pesquisadores da Universidade da Califórnia, em conjunto com outras instituições, realizaram um mapeamento detalhado de uma ameaça ainda pouco discutida: ataques conduzidos por roteadores de API de modelos de linguagem (LLMs). O estudo, intitulado “Your Agent Is Mine: Measuring Malicious Intermediary Attacks on the LLM Supply Chain”, mostra como esses intermediários conseguem injetar código malicioso, roubar credenciais e manipular silenciosamente o fluxo de dados entre usuários e modelos de IA.
O trabalho classifica os ataques em duas categorias principais. A primeira é a injeção de payload (AC-1), quando o roteador altera respostas ou chamadas de ferramentas para inserir comandos maliciosos. A segunda é a exfiltração de segredos (AC-2), em que o intermediário captura chaves, tokens, credenciais em nuvem ou outros dados sensíveis que passam pelo tráfego JSON. Além disso, os pesquisadores identificam variantes de evasão adaptativa, em que o comportamento malicioso só é ativado sob certas condições, dificultando a detecção.
Roteadores maliciosos já estão em operação
Ao contrário da ideia de que se trata apenas de um risco teórico, os autores demonstram que roteadores maliciosos já estão sendo usados ativamente. Eles analisaram 28 roteadores pagos, comprados em marketplaces digitais, e 400 roteadores gratuitos encontrados em serviços públicos. Dentro desse universo, encontraram um roteador pago e oito gratuitos que efetivamente injetavam código malicioso em chamadas de ferramentas devolvidas aos clientes.
Alguns desses roteadores ainda empregavam estratégias sofisticadas de camuflagem. Em dois casos, o código malicioso não aparecia de imediato: a injeção só ocorria após 50 requisições ou apenas quando o agente operava em um modo autônomo, descrito como “YOLO mode”. Dessa forma, os operadores maliciosos evitam ser detectados em testes superficiais e só passam a agir quando presumem que estão em um ambiente real de produção.
Roubo de credenciais e drenagem de criptomoedas
A dimensão do problema fica ainda mais clara quando se observam os experimentos com exfiltração de segredos. Entre os 400 roteadores gratuitos, 17 interagiram com credenciais AWS “canário” criadas pelos próprios pesquisadores – chaves projetadas para denunciar acesso indevido. Em outro caso, um roteador chegou a drenar ETH de uma chave privada Ethereum controlada pelo time de pesquisa, demonstrando que esse tipo de ataque pode resultar em prejuízo financeiro direto.
Os autores também testaram cenários de envenenamento proposital. Uma chave da OpenAI vazada de forma controlada foi usada para gerar cerca de 100 milhões de tokens de um modelo identificado como GPT-5.4, além de expor múltiplas sessões de usuários que, sem saber, confiavam naquela infraestrutura intermediária. Em outro conjunto de experimentos, foram implantadas instâncias de “isca”, com configurações propositalmente fracas: essas instalações receberam mais de 40 mil tentativas de acesso não autorizado, processaram cerca de 2 bilhões de tokens e expuseram 99 credenciais em 440 sessões analisadas.
Onde está o risco na arquitetura de LLMs
O estudo chama atenção para o papel dos roteadores de API como proxies em nível de aplicação, com acesso completo ao conteúdo das requisições e respostas em texto plano. Diferente de uma visão tradicional de segurança em rede, em que a criptografia de transporte (como TLS) é suficiente, aqui o risco está na camada de aplicação: o roteador vê tudo, mexe em tudo e não há, hoje, garantias criptográficas de integridade de ponta a ponta entre o cliente e o modelo de IA upstream.
Os pesquisadores formalizam isso como uma propriedade de “elo mais fraco”: basta um único roteador malicioso em qualquer camada da cadeia para comprometer toda a sessão. Se um intermediário alterar a resposta ou a chamada de ferramenta, roteadores subsequentes, mesmo honestos, não têm meios para perceber ou reverter a modificação. Esse desenho cria uma superfície de ataque ideal para adversários que desejam se infiltrar no supply chain de IA.
Protótipo de ataque e avaliação de defesas
Para demonstrar o impacto prático, os autores construíram o Mine, um proxy de pesquisa que implementa as quatro classes de ataque descritas no artigo contra quatro frameworks públicos de agentes: OpenClaw, OpenCode, OpenAI Codex e Anthropic Claude Code. A ideia foi simular o comportamento de um roteador intermediário malicioso, manipulando respostas, chamadas de ferramentas e tentando roubar segredos expostos no tráfego.
Com base nesses testes, três tipos de defesa no lado do cliente foram avaliados. A primeira é uma política de bloqueio voltada a ferramentas de alto risco, que consegue bloquear 100% dos ataques AC-1 e AC-1.a, com uma taxa de falsos positivos em torno de 1%. A segunda é a triagem de anomalias na resposta, que identifica 89% dos ataques de injeção, analisando padrões suspeitos no retorno. A terceira é o uso de registros de transparência anexáveis, que criam um log verificável do tráfego – nesse caso, o custo estimado foi de 12 MB por 1.000 sessões, o que é razoável para muitos cenários corporativos.
Limitações das defesas e lacunas de proveniência
Apesar dos resultados positivos, os pesquisadores são claros ao apontar que essas defesas apenas reduzem o impacto, mas não resolvem o problema de origem. Nenhum dos quatro frameworks analisados implementava verificação robusta de integridade de resposta. Em outras palavras, o cliente ainda não tem como garantir, de forma criptograficamente verificável, que a saída recebida realmente veio do modelo upstream, sem interferência de intermediários.
Eles destacam que a escolha de um roteador passa a ser, na prática, uma decisão de confiança – com um detalhe importante: o custo de troca é baixíssimo. Um desenvolvedor pode mudar de roteador em minutos, o que incentiva a adoção rápida de soluções pouco auditadas ou de origem desconhecida. Segundo os autores, a lacuna crítica que permanece é a falta de proveniência de ponta a ponta, algo que exige mecanismos de integridade suportados pelos próprios provedores de modelos.
O que isso significa para empresas e equipes de segurança
Para organizações que estão adotando LLMs em processos de negócio, o recado é direto: roteadores de API de IA devem ser tratados como componentes críticos de segurança, e não apenas peças neutras de infraestrutura. Eles enxergam dados sensíveis, podem manipular decisões automatizadas e têm potencial para desviar fluxos financeiros, especialmente quando conectados a sistemas de pagamento, automação de nuvem ou wallets de criptomoedas.
CISOs, arquitetos de segurança e líderes de TI precisam incorporar esse risco nos seus modelos de ameaça. A mesma disciplina já aplicada a gateways de API, proxies de rede ou serviços de terceiros deve ser estendida aos roteadores de LLM. Isso inclui due diligence mínima, avaliação de código (quando possível), governança de chaves e monitoramento contínuo de comportamento anômalo.
Boas práticas para mitigar riscos em roteadores de LLM
Algumas medidas práticas podem reduzir significativamente a exposição:
1. Minimizar intermediários
Sempre que possível, reduzir a quantidade de saltos entre o cliente e o provedor de LLM. Quanto menos roteadores e plugins externos, menor a superfície de ataque.
2. Preferir roteadores auditáveis e com código aberto (quando a política permitir)
Soluções cujo código pode ser inspecionado e que possuem histórico de manutenção transparente tendem a oferecer maior visibilidade, embora ainda exijam avaliação criteriosa.
3. Segmentar funções de alto risco
Acesso a carteiras de criptomoedas, credenciais em nuvem e sistemas críticos não deve ser exposto diretamente a agentes autônomos. Use contas de serviço com privilégios mínimos, escopo restrito e segregação de funções.
4. Implementar políticas de ferramentas sensíveis
Tal como sugerido pelos pesquisadores, definir listas de ferramentas de alto risco e aplicar políticas de bloqueio ou confirmação manual antes de sua execução.
5. Monitorar e registrar sessões de IA
Coletar logs detalhados de requisições, respostas e chamadas de ferramentas, com atenção para anomalias como uso excessivo de tokens, chamadas inesperadas ou comandos fora de contexto.
6. Rotação e proteção de credenciais
Chaves de API, tokens e segredos usados por agentes devem ser rotacionados com frequência, armazenados em cofres de segredos e nunca colocados diretamente em prompts ou configurações expostas.
Governança e compliance em ambientes de IA generativa
Do ponto de vista de governança, o estudo reforça a necessidade de políticas formais para uso de LLMs em ambientes corporativos. Não basta liberar “assistentes de IA” para equipes de desenvolvimento ou operações: é preciso definir quais provedores podem ser usados, quais roteadores são aprovados, que tipos de dados podem trafegar nesses canais e quais revisões de segurança são obrigatórias antes de se conectar a sistemas internos.
Reguladores e equipes de compliance também tendem a olhar com mais atenção para esses componentes. Vazamentos de credenciais, logs contendo dados pessoais ou exposição de informações sensíveis por meio de roteadores terceirizados podem gerar impactos regulatórios relevantes, inclusive em legislações de proteção de dados. Mapear a cadeia de fornecimento de IA passa a ser uma etapa essencial de qualquer avaliação de risco.
Próximos passos para o ecossistema de IA
O estudo sugere que a evolução natural será a adoção de mecanismos de integridade fim a fim, suportados por provedores de modelos e por padrões abertos. Isso pode incluir assinaturas digitais de respostas, canais autenticados de ponta a ponta e protocolos que permitam ao cliente verificar se a saída foi alterada por intermediários. Enquanto isso não se consolida, o cenário permanece baseado em confiança, inspeção manual e soluções de monitoramento no lado do cliente.
Fabricantes de ferramentas de desenvolvimento de agentes e plataformas de orquestração de LLMs também devem se mover na direção de incorporar controles nativos: verificação de integridade, detecção de anomalias, políticas de uso de ferramentas e telemetria mais rica para as equipes de segurança. Organizações que saírem na frente e exigirem tais recursos de seus fornecedores terão vantagem na construção de ambientes de IA mais confiáveis.
Conclusão: IA poderosa, mas cadeia frágil
Os roteadores de LLM emergem como um ponto cego significativo na segurança de soluções de IA generativa. Eles concentram poder, enxergam dados valiosos e, como o estudo demonstra, já estão sendo explorados de forma maliciosa. Ao mesmo tempo, o custo de troca e a facilidade de adoção criam um terreno fértil para soluções pouco confiáveis entrarem na cadeia.
Proteger a supply chain de LLMs exige uma combinação de arquitetura mais segura, seleção cuidadosa de roteadores, políticas de governança claras e mecanismos técnicos de detecção e mitigação de ataques. Até que existam padrões consolidados de proveniência e integridade de ponta a ponta, o fator determinante será a maturidade com que empresas e desenvolvedores tratam esses intermediários: como componentes críticos de segurança, e não apenas como mais um serviço conveniente na pilha de IA.