A maioria dos programas de segurança de IA para no primeiro estágio. Uma equipe roda uma bateria de prompts adversariais, o modelo escapa do guardrail uma vez em cinquenta tentativas, o achado vira um ticket de severidade média e o assunto se encerra. O relatório diz "o modelo é vulnerável a prompt injection". Não diz o que um adversário faria com isso.
Essa é a lacuna que a Promptware Kill Chain existe para fechar. Adaptamos o framework da pesquisa de Schneier et al. (2025) e o transformamos em uma metodologia ofensiva de sete estágios — do acesso inicial ao comprometimento total. A premissa é simples: prompt injection não é o ataque. É a porta de entrada.
Por que a kill chain tradicional não serve
Frameworks clássicos assumem uma fronteira nítida entre código e dados. Um binário executa instruções; um arquivo de configuração fornece parâmetros. A exploração acontece quando o atacante consegue mover dados para o lado do código.
Em um LLM, essa fronteira não existe. O system prompt, o input do usuário, o documento recuperado do vector store e a saída de uma ferramenta chegam ao modelo no mesmo canal — texto. O modelo não tem um mecanismo estrutural para distinguir a instrução legítima do operador da instrução plantada dentro de um PDF que o pipeline RAG acabou de indexar.
O resultado prático: todo dado que entra no contexto é potencialmente executável. Um framework de ataque para sistemas de IA precisa partir dessa realidade, não adaptá-la.
Os sete estágios
1. Acesso inicial
O adversário obtém entrada no sistema de IA. Os vetores que testamos com mais frequência:
- Prompt injection direto — o usuário é o atacante, interagindo diretamente com a interface.
- Prompt injection indireto — a instrução chega via conteúdo que o sistema consome: um e-mail, uma página web, um ticket de suporte, um documento no vector store.
- Envenenamento de dados — manipulação do corpus de fine-tuning ou dos embeddings.
- Plugins e endpoints comprometidos — a integração de terceiros como ponto de entrada.
O vetor indireto é o mais subestimado e o mais explorado em incidentes reais. Ele não exige que o atacante tenha acesso ao sistema — exige apenas que ele consiga colocar texto onde o sistema vai ler.
2. Escalação de privilégios
Dentro do contexto do modelo, o atacante amplia o que pode fazer: contorna guardrails, extrai o system prompt, ou desbloqueia chamadas de ferramenta que deveriam estar restritas ao operador.
Extrair o system prompt costuma ser tratado como achado de baixa severidade. Não é. O system prompt descreve as ferramentas conectadas, os limites de autorização e frequentemente a estrutura dos dados acessíveis. É o mapa da rede — só que em linguagem natural.
3. Reconhecimento
O adversário enumera capacidades: quais ferramentas o agente pode invocar, quais fontes de dados alcança, que outros agentes existem no pipeline, quais credenciais estão no escopo da sessão.
Aqui a assimetria fica evidente. Um agente com acesso a e-mail, calendário e um banco vetorial corporativo responde perguntas sobre a própria configuração com a mesma prestatividade com que responde perguntas sobre o negócio.
4. Persistência
O estágio que separa um teste de escritório de um exercício realista. O atacante grava instruções em um local que sobrevive ao fim da sessão:
- memória de longo prazo do agente;
- documentos no vector store que serão recuperados em conversas futuras;
- arquivos de configuração ou regras de projeto que o assistente lê a cada inicialização.
Nos incidentes que catalogamos entre 2025 e 2026, 57% dos casos mantiveram persistência ativa após a detecção inicial. A organização remediou o sintoma — bloqueou o prompt, ajustou o filtro — e deixou o payload no lugar.
5. Comando e controle
Canais de saída são estabelecidos. Um agente com acesso à web tem um canal C2 embutido: basta codificar dados no path de uma requisição. Um agente com acesso a e-mail tem outro. A memória de conversação de um assistente compartilhado pode servir como dead drop entre operações — foi exatamente o padrão observado no caso ZombAI.
6. Movimento lateral
O agente comprometido alcança outros sistemas. Em arquiteturas multi-agente, um agente confia na saída de outro pelo mesmo motivo que confia no input do usuário: é tudo texto. Uma instrução plantada no agente A é executada pelo agente B como se fosse legítima.
O incidente GeminiJack demonstrou movimento lateral por um ambiente Workspace inteiro, zero-click, sem que o usuário interagisse com nada.
7. Ações sobre o objetivo
Exfiltração de dados, manipulação de sistemas, fraude, ou uso do acesso como ponte para o ambiente tradicional. CVE-2025-53773 (GitHub Copilot) e CurXecute (Cursor IDE) fecham o ciclo de forma inequívoca: sugestão de código malicioso levando a execução arbitrária de comandos na máquina do desenvolvedor. O ataque começa em linguagem natural e termina em shell.
O que os dados mostram
Catalogamos 21 incidentes de promptware entre 2025 e 2026. Dois números importam mais que os outros:
- 15 dos 21 apresentaram quatro ou mais estágios da kill chain. Ataques a sistemas de IA não são one-shot. São campanhas.
- 57% mantiveram persistência após a detecção inicial. O tempo de permanência é longo porque a superfície de detecção — memória, embeddings, contexto — não é monitorada pelos controles existentes.
Se o seu teste de segurança de IA produz uma lista de prompts que quebraram o guardrail, você mediu o estágio 1 e extrapolou o resto.
Como isso muda o teste
Aplicar a kill chain reorganiza o exercício em torno de três perguntas:
- Alcance. Comprometido o modelo, o que ele efetivamente alcança? Não o que a documentação diz — o que as credenciais da sessão permitem.
- Persistência. Existe algum local gravável que o modelo relê? Se sim, é um mecanismo de persistência, independentemente de ter sido projetado como tal.
- Detecção. Os estágios 4 a 6 geram algum sinal observável? Na maioria dos ambientes que avaliamos, a resposta é não — os logs registram a interação, não a intenção.
A saída deixa de ser uma lista de jailbreaks e passa a ser um caminho de ataque com evidência reproduzível em cada estágio, classificação de severidade por impacto ao negócio e uma ordem de correção justificada.
Onde começar
Se você opera sistemas de IA em produção, três controles têm o melhor retorno imediato:
- Reduza a agência. A maior parte da severidade vem do estágio 7, e o estágio 7 é limitado pelo que o agente pode fazer. Permissões de leitura no lugar de escrita eliminam classes inteiras de impacto.
- Trate a memória como superfície de ataque. Se o agente escreve em um armazenamento que relê depois, esse armazenamento precisa de revisão, expiração e log.
- Instrumente o estágio 5. Chamadas de saída iniciadas por agentes — HTTP, e-mail, invocação de ferramenta — devem ser logadas e correlacionáveis ao input que as originou.
Nenhum desses controles depende de o modelo "resistir" a prompt injection. Essa é a intenção: a kill chain assume que o estágio 1 vai funcionar e projeta a defesa para os seis estágios seguintes.
A Promptware Kill Chain é o framework por trás dos nossos exercícios de Red Team para IA e do pentest de LLM. Para discutir a aplicação no seu ambiente, fale com o time.