Prompt injection não é novidade, o termo circula desde os primeiros experimentos com LLM em produção. O que mudou é o tamanho do estrago. Enquanto o modelo só respondia texto, uma instrução escondida num prompt malicioso no máximo produzia uma resposta constrangedora. Agora que agentes de IA leem e-mail, abrem arquivo, chamam API e executam comando em nome de um usuário, a mesma instrução escondida vira ação real: comando executado, dado exfiltrado, configuração alterada sem que ninguém aprovasse conscientemente.
O que é prompt injection, na prática
É a técnica de inserir instrução dentro de conteúdo que o modelo vai processar, de forma que o modelo trate aquela instrução como comando legítimo do operador. Existem duas variantes principais. Na injection direta, o próprio usuário escreve o prompt malicioso, geralmente pra contornar filtro de segurança do modelo (jailbreak). Na injection indireta, que é a que preocupa em ambiente agentic, o atacante planta a instrução num conteúdo que o agente vai ler depois, sem interação direta com ele: um comentário de issue, uma página web, um arquivo, o corpo de um e-mail. O modelo não distingue de forma confiável 'isto é dado que devo processar' de 'isto é instrução que devo seguir', porque os dois chegam pelo mesmo canal: texto.
Da conversa até execução de comando: o caso do GitHub Copilot
O exemplo mais concreto de 2025 é a CVE-2025-53773, publicada em 12 de agosto e classificada como injeção de comando (CWE-77) no GitHub Copilot e no Visual Studio. A National Vulnerability Database e o GitHub Security Advisory (GHSA-3m2x-p87c-pwv6) confirmam CVSS 3.1 de 7,8 (AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H), afetando o Visual Studio 2022 nas versões 17.14.0 a 17.14.11, corrigida na 17.14.12. Vale registrar: várias publicações no assunto repetiram um CVSS de 9,6, número que não bate com o que consta nas fontes oficiais, exatamente o tipo de erro que evitamos aqui.
O mecanismo é o que interessa. Conteúdo malicioso plantado em algo que o Copilot processa, como um arquivo do projeto ou uma descrição de issue, instrui o agente a editar o arquivo de configuração `.vscode/settings.json` e ligar a opção `chat.tools.autoApprove`. Com essa flag ativa, o Copilot passa a executar ferramenta e comando sem pedir confirmação explícita do usuário, o chamado modo YOLO. A partir daí, o próximo comando que o agente decidir rodar (por instrução do próprio conteúdo malicioso) executa localmente sem barreira nenhuma. Prompt injection deixa de ser sobre enganar o modelo e passa a ser sobre desligar o único controle que restava: a confirmação humana.
Não é caso isolado nem exclusivo de um fornecedor
Em março de 2026, a CVE-2026-2256 documentou falha equivalente no MS-Agent, framework de agente da ModelScope: entrada derivada de prompt não sanitizada permite execução de comando de sistema operacional arbitrário, CVSS 3.1 de 6,5 (AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N), afetando a versão v1.6.0rc1 e anteriores, também classificada como CWE-77. Dois fornecedores diferentes, duas arquiteturas de agente diferentes, a mesma raiz do problema: comando derivado de conteúdo que deveria ser tratado como dado, executado sem sanitização suficiente. Não é coincidência que prompt injection ocupe a primeira posição da OWASP Top 10 para aplicações LLM desde que a lista existe.
Por que é difícil de resolver de vez
A dificuldade é estrutural, não é falta de patch. Um LLM recebe instrução do sistema, contexto de conversa e conteúdo externo pelo mesmo canal de texto, sem separação criptográfica ou estrutural confiável entre 'isto é comando' e 'isto é dado a processar'. Filtro de palavra e classificador de intenção ajudam, mas são heurística, não garantia, e cada geração de defesa produz uma geração nova de técnica de ofuscação pra contornar. O que realmente muda o risco não é tornar o modelo perfeito, é limitar o que uma instrução injetada consegue fazer mesmo quando passa despercebida.
Defesa em camadas: o que reduz o risco de verdade
- Tratar todo conteúdo externo (página web, PR, e-mail, arquivo, resposta de API de terceiro) como dado não confiável, nunca como instrução, inclusive dentro do próprio prompt de sistema do agente
- Rodar ferramenta do agente em sandbox isolada, sem acesso direto a shell do host, sistema de arquivo sensível ou rede irrestrita
- Exigir confirmação humana explícita pra ação de alto risco (execução de comando, envio de dado pra fora, alteração de configuração), com aprovação automática desligada por padrão
- Aplicar privilégio mínimo nas credenciais e escopos concedidos ao agente, nunca reaproveitar token de uso amplo
- Registrar e monitorar toda ação tomada pelo agente, com alerta pra padrão de uso fora do esperado
- Incluir o agente e suas integrações no escopo de pentest, testando prompt injection como se testa qualquer outra superfície de entrada não confiável
O que isso muda pra quem está avaliando contratar um pentest
Agente de IA com acesso a ferramenta, arquivo ou API deixou de ser experimento de time de produto e virou superfície de ataque com o mesmo peso que uma API ou uma rede interna. Se a empresa já colocou um copiloto de código, um agente de atendimento ou uma automação orientada a LLM em produção, essa integração precisa entrar no escopo do próximo teste de segurança, não como item extra, como item padrão.