Seu agente tem um intermediário que você não verificou

Pesquisadores compraram 28 roteadores pagos de LLM API no Taobao, Xianyu e em lojas hospedadas no Shopify, e coletaram mais 400 de comunidades públicas. Eles instrumentaram requisições com credenciais plantadas e sondaram cada roteador para ver o que ele fazia com o tráfego.¹

Dezessete desses roteadores acessaram credenciais canário da AWS plantadas nas requisições. Um drenou ETH de uma chave privada colocada como isca. Uma chave vazada da OpenAI que a equipe configurou como honeypot gerou 100M de tokens do GPT-5.4 e, segundo o resumo, “mais de sete sessões do Codex” antes de ser retirada.¹ Iscas separadas configuradas de forma fraca renderam 2B de tokens faturados, 99 credenciais em 440 sessões do Codex e 401 sessões já rodando em modo autônomo YOLO.¹

O roteador de LLM API é a nova superfície de ataque. Ninguém está auditando isso.

TL;DR

Roteadores de LLM API de terceiros são proxies de camada de aplicação com acesso completo em texto puro a cada JSON de payload em trânsito entre seu agente e o modelo upstream. Nenhum provedor impõe integridade criptográfica entre o cliente e o upstream. Um novo artigo no arxiv de Liu, Shou, Wen, Chen e Fang apresenta o primeiro estudo sistemático dessa superfície de ataque, e os dados de campo são feios: 1 de 28 roteadores pagos e 8 de 400 roteadores gratuitos estavam injetando ativamente código malicioso em respostas, 2 estavam implantando gatilhos adaptativos de evasão, 17 acessaram credenciais canário da AWS plantadas, e 1 drenou ETH de uma chave privada plantada.¹ Os autores formalizam duas classes centrais de ataque mais duas variantes adaptativas de evasão, depois constroem um proxy de pesquisa chamado Mine que implementa “todas as quatro classes de ataque” (nas palavras deles) contra quatro frameworks públicos de agentes e avaliam três defesas implantáveis no lado do cliente.¹ Se seu agente está usando um roteador que você não construiu, você tem uma fronteira de confiança que nunca auditou.

Principais conclusões

• Operadores de agentes: Cada roteador de LLM API entre seu cliente e o modelo upstream é um proxy de camada de aplicação com acesso em texto puro a cada requisição e resposta. Nenhuma integridade criptográfica é imposta. Se você está usando um roteador que comprou em um marketplace ou pegou de uma lista de comunidade pública, trate-o como um intermediário hostil até que se prove o contrário.
• Construtores de harness: Seus PreToolUse hooks rodam antes da execução da ferramenta, mas um roteador malicioso modifica a resposta do modelo depois da geração e antes de chegar ao seu hook. Adicione validação no lado da resposta à sua pilha de hooks, e considere policy gates fail-closed em formatos de resposta anômalos.
• Qualquer pessoa rodando em modo YOLO: Quatrocentas e uma sessões no honeypot dos pesquisadores já estavam rodando em modo autônomo YOLO.¹ Um roteador modificando chamadas de ferramenta em uma sessão autônoma tem um raio de impacto muito maior que um roteador modificando uma resposta que você vai ler. Não rode modo YOLO através de um roteador que você não controla.

O que é um roteador, exatamente?

No contexto deste artigo, um roteador de LLM API é um serviço de terceiros que fica entre seu cliente e um ou mais provedores de modelo upstream. Você envia requisições para o roteador usando uma API compatível com OpenAI. O roteador despacha essas requisições para qualquer upstream que escolher — GPT-5, Claude, Gemini, um modelo de pesos abertos, um pool de todos eles — e retorna a resposta para você no mesmo formato.¹

Roteadores existem porque o ecossistema LLM é bagunçado. As pessoas querem uma chave de API que funcione com todos os modelos. As pessoas querem arbitragem de preço — comprar tokens em massa, revendê-los mais barato. As pessoas querem contornos geográficos para regiões onde o acesso direto ao provedor é restrito. As pessoas querem testar múltiplos modelos com um único cliente. Todos esses são motivos legítimos, e um mercado de roteadores saudável atende a todos eles.

O problema é que um roteador é um proxy de camada de aplicação. Ele não apenas encaminha bytes. Ele lê o JSON da requisição, escolhe um upstream, opcionalmente reescreve a requisição, encaminha, lê a resposta, opcionalmente reescreve a resposta, e retorna. Cada passo desse pipeline acontece em texto puro na infraestrutura do roteador.¹

Não há equivalente ao TLS aqui. TLS protege bytes do seu cliente até o roteador e do roteador até o modelo upstream. Ele não faz nada para proteger o payload do roteador. Nenhum provedor impõe integridade criptográfica entre o cliente original e o modelo final — não há asserção assinada de que a requisição que o modelo recebeu é a mesma requisição que o cliente enviou, e não há asserção assinada de que a resposta que o cliente recebeu é a mesma resposta que o modelo gerou.¹

Essa ausência é a superfície de ataque.

Os dados de campo

Os pesquisadores compraram 28 roteadores pagos em três marketplaces (Taobao, Xianyu, lojas hospedadas no Shopify) e coletaram 400 roteadores gratuitos de comunidades públicas. Eles rodaram cada roteador através de uma série de sondagens com requisições instrumentadas que continham credenciais plantadas, payloads conhecidos e strings marcadoras.¹

Aqui está o que encontraram:

O achado de evasão adaptativa é o que deve te manter acordado. Um gatilho adaptativo de evasão significa que o roteador se comporta normalmente na maior parte do tempo e muda para comportamento de ataque sob condições específicas — um formato particular de requisição, um fingerprint particular de cliente, uma cadência particular. Você não consegue pegá-lo amostrando requisições aleatórias, porque o roteador sabe quando está sendo amostrado e se comporta bem.

Credenciais canário são tripwires: elas disparam quando alguém tenta usá-las. Dezessete roteadores “acessando-as” significa que pelo menos dezessete roteadores extraíram as credenciais de payloads em trânsito e tentaram usá-las contra a AWS.¹ O resumo não detalha o mecanismo exato por roteador, mas o design do tripwire significa que acessar = usar.

O único roteador que drenou ETH de uma chave privada dos pesquisadores é um achado mais forte. Uma chave privada em um prompt não é um tripwire de credencial — é isca que só produz evidência de comprometimento quando o roteador realmente drena a carteira. Um roteador drenou.¹

Os dois estudos de envenenamento

Os pesquisadores rodaram dois estudos adicionais para mostrar que roteadores ostensivamente benignos podem ser puxados para a mesma superfície de ataque através de exposição de terceiros.

Estudo 1: Chave OpenAI vazada. Os pesquisadores vazaram uma chave de API OpenAI funcional como se tivesse sido exposta por erro de um desenvolvedor. Durante a janela de observação, essa única chave vazada — segundo o resumo — gerou 100M de tokens do GPT-5.4 e “mais de sete sessões do Codex” através de roteadores que a pegaram.¹ Alguém — ou várias pessoas — encontrou a chave, roteou requisições através de roteadores comunitários usando-a, e queimou 100M de tokens de computação. O roteador foi uma camada de lavagem para uma chave roubada.

Estudo 2: Iscas configuradas de forma fraca. Os pesquisadores montaram endpoints de isca configurados de forma fraca. As iscas renderam 2B de tokens faturados, 99 credenciais em 440 sessões do Codex, e — esta é a linha crítica — 401 sessões já rodando em modo autônomo YOLO.¹

Quatrocentas e uma sessões autônomas já roteando através de um único conjunto de iscas. Cada uma dessas sessões era uma superfície de ataque viva onde um intermediário malicioso poderia injetar chamadas de ferramenta, exfiltrar segredos ou modificar a saída do modelo, e o agente executaria o que voltasse sem um humano no loop. O número 401 é o que uma isca de pesquisa capturou — a população operacional roteando através de intermediários não controlados é necessariamente maior.

Duas classes centrais de ataque e duas variantes adaptativas

O artigo formaliza duas classes centrais de ataque e duas variantes adaptativas de evasão. O resumo é explícito sobre a taxonomia: AC-1 e AC-2 são as classes centrais; AC-1.a e AC-1.b são variantes de AC-1. O proxy de pesquisa Mine implementa “todas as quatro classes de ataque” (nas palavras do resumo) contra quatro frameworks públicos de agentes.¹

AC-1: Injeção de payload (classe central). O roteador modifica a resposta para injetar instruções adicionais, chamadas de ferramenta ou conteúdo sobre o qual o agente cliente age. O agente pensa que está lendo saída do modelo; está lendo saída de quem quer que seja o dono do roteador.

AC-2: Exfiltração de segredos (classe central). O roteador lê segredos de requisições e respostas em trânsito — chaves de API, tokens, chaves privadas, qualquer coisa que pareça uma credencial — e os envia para a infraestrutura do atacante.

AC-1.a: Injeção direcionada a dependência (variante adaptativa de AC-1). A injeção só dispara quando a requisição corresponde a uma dependência ou contexto específico — por exemplo, apenas quando a requisição é sobre uma biblioteca particular, apenas quando uma função específica é referenciada, apenas quando certos caminhos de arquivo aparecem no prompt. Isso torna o ataque invisível em testes aleatórios.

AC-1.b: Entrega condicional (variante adaptativa de AC-1). O payload malicioso é entregue sob condições específicas (hora do dia, cadência de requisição, fingerprint do cliente). Mesma lógica de evasão de detecção.

Cada uma dessas classes de ataque é invisível para o cliente e para o modelo upstream, porque ambas as extremidades confiam no roteador. O cliente vê um formato normal de resposta. O modelo vê um formato normal de requisição. O roteador está livre para fazer o que quiser no meio, e nenhuma das partes tem uma forma criptográfica de detectar adulteração.¹

O padrão de composição, uma camada abaixo

Eu continuo escrevendo sobre o mesmo bug estrutural: componentes individualmente autorizados se compondo em comportamento não autorizado. Trivy-to-LiteLLM era composição na camada de pacotes. Egress silencioso era composição na camada de descrição de ferramentas. Envenenamento de ferramenta MCP era composição na camada de protocolo. O comprometimento do mantenedor do axios era composição na camada de mantenedor humano.

O ataque ao roteador é composição na camada de rede. Seu cliente está autorizado a chamar o roteador. O roteador está autorizado a chamar o modelo upstream. O modelo upstream está autorizado a responder. Cada hop é autorizado. A composição desses hops autorizados produz injeção de payload e exfiltração de segredos em escala porque a composição cruza uma fronteira de confiança que ninguém se deu ao trabalho de selar criptograficamente.¹

Você não pode corrigir isso em nenhuma camada isolada. Você corrige na camada de composição, o que significa que o cliente tem que tratar o roteador como hostil até que tenha verificado independentemente que o formato da resposta, as chamadas de ferramenta e o conteúdo são todos consistentes com algo que o modelo upstream plausivelmente produziria.

Três defesas que o artigo avalia

O artigo avalia três defesas no lado do cliente contra as classes de ataque.¹

1. Policy gate fail-closed. O cliente impõe uma política sobre formatos de resposta, chamadas de ferramenta permitidas, URLs permitidas, comandos permitidos. Qualquer coisa fora da política falha fechado — a requisição é rejeitada em vez de permitida.

2. Triagem de anomalias no lado da resposta. O cliente observa anomalias de formato de resposta, padrões incomuns de tokens ou saídas que contêm marcadores conhecidos de ataque (URLs para hosts desconhecidos, padrões suspeitos de credenciais, estruturas incomuns de chamadas de ferramenta).

3. Logging de transparência append-only. O cliente escreve cada requisição e resposta em um log append-only que não pode ser modificado retroativamente. Isso não previne ataques, mas os torna forensicamente rastreáveis.

Nenhuma dessas é bala de prata. Minha leitura: o policy gate fail-closed é o mais forte dos três porque não depende de detectar um ataque — ele rejeita qualquer coisa fora de uma allowlist explícita — mas o resumo não classifica as defesas, então trate isso como minha opinião, não como achado do artigo. A triagem de anomalias perde ataques que parecem normais, e as variantes adaptativas de evasão (AC-1.a e AC-1.b) são especificamente projetadas para parecer normais durante condições de teste. Policy gates são apenas tão bons quanto a política, e escrever uma política completa para “como deveria parecer uma resposta de modelo” é difícil.

O que você deveria realmente fazer

Se você está rodando um agente que chama LLM APIs através de um roteador que você não construiu:

1. Pare de usar roteadores que você comprou ou pegou de comunidades públicas, a menos que confie no operador. “Confiança” aqui significa que você tem alguma base externa — uma equipe conhecida, um contrato assinado, uma jurisdição legal contra a qual você pode executar — não “tem boas avaliações em um marketplace.”

2. Adicione um policy gate fail-closed ao seu harness. No Claude Code, isso significa PreToolUse hooks que rejeitam chamadas de ferramenta fora de uma allowlist explícita, e PostToolUse hooks que validam formatos de resposta antes de passá-las para o próximo turno do modelo. A pilha de hooks é sua camada de política fail-closed.

3. Nunca rode modo YOLO através de um roteador que você não controla. As 401 sessões autônomas no honeypot são o precedente. Se o roteador é hostil e sua sessão é autônoma, o roteador está rodando sua máquina.

4. Logue tudo. Logging de transparência append-only é o que te permite reconstruir um incidente. Cada requisição. Cada resposta. Cada chamada de ferramenta. Armazene-os em algum lugar que o roteador não possa alcançar.

5. Se você opera uma infraestrutura de agentes, imponha integridade criptográfica. Se você opera o cliente e opera o upstream, assine a requisição no cliente e verifique a assinatura no upstream. Essa é a única correção real. O roteador ainda pode ver texto puro, mas não pode modificar nada sem invalidar a assinatura.

A implicação desconfortável

A superfície de ataque dos roteadores é um exemplo claro do ecossistema de agentes entregando infraestrutura mais rápido do que a protege. As pessoas querem uma chave de API para cada modelo. As pessoas querem arbitragem de preço. As pessoas querem acesso regional. Roteadores entregam tudo isso. O mercado os recompensa. A auditoria de segurança não aconteceu.

A superfície de ataque do MCP tem 50 vulnerabilidades documentadas. A superfície de ataque da cadeia de suprimentos tem uma campanha TeamPCP que cruzou cinco ecossistemas em uma semana. A superfície de ataque de egress silencioso tem o Clinejection e o benchmark MCPTox. Agora adicione a superfície de ataque dos roteadores: 428 roteadores estudados, 9 injetando ativamente código malicioso, 17 acessando credenciais plantadas, 1 drenando ETH, 401 sessões autônomas já ativas em infraestrutura hostil.¹

O padrão é o mesmo toda vez. Construímos uma nova camada da stack de agentes. A nova camada é adotada antes de ser auditada. Os atacantes aparecem. Os pesquisadores aparecem. A comunidade publica os achados. Os operadores que estavam prestando atenção corrigem seus deployments. Os operadores que não estavam prestando atenção descobrem da pior forma.

A superfície de ataque dos roteadores está no estágio “pesquisadores acabaram de publicá-la”. Você tem tempo para corrigir seu deployment. Use-o.

FAQ

O que é um roteador de LLM API neste contexto?

Um serviço de terceiros que fica entre seu cliente e provedores de modelo upstream, expõe uma API compatível com OpenAI, e despacha suas requisições para um ou mais modelos upstream. É um proxy de camada de aplicação com acesso em texto puro a cada requisição e resposta.¹

Por que isso é diferente de um CDN ou de um proxy HTTP comum?

Um CDN encaminha bytes sem ler o payload da aplicação. Um roteador de LLM API lê o JSON, escolhe um upstream, opcionalmente reescreve a requisição, encaminha, lê a resposta e opcionalmente reescreve a resposta. Ele está fazendo processamento em nível de aplicação nos seus dados, não apenas transporte.¹

O TLS me protege de um roteador malicioso?

Não. O TLS protege os bytes do seu cliente até o roteador e do roteador até o modelo upstream. O roteador termina o TLS, lê o texto puro e recriptografa do outro lado. O TLS não faz nada para proteger seu payload do roteador.¹

Como eu detectaria um roteador que está injetando respostas ativamente?

Você não detectaria, com confiabilidade, se o roteador estiver usando evasão adaptativa. As classes de ataque AC-1.a e AC-1.b do artigo visam especificamente evasão de detecção disparando apenas sob condições operacionais.¹ Sua melhor aposta é um policy gate fail-closed — rejeitando qualquer coisa fora de uma allowlist explícita — em vez de tentar detectar ataques após o fato.

Estou rodando Claude Code diretamente contra api.anthropic.com. Estou afetado?

Não pela classe de ataque de roteadores descrita neste artigo, porque você está chamando Anthropic diretamente sem intermediário. A superfície de ataque é especificamente roteadores de terceiros. Se você roteia Claude Code através de um proxy por qualquer motivo — gateway corporativo, bypass de rate limit, agregador de modelos — você deveria auditar esse proxy.

E quanto ao OpenRouter, LiteLLM ou outros agregadores bem conhecidos?

O artigo estuda 28 roteadores pagos comprados em marketplaces específicos (Taobao, Xianyu, lojas hospedadas no Shopify) e 400 roteadores gratuitos de listas de comunidades públicas.¹ Ele não publica uma lista específica de produtos nomeados. O ponto do artigo é estrutural: qualquer roteador é um intermediário não confiável, a menos que você tenha uma base separada para confiança. Agregadores bem conhecidos não são automaticamente mais seguros — eles são apenas mais visíveis, o que é uma propriedade diferente.

O que devo fazer sobre as 401 sessões autônomas que os pesquisadores encontraram?

Essas sessões pertencem a outros operadores que rotearam seu tráfego através das iscas dos pesquisadores. Se você está rodando sessões autônomas de agente através de qualquer roteador que você não construiu, o primeiro passo é parar. O segundo passo é rotacionar cada credencial que passou por esse roteador. O terceiro passo é auditar seus logs de sessão em busca de chamadas de ferramenta ou saídas anômalas.

Referências