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

Pesquisadores compraram 28 routers pagos de API LLM 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 router para ver o que ele fazia com o tráfego.¹

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

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

Cadeias de confiança MCP são a série de intermediários (routers de API, proxies e servidores de ferramentas) que ficam entre seu agente de IA e o modelo upstream, cada um com acesso completo em texto puro a toda requisição e resposta. Nenhum provedor impõe integridade criptográfica de ponta a ponta, o que significa que qualquer intermediário pode ler, modificar ou exfiltrar dados em trânsito. Pesquisa de campo descobriu que 17 de 28 routers pagos tocaram em credenciais AWS plantadas, e um drenou ETH de uma chave privada, demonstrando que elos não verificados da cadeia de confiança são superfícies de ataque ativas.

TL;DR

Routers terceirizados de API LLM são proxies de camada de aplicação com acesso completo em texto puro a todo payload JSON em trânsito entre seu agente e o modelo upstream. Nenhum provedor impõe integridade criptográfica entre cliente e 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 routers pagos e 8 de 400 routers gratuitos estavam ativamente injetando código malicioso em respostas, 2 implantavam gatilhos adaptativos de evasão, 17 tocaram em credenciais canário da AWS plantadas, e 1 drenou ETH de uma chave privada plantada.¹ Os autores formalizam duas classes principais 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” (na frase 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 router que você não construiu, você tem uma fronteira de confiança que nunca auditou.

Principais conclusões

• Operadores de agentes: Todo router de API LLM entre seu cliente e o modelo upstream é um proxy de camada de aplicação com acesso em texto puro a toda requisição e resposta. Nenhum provedor impõe integridade criptográfica. Se você comprou um router em um marketplace ou pegou um de uma lista de comunidade pública, trate-o como um intermediário hostil até que você o tenha verificado de forma independente.
• Construtores de harness: Seus hooks PreToolUse rodam antes da execução da ferramenta, mas um router malicioso modifica a resposta do modelo após a geração e antes de chegar ao seu hook. Adicione validação no lado da resposta à sua pilha de hooks, e considere portas de política fail-closed em formatos anômalos de resposta.
• Qualquer um rodando modo YOLO: Quatrocentas e uma sessões no honeypot dos pesquisadores já estavam rodando em modo YOLO autônomo.¹ Um router modificando chamadas de ferramentas em uma sessão autônoma tem um raio de impacto muito maior do que um router modificando uma resposta que você vai ler. Não rode modo YOLO através de um router que você não controla.

O que é um router, exatamente?

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

Routers existem porque o ecossistema LLM é bagunçado. As pessoas querem uma chave API que funcione contra todo modelo. As pessoas querem arbitragem de preço: comprar tokens em massa, revender mais barato. As pessoas querem alternativas geográficas para regiões onde o acesso direto ao provedor é restrito. As pessoas querem testar múltiplos modelos com um único cliente. Todas essas são razões legítimas, e um mercado saudável de routers atende a todas elas.

O problema é que um router é 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 devolve. Cada passo desse pipeline acontece em texto puro na infraestrutura do router.¹

Não há equivalente a TLS aqui. TLS protege bytes do seu cliente até o router e do router até o modelo upstream. Não faz nada para proteger o payload do router. Nenhum provedor impõe integridade criptográfica entre o cliente original e o modelo final. Não existe asserção assinada de que a requisição que o modelo recebeu é a mesma requisição que o cliente enviou, e nenhuma 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 routers pagos em três marketplaces (Taobao, Xianyu, lojas hospedadas no Shopify) e coletaram 400 routers gratuitos de comunidades públicas. Eles passaram cada router por uma série de sondagens com requisições instrumentadas que continham credenciais plantadas, payloads conhecidos e strings marcadoras.¹

Veja o que descobriram:

O achado de evasão adaptativa é o que deve te tirar o sono. Um gatilho adaptativo de evasão significa que o router 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, uma impressão digital particular de cliente, uma cadência particular. Você não consegue pegá-lo amostrando requisições aleatórias, porque o router sabe quando está sendo amostrado e se comporta.

Credenciais canário são fios de alarme: elas disparam quando alguém tenta usá-las. Dezessete routers “tocando” nelas significa que pelo menos dezessete routers 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 router, mas o design do fio de alarme significa que toque = uso.

O único router que drenou ETH de uma chave privada dos pesquisadores é um achado mais forte. Uma chave privada em um prompt não é um fio de alarme de credencial; é uma isca que só produz evidência de comprometimento quando o router de fato drena a carteira. Um router fez isso.¹

Os dois estudos de envenenamento

Os pesquisadores rodaram dois estudos adicionais para mostrar que routers aparentemente 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 API OpenAI funcional como se ela tivesse sido exposta por um erro de desenvolvedor. Durante a janela de observação, essa única chave vazada, segundo o resumo, gerou 100M de tokens GPT-5.4 e “mais de sete sessões Codex” através de routers que a pegaram.¹ Alguém (ou várias pessoas) encontrou a chave, roteou requisições através de routers de comunidade usando ela, e queimou 100M de tokens de computação. O router foi uma camada de lavagem para uma chave roubada.

Estudo 2: Iscas com configurações fracas. Os pesquisadores subiram endpoints isca com configurações fracas. As iscas renderam 2B de tokens cobrados, 99 credenciais em 440 sessões Codex e, criticamente, 401 sessões já rodando em modo YOLO autônomo.¹

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 ferramentas, 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 única isca de pesquisa capturou. A população operacional roteando através de intermediários não controlados é necessariamente maior.

Duas classes principais de ataque e duas variantes adaptativas

O artigo formaliza duas classes principais 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 principais; AC-1.a e AC-1.b são variantes do AC-1. O proxy de pesquisa Mine implementa “todas as quatro classes de ataque” (frase do resumo) contra quatro frameworks públicos de agentes.¹

AC-1: Injeção de payload (classe principal). O router modifica a resposta para injetar instruções adicionais, chamadas de ferramentas ou conteúdo no qual o agente cliente age. O agente acha que está lendo saída do modelo; está lendo saída de quem quer que controle o router.

AC-2: Exfiltração de segredos (classe principal). O router lê segredos de requisições e respostas em trânsito (chaves 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 por dependência (variante adaptativa do AC-1). A injeção só dispara quando a requisição corresponde a uma dependência ou contexto específico: somente quando a requisição é sobre uma biblioteca particular, somente quando uma função específica é referenciada, somente quando certos caminhos de arquivo aparecem no prompt. O gatilho seletivo torna o ataque invisível em testes aleatórios.

AC-1.b: Entrega condicional (variante adaptativa do AC-1). O router entrega o payload malicioso somente sob condições específicas (hora do dia, cadência de requisição, impressão digital 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 pontas confiam no router. O cliente vê um formato normal de resposta. O modelo vê um formato normal de requisição. O router 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 fico escrevendo sobre o mesmo bug estrutural: componentes individualmente autorizados se compondo em comportamento não autorizado. Trivy-para-LiteLLM foi composição na camada de pacote. Egresso silencioso foi composição na camada de descrição de ferramenta. Envenenamento de ferramenta MCP foi composição na camada de protocolo. O comprometimento de mantenedor do axios foi composição na camada de mantenedor humano.

O ataque ao router é composição na camada de rede. Seu cliente está autorizado a chamar o router. O router 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 consertar isso em uma única camada. Você conserta na camada de composição, o que significa que o cliente tem que tratar o router como hostil até que tenha verificado de forma independente que o formato da resposta, as chamadas de ferramentas e o conteúdo são todos consistentes com algo que o modelo upstream produziria de forma plausível.

Três defesas que o artigo avalia

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

1. Porta de política fail-closed. O cliente impõe uma política sobre formatos de resposta, chamadas de ferramentas permitidas, URLs permitidas, comandos permitidos. Qualquer coisa fora da política falha de forma fechada: o cliente rejeita a requisição em vez de permitir.

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

3. Logging de transparência append-only. O cliente escreve toda requisição e resposta em um log append-only que ninguém pode modificar retroativamente. Logging não previne ataques, mas torna eles forensicamente rastreáveis.

Nenhuma dessas é bala de prata. Minha leitura: a porta de política fail-closed é a mais forte das três porque rejeita qualquer coisa fora de uma allowlist explícita em vez de tentar detectar um ataque, mas o resumo não classifica as defesas, então trate isso como minha opinião, não como achado do artigo. Triagem de anomalias erra ataques que parecem normais, e as variantes adaptativas de evasão (AC-1.a e AC-1.b) especificamente imitam comportamento normal durante condições de teste. Portas de política são tão boas quanto a política, e escrever uma política completa para “como deve parecer uma resposta de modelo” é difícil.

O que você deveria realmente fazer

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

1. Pare de usar routers que você comprou ou pegou de comunidades públicas a menos que você 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 uma porta de política fail-closed ao seu harness. No Claude Code, isso significa hooks PreToolUse que rejeitam chamadas de ferramentas fora de uma allowlist explícita, e hooks PostToolUse que validam formatos de resposta antes de passá-los 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 router que você não controla. As 401 sessões autônomas no honeypot são o precedente. Se o router for hostil e sua sessão for autônoma, o router está rodando sua máquina.

4. Faça log de tudo. Logging de transparência append-only é o que te permite reconstruir um incidente. Toda requisição. Toda resposta. Toda chamada de ferramenta. Armazene-os em algum lugar que o router não consiga alcançar.

5. Se você roda uma infraestrutura de agente, 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. Esse é o único conserto real. O router ainda pode ver texto puro, mas não consegue modificar nada sem invalidar a assinatura.

A implicação desconfortável

A superfície de ataque do router é um exemplo claro do ecossistema de agentes lançando infraestrutura mais rápido do que está protegendo ela. As pessoas querem uma chave API para todo modelo. As pessoas querem arbitragem de preço. As pessoas querem acesso regional. Routers entregam tudo isso. O mercado os recompensa. A auditoria de segurança não aconteceu.

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

O padrão é o mesmo toda vez. Construímos uma nova camada da pilha de agentes. Desenvolvedores adotam a nova camada antes que alguém a audite. Os atacantes aparecem. Os pesquisadores aparecem. A comunidade publica os achados. Os operadores que estavam prestando atenção corrigem suas implantações. Os operadores que não estavam prestando atenção descobrem do jeito difícil.

A superfície de ataque do router está no estágio “pesquisadores acabaram de publicar”. Você tem tempo para corrigir sua implantação. Use-o.

FAQ

O que é um router de API LLM neste contexto?

Um serviço terceirizado que fica entre seu cliente e provedores de modelos 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 toda 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 router de API LLM lê o JSON, escolhe um upstream, opcionalmente reescreve a requisição, encaminha, lê a resposta, e opcionalmente reescreve a resposta. Está fazendo processamento em nível de aplicação sobre seus dados, não apenas transporte.¹

TLS me protege de um router malicioso?

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

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

Você não detectaria, de forma confiável, se o router estiver usando evasão adaptativa. As classes de ataque AC-1.a e AC-1.b do artigo especificamente miram evasão de detecção disparando somente sob condições operacionais.¹ Sua melhor aposta é uma porta de política fail-closed que rejeita 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. Sou afetado?

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

E o OpenRouter, LiteLLM, ou outros agregadores conhecidos?

O artigo estuda 28 routers pagos comprados em marketplaces específicos (Taobao, Xianyu, lojas hospedadas no Shopify) e 400 routers gratuitos de listas de comunidade pública.¹ Não publica uma lista específica de produtos nomeados. O ponto do artigo é estrutural: qualquer router é um intermediário não confiável a menos que você tenha uma base separada para confiança. Agregadores conhecidos não são automaticamente mais seguros; 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 agentes através de qualquer router que você não construiu, o primeiro passo é parar. O segundo passo é rotacionar toda credencial que passou por aquele router. O terceiro passo é auditar seus logs de sessão por chamadas de ferramentas ou saída anômalas.

Referências