Por que os agentes de IA são vulneráveis a prompt injection e como protegê-los no nível da arquitetura

No software tradicional, arquitetura e segurança são claramente separadas: existe um perímetro, autenticação, validação de entradas. Nos sistemas de IA, essa fronteira se torna tão difusa que as abordagens clássicas deixam de funcionar.

O problema central: os agentes de IA fundem algo que sempre foi separado — o plano de controle (control plane) e o plano de dados (data plane). Em uma aplicação comum, o comando do usuário é processado por código determinístico, e os dados não conseguem reescrever a lógica. Em um sistema LLM, qualquer texto presente na janela de contexto pode potencialmente influenciar o comportamento do modelo.

A OWASP coloca da seguinte forma: "Todas as entradas têm o mesmo peso de confiança, e o modelo não consegue distinguir internamente instruções confiáveis de dados não confiáveis". Trata-se de uma mudança arquitetônica que exige incorporar a segurança ao sistema desde o início, em vez de adicioná-la como um filtro por cima.

Princípio 1:

Separação de confiança como primitiva arquitetônica

Muitos arquitetos colocam conteúdo não confiável, dados internos e instruções do sistema na mesma janela de contexto, assumindo que o modelo vai resolver isso por conta própria. Isso é um erro. A solução é introduzir um nível de confiança explícito para cada fragmento, com separação forçada de camadas.

O sistema não trabalha com strings de prompt concatenadas, mas com blocos de contexto tipados. Cada bloco recebe metadados de origem (provenance) e um nível de confiança: instruções do sistema são trusted, dados do banco interno são internal, e conteúdo externo e documentos RAG são untrusted. As ferramentas verificam esses rótulos antes de executar qualquer ação.

A OWASP chama isso de "segregation of trust" e, em 2026, reforça que isso já não é apenas uma boa prática, mas um requisito arquitetônico.

Princípio 2: Isolamento de ferramentas e privilégio mínimo

Um erro arquitetônico perigoso é dar ao LLM acesso a ferramentas com permissões excessivas. Pode ser uma ferramenta de "leitura" que, na prática, consegue excluir documentos, ou uma conexão com banco de dados com privilégios de administrador quando só é necessário um SELECT. A solução: dar a cada ferramenta o conjunto mínimo necessário de permissões e um contexto de execução isolado.

Em vez de passar consultas SQL diretamente para o modelo, o sistema recebe parâmetros estruturados (tabela, filtros, limite) e constrói ele mesmo a consulta parametrizada. Isso elimina toda uma classe de ataques de injeção. Evite funcionalidades abertas, como execução de comandos de shell ou requisições a URLs arbitrárias. Use ferramentas granulares com restrições: ferramentas de arquivo que escrevem apenas em um diretório específico e com uma extensão determinada, ferramentas de e-mail que enviam apenas para endereços em uma lista de permissões aprovada.

Princípio 3: Controle de memória e do corpus RAG

O corpus RAG faz parte da superfície de ataque, muitas vezes mais perigoso que o próprio prompt. A pesquisa WARP mostrou ser possível injetar documentos "envenenados" em um corpus de busca, de forma que, ao ser acionado o gatilho, o RAG recupere justamente esses documentos. O estudo AgentPoison teve sucesso em 82% dos casos com uma taxa de envenenamento inferior a 0,1% — um único documento malicioso por mil pode ser suficiente.

A defesa envolve três camadas: controle de origem de cada documento, com metadados e hashes de conteúdo; isolamento dos resultados de busca, marcados como untrusted; e monitoramento de desvio (drift) — detectar quando a busca começa a retornar documentos que antes nunca retornava.

Princípio 4: Human-in-the-loop como componente arquitetônico

Isso não é um recurso de interface com um botão de confirmação, mas um componente embutido no runtime. As ações são classificadas por nível de risco: LOW (somente leitura, dados internos), MEDIUM (escrita em sandbox, notificações internas), HIGH (exclusão, chamadas a APIs externas, operações financeiras). Ações de risco HIGH exigem confirmação, e o agente não pode contorná-la.

Incidentes reais confirmam essa necessidade: CVE-2025-32711 (EchoLeak) — uma prompt injection no Microsoft Copilot com exfiltração de dados zero-click; e CVE-2025-54135 e CVE-2025-54136 — execução remota de código via prompt injection na implementação MCP do Cursor IDE. Todos eles resultaram de erros arquitetônicos, não de falhas do modelo.

Isso não é uma história sobre tornar o modelo seguro. É sobre projetar a segurança no nível da arquitetura do sistema.