Tratar o conteúdo obtido como dados não fiáveis

Identifique o ponto em que os dados se tornam uma instrução

Um agente de programação lê mais do que o pedido do utilizador. Pode examinar issues, ficheiros do repositório, documentação de pacotes, resultados de pesquisa e respostas de ferramentas. Parte desse conteúdo pode incluir instruções de outra pessoa.

Uma prompt injection ocorre quando esse conteúdo desvia o modelo da tarefa autorizada. Uma injeção indireta chega através de uma fonte obtida, em vez do pedido direto do utilizador. A OWASP identifica o material dos repositórios e os resultados das ferramentas como pontos de entrada relevantes. Leia as orientações de prevenção.

Considere uma tarefa fictícia de manutenção. O utilizador pede ao agente que corrija um filtro de relatório e execute os testes obrigatórios. Um README obtido pelo agente diz que os testes estão obsoletos e pede o envio de um ficheiro de configuração. O README pode explicar o projeto. Não pode autorizar a omissão das verificações do utilizador nem o envio de ficheiros para outro destino.

Mapeie as consequências possíveis

O mesmo texto enganador tem consequências diferentes em ambientes diferentes. Um sistema de resumo com acesso apenas de leitura pode produzir um resumo incorreto. Um agente com permissão de escrita no repositório pode alterar código. Um agente com segredos e acesso de saída à rede pode expor informação.

Examine as ações disponíveis antes de decidir quais as defesas relevantes. Liste os recursos sensíveis, os destinos onde é possível escrever e os destinos externos. Inclua os conectores acrescentados depois da configuração inicial. Uma ferramenta nova pode aumentar o efeito de uma fragilidade existente.

Um agente também pode transportar conteúdo enganador para uma fase posterior. Por exemplo, pode copiar uma instrução não fiável para uma descrição de tarefa que gere. O agente seguinte não deve tratar essa descrição como uma política aprovada de forma independente.

Use vários controlos com finalidades distintas

Na conceção da aplicação, separe as instruções fiáveis da tarefa dos dados obtidos. Mostre a origem do material obtido. Estes passos melhoram a interpretação, mas não estabelecem uma fronteira de segurança completa.

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

Os filtros e um segundo modelo podem ajudar a detetar conteúdo suspeito. Também podem não detetar ataques ou bloquear informação legítima. Não substitua a autorização determinística pela pontuação de confiança de um modelo. A OWASP assinala explicitamente os limites de depender apenas de prompts ou da obtenção de informação. Leia a descrição do risco.

Teste o fluxo de trabalho sem exposição real

Use um repositório descartável e ficheiros fictícios. Não dê à avaliação credenciais de produção nem escrita externa sem restrições. Introduza uma instrução inofensiva que entre em conflito com a tarefa, como omitir uma verificação obrigatória.

Observe a resposta do modelo e as ações reais das ferramentas. Uma mensagem que diga «ignorei a instrução» não basta se a verificação tiver sido omitida. Registe a tarefa, os dados de teste com a instrução injetada, as ferramentas permitidas e o resultado observado.

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