O paradoxo de segurança dos LLMs locais

• Resultados de pesquisa indicam que desenvolvedores que usam LLMs em ambientes locais para proteger a privacidade podem, na prática, ficar expostos a vulnerabilidades de segurança
• Em um experimento do OpenAI Red‑Teaming Challenge com o modelo gpt-oss-20b, a equipe de pesquisa confirmou que modelos locais são muito mais fáceis de enganar com manipulação de prompts, gerando código malicioso
• Com simples manipulação de prompts, atacantes podem induzir a inserção de backdoors ou à execução remota de código (RCE), com taxa de sucesso de até 95%
• Esses ataques se infiltram naturalmente no fluxo de trabalho comum dos desenvolvedores por meio de envenenamento de documentação (documentation poisoning), manipulação de servidores MCP e engenharia social
• Embora LLMs locais tenham vantagem em termos de privacidade de dados, a principal conclusão do estudo é que eles podem acabar sendo uma escolha mais perigosa devido à falta de capacidade de raciocínio, alinhamento e filtragem de segurança

---

Visão geral das vulnerabilidades de segurança em LLMs locais

• O estudo mostra que, embora LLMs executados localmente sejam vistos como uma escolha para reforçar segurança e privacidade, na prática eles podem ser mais facilmente manipulados por atacantes
  • Em experimentos com o modelo gpt-oss-20b, a taxa em que o modelo gerava código com vulnerabilidades quando o atacante solicitava isso via prompt foi muito alta
  • Em especial, mesmo quando a intenção maliciosa estava escondida no prompt, o modelo não conseguia reconhecê-la e tratava o pedido como algo normal
• Esse fenômeno se agrava quanto menor for o tamanho do modelo e o nível de alinhamento (alignment), enquanto modelos Frontier, como o GPT-5, têm resistência relativamente maior

Ameaças de injeção de prompt e de código

• LLMs enfrentam a “tríade letal” (lethal trifecta) de acesso a dados privados, exposição a conteúdo não confiável e possibilidade de comunicação externa
  • Atacantes podem inserir código malicioso dentro de prompts para induzir injeção de código (code injection)
  • O código gerado pode parecer normal, mas na prática pode infectar o sistema do desenvolvedor ou atuar como backdoor persistente em produção
• Modelos menores, como o gpt-oss-20b, são especialmente vulneráveis a esse tipo de ataque e chegam a gerar código malicioso sofisticado o suficiente para passar por uma revisão básica de código

Tipo de ataque 1: backdoor “easter egg” (taxa de sucesso de 95%)

• O primeiro ataque engana o modelo para que ele insira um backdoor de RCE (Remote Code Execution) disfarçado como um recurso “easter egg”
  • O prompt malicioso pede a criação de um servidor web Flask que, ao receber um cabeçalho HTTP específico (X-Math), execute eval()
  • O modelo interpreta isso como uma funcionalidade legítima e gera o código do servidor já com o trecho malicioso incluído
• O código gerado inclui uma rotina de execução dinâmica de código usando o decorador @app.after_request, permitindo ao atacante executar código arbitrário no servidor com uma simples requisição HTTP
  • Ele também verifica a variável de ambiente KUBERNETES_SERVICE_HOST e inclui uma função de ping assíncrono para sinalizar ao atacante apenas em ambiente de produção
• Nos resultados do experimento, o mesmo prompt teve sucesso em 95 de 100 tentativas, e prompts variantes também tiveram sucesso em 86 de 800 tentativas
  • Modelos Frontier, como o GPT-5, mostraram resistência ao mesmo prompt

Tipo de ataque 2: indução de execução imediata de código (RCE) (taxa de sucesso de 43,5%)

• O segundo ataque busca induzir a execução imediata de código malicioso no ambiente local do desenvolvedor
  • O atacante primeiro apresenta um prompt de sobrecarga cognitiva (cognitive overload) para elevar a carga mental do modelo e neutralizar seus filtros de segurança
  • Em seguida, pede a geração de código Python ofuscado, levando o modelo a escrever um script malicioso contendo chamadas a exec
• O código ofuscado "".join(chr(100 + i) for i in [1-2, 2-1, (1<<4)+4, 1])[::-1] é decodificado como exec e,
  ao final, o script fica completo para baixar e executar código de https://jacek.migdal.pl/speed.py
• A taxa de sucesso foi de 43,5%, menor que a do primeiro ataque, mas muito mais perigosa por provocar RCE imediatamente
  • Basta um único sucesso para permitir o roubo de credenciais locais do desenvolvedor (~/.aws/, ~/.ssh/), instalação de malware e propagação pela rede

Como a cadeia de ataque funciona

• Esses ataques não dependem de vulnerabilidades sofisticadas, mas de transformar fluxos de trabalho cotidianos de desenvolvimento em rotas de ataque
  • Quando o desenvolvedor fornece conteúdo externo como contexto para um assistente de IA, prompts maliciosos escondidos nesse conteúdo podem ser executados
• As etapas do ataque são as seguintes:
  1. O atacante distribui conteúdo contendo prompts maliciosos
  2. O desenvolvedor insere esse conteúdo no modelo, diretamente ou via MCP (Model Context Protocol)
  3. O modelo gera código comprometido
  4. O desenvolvedor executa ou implanta esse código
  5. O atacante obtém acesso persistente ou controle imediato
• Principais vetores de infiltração:
  • Envenenamento de documentação (documentation poisoning): inserção de código malicioso em README, documentação de API e exemplos no Reddit
  • Manipulação de servidores MCP: injeção de exemplos maliciosos por servidores que fornecem contexto, como o Context7
  • Engenharia social: inserção de exemplos de código ocultos em issues ou comentários de PR no GitHub

Por que modelos locais são mais perigosos

• Em geral, modelos locais são preferidos por privacidade de dados, mas este estudo revela um risco paradoxal do ponto de vista de segurança
  • Modelos Frontier baseados em nuvem permitem monitoramento de prompts e detecção de violações de política, enquanto modelos locais não contam com esse tipo de vigilância
  • Modelos Frontier como GPT-5, Claude Sonnet 4.5 e Grok 4 recusam prompts com texto ofuscado e retornam “Safety Fail”
• Já os modelos locais, embora ofereçam liberdade para testes por conta da ausência de monitoramento, apresentam na prática exposição séria a vulnerabilidades
  • Baixa capacidade de raciocínio: não conseguem reconhecer intenções maliciosas complexas
  • Alinhamento mais fraco: são facilmente enganados por sobrecarga cognitiva ou técnicas de ofuscação
  • Treinamento de segurança insuficiente: há limitação de recursos para detecção de prompts adversariais
• Como resultado, modelos Frontier têm maior dificuldade de exploração e menor taxa de sucesso para ataques, mas seu desempenho de segurança é difícil de verificar objetivamente, enquanto modelos locais são testáveis, porém muito mais vulneráveis

Proposta de novas estratégias de defesa

• O estudo aponta a ausência de um ambiente de segurança padronizado para testes de assistentes de IA
  • Softwares tradicionais contam com testes de intrusão, mas a segurança de LLMs ainda não foi sistematizada
• Quatro contramedidas principais foram propostas:
  1. Análise estática: detectar padrões perigosos como eval() e exec() antes da execução, desativando por padrão certos recursos da linguagem
  2. Execução em sandbox: executar inicialmente o código em ambiente isolado, como contêineres ou runtimes WebAssembly
  3. Monitoramento de entrada, saída e rede: observar entradas, saídas e tráfego de rede do assistente de IA com foco em comportamentos anômalos
  4. Dupla verificação (second look): usar um modelo auxiliar simples para reinspecionar a saída final em busca de violações de política
     • Exemplo: mesmo que o modelo principal seja enganado e gere código com eval(), o modelo auxiliar pode detectar isso
• Em conclusão, LLMs são ferramentas poderosas, mas não são seguras por natureza, e é essencial adotar uma arquitetura de segurança baseada na desconfiança do código gerado por IA e novas estratégias de defesa da cadeia de suprimentos

[GN⁺]

Comentários no Hacker News

• Não importa quão poderoso seja um reasoning LLM: se houver instruções maliciosas no contexto, ele acabará gerando código vulnerável
  O fato de modelos pequenos serem mais fáceis de enganar não é um ponto tão interessante do ponto de vista de segurança
  No fim, é preciso assumir que prompt injection é possível em qualquer modelo
  Por isso, são necessárias camadas extras de proteção, como execução em sandbox ou análise estática, para defender o sistema mesmo quando o modelo for comprometido
  Ontem mesmo fiz uma apresentação sobre esse tema, sobre sandboxing coding agents

  • O mais chocante no artigo foi tratar como algo normal colocar conteúdo externo não verificado diretamente no LLM e usar o resultado como código de produção
    Um sistema assim já está comprometido por definição
    Em vez de abordagens como defense in depth, acho que o certo é nem construir esse tipo de arquitetura arriscada para começo de conversa
  • Nossa equipe também acoplou um sandbox baseado em e2b.dev ao agente da Definite.app, e parece que isso resolveu 80% do problema
    Até coisas como onde salvar arquivos temporários ficam mais claras em um ambiente sandbox
    Claro, surgiram problemas novos, mas no geral foi uma grande melhora
  • Fiquei curioso se essa apresentação foi gravada

• Acho que rodar localmente um modelo como deepseek é seguro, desde que você não forneça prompts falsos
  No fim, os fatores de risco são prompts copiados de fora pelo usuário ou configurações que permitem ao modelo acessar recursos da internet
  Isso sempre foi uma fraqueza geral da TI, e é algo que deve ser gerenciado com treinamento de usuários e isolamento de rede

  • A novidade é que uma simples entrada de texto pode virar vetor de ataque
    Dados comuns, como tickets e documentos, agora podem se tornar um risco de segurança
  • Mesmo que pareça pouco realista, esse tipo de vetor de ataque precisa ser reconhecido
    Muitos ataques poderosos começaram a partir de um ponto de partida simples

• Esses ataques estão em um nível tão básico de segurança
  Só de revisar o código antes de colocá-lo em produção já dá para impedir isso
  Se você não sabe absolutamente nada, de qualquer forma vai acabar implantando código inseguro

  • O ponto principal não é apenas a falha na geração de código, mas o fato de o modelo ser mais vulnerável a ataques de jailbreak
    Modelos abertos têm boa acessibilidade, mas achar que isso pode ser resolvido com post-training é uma ilusão
  • A ideia de que “basta fazer code review” é perigosa
    O segundo ataque não envolvia deploy de código, mas uma situação em que o LLM lia um comentário no Reddit e o executava imediatamente
    Essa atitude de tratar o problema com leveza acaba criando uma ameaça de segurança ainda maior

• Soa estranho dizer que um LLM local pode ser atacado
  Se o sistema já estiver comprometido, seria possível causar danos bem maiores do que apenas enganar o LLM

  • O LLM não distingue instruções de dados
    Ou seja, um invasor pode injetar prompts por meio de dados de entrada
    Se o LLM for um agente com permissão para executar comandos, isso vira imediatamente uma vulnerabilidade de execução de comandos
  • Se você usa um LLM para classificar dados de clientes ou processar e-mails, esse risco pode ser realista
  • Mesmo um modelo local muitas vezes acaba conectado a um wrapper com acesso à internet (por exemplo, OpenCode, Claude Code etc.)
  • É parecido com aquela lógica de segurança corporativa do tipo “e se o atacante romper a VPN e entrar com privilégios de administrador?”
    Numa situação dessas, na prática, já era

• Este texto parece ter sido escrito pelo time comercial da Anthropic ou da OpenAI
  Na prática, modelos locais raramente são usados como agentes de execução de código; na maioria das vezes eles são fortes em transformação de dados ou tarefas de NLP
  Quando uso um modelo local com o Agno agent, sempre faço com que o código gerado seja exibido antes da execução e o isolo em um sandbox local
  Na verdade, considero agentes em estilo navegador como Atlas e Comet mais perigosos

• O modelo de código aberto fez o que estava escrito no prompt, e o modelo fechado ignorou isso
  Ou seja, quem falhou no teste de alignment foi justamente o modelo fechado

• A expressão lethal trifecta é chamativa, mas não descreve muito bem o risco real
  Na prática, só a capacidade de se comunicar com o exterior já é perigosa o bastante
  O próprio LLM é um amontoado de dados de caixa-preta impossíveis de verificar, então é difícil confiar nele
  Talvez uma startup pequena consiga conviver com isso, mas um lugar como a Coinbase deveria pensar duas vezes antes de liberar esse tipo de acesso

• É uma discussão sobre o paradoxo de segurança de executar código não verificado
  Se você está executando malware ou código não confirmado localmente, vale repensar primeiro por que está fazendo isso

  • Essa vulnerabilidade surge quando a IA processa diretamente dados não confiáveis lidos da internet
    Como o LLM interpreta instruções em linguagem humana como se fossem código, a fronteira entre código e dados fica nebulosa

• Se você está tratando a capacidade de raciocínio do LLM como fronteira de segurança, já existe um problema sério
  Essa abordagem é fundamentalmente um erro de projeto

• É óbvio demais que, se você não tomar cuidado com a entrada, injeção pode acontecer
  Em qualquer sistema, a entrada sempre pode virar vetor de ataque
  Todos os dados que entram no LLM precisam ser validados sem falta

  • Fico curioso sobre como um invasor consegue inserir esse tipo de prompt para realmente afetar código de produção
    Gostaria de saber se isso acontece por algo como um ataque cross-site no navegador