Injeção de prompt: a vulnerabilidade que ninguém corrige na raiz
Ataques de prompt injection cresceram 340% em um ano e já causaram vazamento de 150GB de dados governamentais. Por que isso não é um bug comum — e o que fazer a respeito.
Passei duas décadas construindo busca enterprise. Nesse tempo, aprendi uma lição que a indústria de agentes está reaprendendo agora, do jeito difícil: todo sistema que processa texto de fontes não confiáveis e depois age no mundo real é, por definição, uma superfície de ataque. Busca lê documentos e devolve resultados. Agente lê documentos, e-mails, páginas web — e executa ações. A diferença entre os dois é exatamente o tamanho do problema que estamos vivendo.
Prompt injection não é um bug que se corrige com um patch. É uma consequência estrutural de como LLMs funcionam: instrução e dado trafegam no mesmo canal, o texto. Um agente que lê um PDF malicioso, um e-mail envenenado ou uma página web comprometida pode receber comandos escondidos ali dentro e obedecer como se viessem do usuário. Não é teoria. Os números de 2026 mostram a escala real.
O que os números de 2026 mostram
Os ataques de prompt injection cresceram +340% ano a ano, segundo o OWASP em 2026. Não é ruído estatístico — é o reflexo direto de quantos agentes autônomos passaram a operar em produção, com acesso a ferramentas, e-mails, sistemas internos e credenciais.
O levantamento de incidentes reais é ainda mais concreto: 520 casos de tool-misuse e 450 de prompt injection registrados em 2026. Dentro dessa lista está um caso que deveria estar em todo comitê de risco: o roubo de 150GB de dados do governo mexicano, resultado direto de um agente manipulado por injeção de prompt. Não foi uma falha de senha fraca. Foi um agente fazendo exatamente o que um atacante pediu, através de um canal que ninguém estava vigiando.
A infraestrutura embaixo do agente também é vulnerável
Enquanto a camada de aplicação sofre com prompt injection, a camada de infraestrutura tem seus próprios boletins de guerra. Duas vulnerabilidades críticas relacionadas a agentes e ao Model Context Protocol (MCP) chegaram ao topo da escala CVSS em 2026: a CVE-2026-25592, com CVSS 10.0, e a CVE-2025-6514, com CVSS 9.6, esta última permitindo execução remota de código através de servidores MCP comprometidos.
CVSS 10.0 é o teto da escala. Não existe “mais crítico” que isso. Quando duas falhas desse calibre aparecem no mesmo ano, na mesma categoria de tecnologia — infraestrutura de agentes — a mensagem é clara: a corrida para colocar agentes em produção está deixando a segurança para depois. E “depois” está custando 150GB de dados de um governo inteiro.
Por que isso não se resolve com mais um firewall
O erro comum é tratar prompt injection como mais um item de checklist de segurança perimetral. Não é. É um problema de arquitetura do agente: quem pode instruir, o que o agente tem permissão de fazer sem confirmação humana, como se separa dado de comando, e o que acontece quando uma ferramenta MCP de terceiros é comprometida. Isso se resenha antes do agente ir para produção, não depois do incidente.
Na Arvor, cada agente que construímos — para clientes ou para os nossos próprios produtos, como o AMIGO — nasce com essa pergunta na mesa: o que esse agente faz se o texto que ele está lendo for hostil? Segurança não é uma camada que se adiciona no fim. É um requisito de design, do mesmo jeito que era em busca enterprise quando um índice mal configurado expunha dados de clientes inteiros.
Se sua empresa está colocando agentes para produzir, ler e-mail, acessar sistemas internos ou tomar decisões — e ainda não fez essa pergunta — vale conversar. É exatamente esse tipo de arquitetura que desenhamos na consultoria da Arvor. E se o problema é organizar conhecimento disperso com governança e proveniência, em vez de um agente solto sem controle, o caminho é o BRAIN MAKER.
A pergunta certa não é se seu agente vai encontrar um prompt malicioso. É o que ele faz quando encontrar. Fale com a gente.