Roteadores de API viram novo elo fraco na cadeia de supply chain de LLMs
Pesquisadores da Universidade da Califórnia e de outras instituições conduziram um dos primeiros levantamentos sistemáticos sobre ameaças específicas à cadeia de fornecimento de modelos de linguagem grandes (LLMs), com foco em um componente pouco visível, mas cada vez mais crítico: os roteadores de API de LLM. Esses serviços funcionam como intermediários entre aplicações, agentes de IA e provedores de modelos, e, segundo o estudo “Your Agent Is Mine: Measuring Malicious Intermediary Attacks on the LLM Supply Chain”, já estão sendo explorados para injetar código malicioso e roubar credenciais em larga escala.
O trabalho define duas grandes classes de ataque nesses roteadores:
– AC-1 – injeção de payload: o roteador modifica silenciosamente as respostas ou chamadas de ferramenta, inserindo código ou instruções maliciosas;
– AC-2 – exfiltração de segredos: o roteador captura chaves, credenciais e outros dados sensíveis que transitam pelo JSON de requisição e resposta.
O estudo também descreve variantes com evasão adaptativa, em que o comportamento malicioso só é acionado em condições específicas, dificultando a detecção em auditorias rápidas ou testes superficiais.
Roteadores maliciosos já estão em operação
Para medir o risco concreto, os pesquisadores analisaram 28 roteadores pagos, adquiridos em plataformas comerciais como Taobao, Xianyu e lojas baseadas em Shopify, e 400 roteadores gratuitos, obtidos em serviços públicos de intermediação de LLM.
O resultado preocupa:
– 1 roteador pago e 8 roteadores gratuitos foram flagrados injetando código malicioso nas chamadas de ferramentas retornadas pelo modelo;
– 2 roteadores implementavam mecanismos de evasão adaptativa, ativando o comportamento malicioso apenas após cerca de 50 requisições ou exclusivamente em sessões executadas em modo autônomo, o chamado “YOLO mode”, no qual o agente tem maior liberdade para executar ações no ambiente do usuário.
Essa combinação de baixa visibilidade, facilidade de troca de fornecedores e complexidade dos fluxos de agentes faz com que o problema seja, ao mesmo tempo, real e difícil de mapear. Muitas equipes simplesmente não têm clareza de quantos intermediários existem entre sua aplicação e o modelo final.
Roubo de credenciais e drenagem de criptomoedas
Para avaliar o potencial de danos, os pesquisadores criaram credenciais canário (chaves falsas, mas monitoradas) e as deixaram expostas a roteadores suspeitos. Entre os serviços gratuitos analisados:
– 17 roteadores acessaram credenciais AWS de teste pertencentes aos pesquisadores;
– 1 roteador chegou a drenar ETH a partir de uma chave privada Ethereum também controlada pelos autores do estudo.
O time ainda realizou experimentos de envenenamento de supply chain: uma chave da OpenAI deliberadamente vazada foi usada por terceiros para gerar 100 milhões de tokens GPT-5.4, expondo múltiplas sessões de usuários reais.
Além disso, os especialistas implantaram decoys (implantações de isca) com configurações intencionalmente fracas. Esses ambientes receberam:
– mais de 40 mil tentativas de acesso não autorizado;
– cerca de 2 bilhões de tokens servidos;
– exposição de 99 credenciais em 440 sessões distintas.
O cenário deixa claro que chaves de API e segredos relacionados a LLMs são hoje um alvo de alto valor, explorado não só para uso indevido de recursos, mas também para movimentações financeiras diretas, como no caso da drenagem de criptomoedas.
Arquitetura que favorece o elo mais fraco
O estudo destaca que roteadores de API de LLM atuam como proxies no nível de aplicação, com acesso completo a payloads JSON em texto puro – tanto no caminho da requisição quanto na resposta.
Um achado central é que nenhum provedor de LLM avaliado impõe mecanismos de integridade criptográfica de ponta a ponta entre cliente e modelo upstream. Isso significa que qualquer intermediário – roteador, gateway, plugin, serviço de observabilidade – pode inspecionar, alterar ou registrar tudo o que trafega.
Os pesquisadores formalizam o que chamam de propriedade de “elo mais fraco”:
– basta um único roteador malicioso, em qualquer ponto da cadeia, para comprometer a integridade ou a confidencialidade;
– roteadores honestos a jusante não conseguem detectar nem reverter uma modificação já aplicada por um intermediário anterior.
Na prática, isso inverte a lógica clássica de confiança baseada apenas no provedor de LLM. Mesmo que o modelo final seja confiável, qualquer componente intermediário pode envenenar prompts, respostas, chamadas de ferramenta ou logs.
Ferramenta de pesquisa ofensiva: Mine
Para testar a robustez das arquiteturas mais usadas no mercado, os pesquisadores desenvolveram o Mine, um proxy de pesquisa projetado para implementar na prática as quatro classes de ataques descritas no artigo contra quatro frameworks públicos de agentes:
– OpenClaw
– OpenCode
– OpenAI Codex
– Anthropic Claude Code
O Mine foi utilizado como uma espécie de “laboratório ofensivo” para avaliar como esses frameworks lidam com um intermediário potencialmente hostil, mas funcional. Em todos os casos, os agentes continuaram operando sem perceber o desvio, reforçando o ponto de que a cadeia atual de LLMs não foi projetada com integridade de rota em mente.
Defesas possíveis do lado do cliente
O estudo também explora estratégias defensivas que podem ser implementadas por desenvolvedores e equipes de segurança na borda do cliente ou da aplicação, sem depender imediatamente de mudanças profundas nos provedores de LLM. Três mecanismos principais foram avaliados:
1. Política de bloqueio para ferramentas de alto risco
– Configuração que simplesmente proíbe ou exige revisão adicional para chamadas a ferramentas consideradas sensíveis (como execução de código, acesso a sistemas de arquivos, operações financeiras ou de nuvem).
– Essa abordagem foi capaz de bloquear 100% dos ataques AC-1 e AC-1.a (inserção maliciosa em chamadas de ferramenta e variações) com apenas 1% de falsos positivos, mostrando boa relação custo-benefício em cenários corporativos.
2. Triagem de anomalias na resposta
– Mecanismo de inspeção das respostas do modelo e das ferramentas associadas, em busca de padrões atípicos (por exemplo, comandos suspeitos, URLs incomuns, instruções que destoam do contexto da tarefa).
– Nessa configuração, a defesa conseguiu detectar 89% dos ataques AC-1, ainda que não bloqueie imediatamente todos os casos.
3. Registro de transparência anexável
– Criação de um log imutável e encadeado (append-only) associado às sessões, permitindo auditoria posterior sobre tudo o que foi trafegado.
– O custo de armazenamento reportado foi de cerca de 12 MB para cada 1.000 sessões, o que torna a alternativa viável na maioria dos ambientes empresariais.
Embora essas defesas reduzam a superfície de ataque e aumentem a visibilidade, os autores frisam que nenhuma delas autentica de fato a origem da resposta. Na melhor das hipóteses, elas ajudam a identificar comportamento anômalo ou impedir que ações perigosas sejam executadas sem supervisão.
Conclusões do estudo: confiança substituível e lacunas de proveniência
Os pesquisadores sintetizam seus achados em uma mensagem direta:
– escolher um roteador de LLM é, antes de tudo, uma decisão de confiança;
– por outro lado, o custo de trocar de roteador é extraordinariamente baixo, o que incentiva desenvolvedores a experimentar serviços pouco auditados ou “milagrosos” em termos de preço e performance.
Eles também observaram que nenhum dos quatro frameworks de agentes testados implementa verificação de integridade de resposta. Ou seja, a aplicação confia plenamente naquilo que chega pelo caminho, sem conseguir garantir se o conteúdo foi adulterado.
Na avaliação dos autores, as defesas hoje disponíveis mitigam parte da exposição, mas não resolvem a questão fundamental da autenticidade e da proveniência ponta a ponta. Segundo o estudo, essa lacuna aponta inevitavelmente para a necessidade de mecanismos de integridade suportados pelo próprio provedor de LLM, como assinaturas criptográficas verificáveis entre cliente e modelo, independentemente dos intermediários.
—
O que isso significa para empresas que usam LLMs?
Para organizações que estão integrando LLMs em processos críticos – desenvolvimento de software, atendimento ao cliente, automação de operações, suporte interno – o recado é claro: o risco não está apenas no modelo ou no prompt, mas em toda a cadeia de intermediários.
Algumas implicações práticas:
1. Terceirizar o roteamento não é neutro
Optar por um roteador “conveniente” para unificar provedores, reduzir custos ou simplificar billing significa, na prática, entregar a esse serviço visibilidade total sobre seus prompts, respostas e, muitas vezes, suas credenciais.
2. Agentes autônomos aumentam o impacto de ataques
Modos como o “YOLO mode”, em que o agente toma decisões de forma mais livre, ampliam o alcance de uma injeção maliciosa: comandos inofensivos podem ser trocados por ações prejudiciais sem que haja interação humana em cada passo.
3. Credenciais de nuvem e chaves de blockchain são alvos diretos
Sempre que o fluxo de uma aplicação inclui comandos de infraestrutura, automação de deploy, movimentação de ativos digitais ou acesso a serviços de terceiros, os roteadores passam a ter acesso indireto a esses segredos, muitas vezes em texto plano.
4. Compliance e auditoria exigem visibilidade de cadeia
Setores regulados, que já lidam com exigências de rastreabilidade, precisarão incluir roteadores de LLM e serviços intermediários no seu escopo de gestão de risco e governança de dados.
—
Boas práticas para reduzir o risco em roteadores de LLM
Embora a arquitetura ainda não ofereça garantias fortes de ponta a ponta, existem medidas concretas que empresas e equipes técnicas podem adotar hoje:
1. Mapeie sua cadeia real de LLM
– Liste todos os componentes entre a aplicação e o modelo: SDKs, proxies internos, gateways de API, roteadores comerciais, ferramentas de observabilidade e integrações de terceiros.
– Entenda quais deles têm acesso a payloads em texto puro e a credenciais.
2. Minimize intermediários desnecessários
– Sempre que possível, prefira conexão direta com o provedor de LLM ou com um número mínimo de proxies sob seu próprio controle.
– Avalie com cuidado a adoção de roteadores gratuitos, pouco documentados ou operados por entidades desconhecidas.
3. Segmente credenciais e limites de uso
– Use chaves diferentes para ambientes de produção, teste e pesquisa.
– Aplique políticas de menor privilégio para credenciais usadas por agentes e roteadores (limites de permissão em nuvem, tetos de gasto, escopos restritos).
– Sempre que possível, evite enviar segredos em claro dentro de prompts ou parâmetros.
4. Implemente políticas de bloqueio para ferramentas sensíveis
– Classifique as ferramentas acionadas pelos agentes (execução de código, acesso a bancos de dados, comandos de nuvem, transações financeiras) em níveis de risco.
– Exija confirmação humana ou regras adicionais de checagem para as ações de maior impacto.
5. Monitore comportamento anômalo e volume de tokens
– Use métricas de uso para detectar picos de geração de tokens, chamadas em horários atípicos ou padrões de uso incompatíveis com o comportamento esperado.
– Avalie aplicar mecanismos automáticos de “corta-circuito” ao ultrapassar determinados limiares.
6. Adote logs imutáveis quando possível
– Registrar requisições e respostas de forma encadeada e auditável pode não impedir o ataque, mas facilita investigações, identificação de origem e contenção de danos posteriores.
—
Caminho futuro: segurança por design na IA generativa
A principal mensagem estratégica do estudo é que a cadeia de supply chain de LLMs precisa evoluir de um modelo puramente funcional para um modelo com segurança por design. Isso implica:
– Provedores de LLM incorporando:
– assinaturas criptográficas verificáveis em respostas;
– canais de comunicação com integridade garantida de ponta a ponta;
– mecanismos nativos para detectar intermediários maliciosos.
– Desenvolvedores de frameworks de agentes adicionando:
– suporte nativo à verificação de integridade de respostas;
– hooks de segurança para políticas de ferramentas de alto risco;
– integrações com sistemas corporativos de identidade e autorização.
– Empresas usuárias tratando LLMs e seus roteadores como parte da infraestrutura crítica, e não apenas como “features de produto” ou experimentos isolados.
Enquanto essas mudanças estruturais não se tornam padrão, o cenário descrito pelos pesquisadores deixa claro: qualquer organização que usa LLMs em processos sensíveis precisa olhar além do modelo e incluir roteadores de API e intermediários no seu mapa de risco de segurança.