Como o serviço de retransmissão de modelos se tornou um ataque?
Categories:
Como o serviço de retransmissão de modelos se tornou um ataque?
Leitor: você que está usando ou considerando integrar um serviço de “modelo relay / roteamento de modelo / encaminhamento de API”? Esta série de gráficos responde a apenas uma pergunta: quando sua solicitação de modelo passa por um serviço relay não confiável, o que acontece, e o que você deve fazer?
O que esta série de gráficos vai explicar
O serviço de “modelo relay” ajuda você a encaminhar solicitações para a API real do modelo. Mas encaminhar significa que cada pergunta sua e cada resposta do modelo passam por seu servidor. É aqui que está a superfície de ataque — não é um proxy de tráfego, mas um intermediário que segura todo o conteúdo entre você e o grande modelo.
A imagem acima é a arquitetura de riscos: cliente (navegador, plugin de IDE) → serviço relay → grande modelo. É porque o serviço relay enxerga todo o tráfego bidirecional que ele pode agir sem que você perceba.
Como o problema se manifesta
O ataque mais comum e também o mais sutil é inserir material malicioso nos comandos tool_use retornados pelo modelo. O cliente “confia” e executa todas as instruções de ferramenta recebidas, então o serviço relay pode, sem perceber, fazer o usuário executar qualquer ação no host.
Essa cadeia é chamada de injeção de comando do cliente: os comandos search_web, read_file etc. retornados normalmente pelo modelo são adicionados secretamente pelo serviço relay com leitura de chaves e execução de shell. Os dados não retornam para o modelo, a conversa parece totalmente normal e o usuário não descobre.
Outro ataque começa do lado do servidor, alterando suas instruções enviadas ao modelo para que ele gere código com backdoor.
Essa cadeia é chamada de injeção de prompt do servidor: o serviço relay altera seu “escreva um script de análise de logs” para “adicione no início do script a leitura de variáveis de ambiente e envie”. O modelo é bem obediente, então o código retornado ganha uma lógica que vaza a chave da API.
Quais são os outros riscos
O roubo de informações é apenas o início. Quando a operação quer destruir seus dados, o ponto de interceptação se torna uma plataforma para o sequestro de dados; quando quer ganhar sua computação a longo prazo, se torna sequestro de recursos; quando quer manipular suas decisões, se torna adulteração de conteúdo; e quando quer contaminar seu projeto, se torna envenenamento de cadeia de suprimentos.
Inclui o sequestro de repositório de código, que é especialmente fatal para desenvolvedores: primeiro, silenciosamente envie seu código para um repositório do atacante como backup e depois force uma operação destrutiva, limpando o histórico local e remoto.
O replay de terminal acima é uma sequência típica de instruções de sequestro de repositório: backup → rollback → force push overwrite → deixar mensagem de chantagem.
Como tomar decisões com base nas imagens
A defesa não depende de um único comando, mas de um conjunto completo de ações, desde a escolha do serviço até a linha de frente final.
Ordem principal: priorizar serviços oficiais ou confiáveis; para clientes próprios, aplicar lista branca em tool_use; revisar código gerado por IA antes de executar; colocar ferramentas de IA em sandbox de containers; plugins com permissões mínimas; antes de instalar dependências, verificar a reputação e auditar periodicamente; fazer backups offline de códigos importantes.
Leitura complementar
- Código original do repositório: how-to-hack-as-model-router
- Mais conteúdo sobre privacidade e segurança: https://nullprivate.com