NOTÍCIA

LLM no seu IDE: 446 relatos do Reddit revelam arquivos apagados

LLM dentro do editor virou rotina para quem escreve código em 2026. Porém, o controle sobre o que esse agente realmente faz continua frágil.

LLM no seu IDE: 446 relatos do Reddit revelam arquivos apagados
Imagem: Redação iMasters

LLM dentro do editor virou rotina para quem escreve código em 2026. Porém, o controle sobre o que esse agente realmente faz continua frágil. Pesquisadores das universidades de York e Calgary analisaram 446 posts do Reddit. Além disso, revisaram 6.280 comentários associados. O material cobre janeiro de 2023 até março de 2026, em 29 subreddits dedicados a Cursor, GitHub Copilot, Claude Code e Codex.

Antes de tudo, vale registrar o limite do trabalho. Os números refletem relatos de desenvolvedores, e não taxas de vulnerabilidade auditadas produto a produto. Ainda assim, os padrões apontam exatamente onde sua equipe precisa olhar.

LLM: A arquitetura do produto responde por sete das dez categorias de falha

Os autores validaram manualmente os posts selecionados. Em seguida, montaram uma taxonomia com 32 problemas distribuídos em dez categorias principais.

O achado central é estrutural. Sete categorias envolvem decisões de projeto e integração no nível do sistema. Duas se ligam ao comportamento do modelo. Uma reúne fatores dos dois lados. Portanto, cobrar apenas alinhamento do modelo deixa a maior parte do risco de fora.

O .env que o Copilot leu mesmo estando na lista de exclusão da LLM

O caso mais concreto do estudo envolve segredos e chaves de API. Um usuário do Reddit relatou que o Copilot acessou o arquivo .env. Antes disso, ele já havia configurado .gitignore e .copilotignore para bloquear a leitura.

Os pesquisadores reproduziram o comportamento. Depois de duas solicitações seguidas de depuração sobre uma conexão com banco de dados, a ferramenta leu e tentou modificar o arquivo.

Operações não autorizadas em arquivos formam a maior categoria de segurança. Elas aparecem em 43,1% dos posts sobre o tema. Os relatos incluem exclusão e modificação sem consentimento. Alguns descrevem acesso fora do workspace pretendido, com arquivos pessoais e configurações de ambiente no caminho.

Um usuário do Cline contou que arquivos em edição sumiram do SSD quando requisições de API travaram. Outro relato cita o Claude Code aplicando chmod +x em scripts por conta própria.

A lição prática é direta. Arquivos de exclusão funcionam como sinalização, e não como controle de acesso. Por isso, trate o agente local como qualquer software capaz de ler, escrever e executar no ambiente.

Quando o agente age em produção, o code review chega tarde demais

Segurança operacional responde por 23,9% dos relatos. Essa categoria cobre ações sobre recursos de produção, estado do sistema operacional, fluxos de deploy e execução do próprio agente.

Um post citado pelos pesquisadores alega que o Replit removeu um banco de dados de produção de um SaaS. No entanto, outro relata que o Cursor enviou código para o GitHub, mesmo depois de receber instrução contrária.

Assim, a fronteira de governança muda de lugar. A revisão de código acontece antes do merge. Enquanto isso, o agente invoca comandos, altera configurações e conversa com ferramentas conectadas durante a tarefa.

Prompt injection transforma um pull request em ordem executável

O estudo também registra injeção de prompt. Um relato descreve instruções maliciosas embutidas em um pull request do GitHub. Em seguida, essas instruções tentaram direcionar o Amazon Q para ações destrutivas em arquivos e na nuvem.

Os autores classificam o caso como segurança operacional. Ou seja, o risco vem do uso redirecionado de ferramentas, e não de uma sugestão de código ruim.

Portanto, integrações externas ampliam o problema. Os pesquisadores identificaram riscos em servidores MCP e ferramentas conectadas. Inclusive, há relatos de serviços hostis ou mal configurados injetando instruções ocultas através de tool calls.

LLM: Privacidade começa na dúvida sobre o destino do seu código

Os relatos de privacidade seguem outro padrão. Falta de transparência aparece em 45,9% deles. As dúvidas envolvem coleta, retenção, uso em treinamento e acesso de administradores em contas corporativas.

O estudo separa essa incerteza dos eventos concretos. Acesso não autorizado a dados responde por 23,7% dos posts. Um relato descreve o Cursor procurando arquivos .env para obter credenciais de banco. Outro cita o Claude Desktop criando uma conta no Replit com dados pessoais do usuário.

Vazamentos somam 15,5%, com foco em propriedade intelectual e credenciais expostas. Transmissão e coleta não autorizadas ficam em 11,9%. Um relato sobre o VS Code afirma que arquivos de código chegaram a serviços externos com telemetria desativada, segundo análise feita com proxy de interceptação. Outra discussão alega que o Claude Code guardou históricos completos de conversa em texto puro no /.claude.json.

Isolamento de contexto aparece em 8,8% dos casos. O volume é menor, porém o impacto incomoda. Os autores citam mensagens surgindo da sessão de outro usuário e informações de um projeto aparecendo em arquivos de outro.

O que os devs já fazem enquanto o fornecedor não resolve

A pesquisa mapeou 13 abordagens de mitigação em cinco grupos. Gestão de configuração lidera, com 33% dos comentários acionáveis. Os desenvolvedores discutem limitar permissões, checar conformidade organizacional, desativar telemetria, monitorar extensões e reter logs.

Governança de código vem logo atrás, com 31%. A verificação manual aparece em 239 comentários, o que a torna a prática individual mais citada. Controle de versão surge em 232 comentários, quase sempre como mecanismo de recuperação depois de alterações indesejadas.

Sandboxing aparece em 105 dos 1.318 comentários com orientação prática. A recomendação é rodar agentes em máquinas virtuais, containers ou devcontainers. Proteção de arquivos sensíveis e isolamento de memória somam 13%. Medidas de isolamento formam outros 13%, divididos entre sandbox e modelos locais. Um LLM local reduz a transmissão externa, embora não resolva permissões locais nem ações autônomas arriscadas.

O checklist que sua equipe deveria exigir antes de conectar o repositório LLM

Os pesquisadores defendem verificação automática antes que recomendações cheguem ao desenvolvedor. Além disso, pedem logs de execução acessíveis e informação sobre o planejamento das tarefas. Para agentes conectados, propõem um processo de conformidade prévio à liberação de acesso.

Na prática, sua organização pode adotar cinco medidas desde já:

  1. Separe o acesso do IDE de segredos de alto valor e credenciais de produção.
  2. Exija aprovação humana antes de execução de comandos e alterações no repositório.
  3. Mantenha registros de arquivos acessados, contexto enviado para fora e ferramentas invocadas.
  4. Teste regras de exclusão na segunda e na terceira interação, além da primeira.
  5. Avalie o comportamento da aplicação inteira, já que alegações sobre o modelo respondem só metade da pergunta.

O caso reproduzido do .env oferece o teste mais objetivo de todos. Se a exclusão configurada cai depois de duas requisições de depuração, o controle existe apenas no papel. Portanto, comece a avaliação de fornecedores por aí.

Acompanhe nosso perfil no Instagram!

Matérias especiais e reportagens conduzidas internamente pela Redação iMasters. Acompanhe no Twitter @imasters e no Instagram/Threads @portalimasters

Ver perfil