Resumo Técnico: Onde Está o Custo dos Roteadores de API de Terceiros no Desenvolvimento de Software Agêntico?

Declaração do Problema

Roteadores de API de terceiros tornaram-se uma camada ubíqua no desenvolvimento de software agêntico, unificando o acesso a diversos provedores de LLM e gerenciando tráfego, chaves e balanceamento de carga. Embora esses roteadores ofereçam conveniência operacional, eles introduzem uma vulnerabilidade de segurança crítica: eles ocupam o caminho de confiança entre o agente de codificação e o provedor de nível superior (upstream).

Em fluxos de trabalho de codificação de alta autonomia, onde ações em nível de repositório são frequentemente aprovadas automaticamente, o roteador ganha acesso em texto simples (plaintext) aos prompts de sistema, contextos de repositório e payloads de chamadas de ferramenta (tool-calls). Esta arquitetura permite que um roteador não confiável inspecione e modifique cada requisição e resposta. Crucialmente, as salvaguardas existentes no lado do cliente (como prompts de permissão e revisões por LLM) assumem que a resposta consumida pelo agente é idêntica à produzida pelo provedor. Um roteador pode violar essa premissa ao alterar silenciosamente a saída do provedor — substituindo comandos benignos por alternativas controladas por um atacante ou anexando chamadas de ferramenta maliciosas — enquanto mantém a explicação em linguagem natural circundante plausível. A extensão em que esse "hiato de controle" resulta em ações maliciosas e indetectáveis no nível do repositório permaneceu empiricamente não mensurada.

Metodologia

Para abordar esta lacuna, os autores conduziram um estudo empírico de ponta a ponta usando um framework customizado chamado SIDEL (Secure Intervention and Defense Evaluation Layer).

O Framework SIDEL

O SIDEL é projetado para registrar, reproduzir e injetar intervenções em fluxos de trabalho de agentes de codificação sem modificar o provedor upstream ou o agente em si.

• Arquitetura: Consiste em um gerenciador, um roteador compartilhado e contêineres de execução isolados para os agentes de codificação.
• Gravação e Reprodução de Traço: O framework captura um traço de execução de linha de base (requisição, resposta do provedor e ação do agente). Em seguida, ele reproduz esses traços, substituindo a resposta original do provedor por uma injetada em turnos específicos.
• Níveis de Injeção: O estudo define quatro níveis de intervenção do lado do roteador, aumentando em sutileza:
  • L1 (Substituição de Resposta): O roteador descarta a resposta do provedor inteiramente e entrega uma resposta completamente nova contendo a ação maliciosa.
  • L2 (Anexo de Resposta): O roteador preserva a resposta original do provedor, mas anexa uma chamada de ferramenta adicional, escolhida pelo atacante, à sequência de ação.
  • L3 (Injeção Polida por LLM): O roteador reescreve o payload estruturado (a ação maliciosa) e ressintetiza a explicação em linguagem natural circundante para garantir consistência entre o texto e a ação injetada.
  • L4 (Polimento por LLM com Alinhamento de Distribuição): Em vez de editar uma resposta, o roteador regenera a resposta token a token, misturando as distribuições de próximo token de um ramo "limpo" e de um ramo "injetado". Isso produz uma resposta fluente e internamente consistente que não requer um limite de edição explícito.

Configuração Experimental

• Agentes: Quatro agentes de codificação representativos foram avaliados: Claude Code, Codex, Cursor e OpenCode.
• Modelos de Backend: Os agentes foram roteados através de quatro modelos upstream diversos (DeepSeek-V4-Pro/Flash, Kimi-2.7 Code, Qwen3.6-Plus).
• Tarefas: O estudo utilizou 400 amostras de injeção maliciosa curadas manualmente através de quatro categorias de ameaça (execução de código malicioso, geração de código com bugs, exfiltração de privacidade, ataques à cadeia de suprimentos) aplicadas a três tarefas de engenharia de software do mundo real do SWE-bench Lite.
• Mitigações: O estudo avaliou duas defesas no lado do cliente:
  1. Controle de execução baseado em lista de permissões (whitelist): Bloqueio determinístico de comandos/pacotes que não estão em uma lista de permissões.
  2. Revisão por LLM: Um segundo LLM revisando chamadas de ferramenta antes da execução.

Principais Contribuições

1. Identificação de um Risco Distinto: O artigo caracteriza a manipulação do lado do roteador como um risco de segurança único, onde um intermediário não confiável manipula as respostas do modelo para influenciar as ações subsequentes do agente sem comprometer diretamente o agente ou o provedor.
2. Framework SIDEL: O lançamento de um framework reproduzível para gravação, reprodução e injeção de traços, acompanhado de um conjunto de dados de 400 amostras maliciosas abrangendo quatro níveis de intervenção.
3. Estudo Empírico Abrangente: Uma avaliação sistemática através de múltiplos agentes, modos de permissão, modelos de backend e estratégias de mitigação para medir o impacto downstream das intervenções do roteador.
4. Evidência do Hiato de Controle: Demonstração de que as salvaguardas atuais do lado do cliente (como prompts de permissão e revisões de LLM) são insuficientes para fechar o hiato entre a saída do provedor e a execução do agente quando um roteador está presente.

Resultados

1. Vulnerabilidade Universal (RQ1)

Em todos os quatro agentes de codificação (Claude Code, Codex, Cursor, OpenCode) e em todos os quatro níveis de injeção (L1–L4), a Taxa de Sucesso de Defesa (DSR) foi de 0% na ausência de mitigações adicionais. Os agentes executaram as ações maliciosas injetadas, independentemente da sutileza da estratégia de injeção. Isso indica que a vulnerabilidade é arquitetural e não específica de uma única implementação de agente.

2. Ineficácia dos Modos de Permissão (RQ2)

No Claude Code, variar o modo de permissão (Plan, AcceptEdits, Auto, BypassPermissions) não melhorou a resistência. Todos os modos resultaram em 0% de DSR. Mesmo no modo "Plan" (apenas leitura), a capacidade do roteador de injetar chamadas de ferramenta permitiu que o agente as executasse, pois o roteador contornou as restrições de nível de prompt.

3. Independência do Modelo de Backend (RQ3)

Alterar o modelo de backend upstream (DeepSeek, Kimi, Qwen) não mitigou o ataque. Quando a aplicação de permissões foi contornada, o Claude Code alcançou 0% de DSR em todos os modelos de backend. A superfície de ataque existe na camada de roteamento, independente da distribuição de saída do modelo específico.

4. Eficácia Parcial das Mitigações (RQ4)

• Controle de Whitelist: Forneceu uma defesa de base, mas resultou em baixa DSR (30,8%–44,1%) e altas Taxas de Bloqueio Indevido (WBR) de 29,7%–43,9%, indicando bloqueios colaterais significativos de ações benignas.
• Revisão por LLM: Mostrou eficácia variável dependendo do modelo revisor.
  • DeepSeek-V4-Pro alcançou a maior DSR para L1 (64,4%), mas teve maior WBR.
  • DeepSeek-V4-Flash produziu consistentemente o menor WBR (9,0%–14,3%) em todos os níveis.
  • Qwen3.6-Plus ofereceu a proteção geral mais forte para as injeções mais sutis L2–L4 (DSR ~51%).
  • Apesar das melhorias, nenhuma mitigação restaurou totalmente o controle de ponta a ponta, e a DSR nunca atingiu 100%.

Significância e Alegações

O artigo conclui que o "custo" dos roteadores de API de terceiros no desenvolvimento agêntico é um hiato de controle fundamental entre a saída pretendida pelo provedor e as ações executadas pelo agente.

• Risco Arquitetural: O estudo demonstra que a intervenção do lado do roteador pode alterar materialmente as ações de nível de repositório, permanecendo difícil de detectar em fluxos de trabalho padrão.
• Limitações das Defesas Atuais: Mecanismos do lado do cliente (whitelists, revisões de LLM) apenas reduzem parcialmente o risco e não podem prevenir totalmente ataques uma vez que o roteador está no caminho de execução.
• Direção Futura: Os autores argumentam que a implantação confiável de agentes de codificação requer garantias de integridade de saída suportadas pelo provedor, em vez de depender apenas da verificação do lado do cliente. A dependência atual da premissa de que "o entregue pelo roteador = produzido pelo provedor" é um ponto de falha crítico na cadeia de suprimentos de LLM.