Trate conteúdo recuperado como entrada não confiável

Identifique onde os dados passam a ser tratados como instrução

Um agente de programação lê mais que o pedido do usuário. Pode inspecionar issues, arquivos do repositório, documentação de pacotes, resultados de busca e respostas de ferramentas. Parte desse conteúdo pode conter instruções de outra pessoa.

Prompt injection ocorre quando esse conteúdo desvia o modelo da tarefa autorizada. Uma injeção indireta chega por uma fonte recuperada, em vez de pelo pedido direto do usuário. A OWASP descreve material do repositório e resultados de ferramentas como pontos de entrada relevantes. Leia as orientações de prevenção.

Considere uma tarefa fictícia de manutenção. O usuário pede ao agente que corrija um filtro de relatórios e execute os testes exigidos. Um README recuperado diz que os testes estão obsoletos e pede ao agente que envie um arquivo de configuração. O README pode explicar o projeto. Não pode autorizar que o agente pule as verificações do usuário ou envie arquivos para outro destino.

Mapeie as consequências possíveis

O mesmo texto enganoso tem consequências diferentes em ambientes diferentes. Um resumidor somente de leitura pode produzir um resumo incorreto. Um agente com acesso de escrita ao repositório pode alterar código. Um agente com segredos e acesso de saída à rede pode expor informações.

Inspecione as ações disponíveis antes de decidir quais defesas importam. Liste os recursos sensíveis, os destinos de escrita e os destinos externos. Inclua conectores adicionados após a configuração inicial. Uma nova ferramenta pode ampliar o efeito de uma fraqueza existente.

Um agente também pode levar conteúdo enganoso a uma etapa posterior. Por exemplo, pode copiar uma instrução não confiável para uma descrição de tarefa gerada. O próximo agente não deve tratar essa descrição como uma política aprovada de forma independente.

Use vários controles com objetivos distintos

No projeto da aplicação, separe instruções confiáveis da tarefa dos dados recuperados. Mostre a origem do material recuperado. Essas medidas melhoram a interpretação, mas não estabelecem um limite completo de segurança.

Imponha permissões de recursos no sistema de execução. Restrinja os destinos de dados sensíveis. Exija a decisão adequada antes de ações com consequências relevantes. Valide a operação proposta em relação à tarefa e ao destino autorizados.

Filtros e um segundo modelo podem ajudar a detectar conteúdo suspeito. Também podem deixar ataques passar ou bloquear informações legítimas. Não substitua autorização determinística por uma pontuação de confiança do modelo. A OWASP destaca os limites de depender apenas de prompts ou recuperação de informações. Leia a descrição do risco.

Teste o fluxo sem exposição real

Use um repositório descartável e arquivos fictícios. Não dê à avaliação credenciais de produção nem permissões irrestritas de escrita externa. Introduza uma instrução inofensiva que contrarie a tarefa, como pular uma verificação obrigatória.

Observe tanto a resposta do modelo quanto as ações reais das ferramentas. Uma mensagem dizendo “ignorei a instrução” é insuficiente se a verificação ainda assim foi pulada. Registre a tarefa, a fixture injetada, as ferramentas permitidas e o resultado observado.

Repita casos representativos após mudanças em prompts, modelos, conectores ou permissões. Um exemplo bloqueado é evidência para aquele caso, não prova contra toda injeção. Se um teste falhar, reduza as consequências possíveis enquanto corrige o fluxo de trabalho subjacente.