Lista de verificação de endurecimento contra injeção de prompts para equipes de LLM e agentes

1. Inventarie todos os canais de instruções

Antes de endurecer, mapeie onde as strings se tornam instruções. Canais típicos incluem prompts de sistema carregados no lado do servidor, mensagens de desenvolvedor em APIs de chat, chunks de documentos recuperados, payloads de retorno de ferramentas, corpos de webhooks, encaminhamentos de e-mail e campos de metadados que os usuários nunca veem, mas os modelos ainda leem. Deixar de mapear um canal garante um ponto cego que os atacantes irão explorar.

Documente cada canal com proprietário, classificação de dados e se o conteúdo é controlado pelo usuário final. Marque canais que possam conter HTML, markdown, código ou JSON serializado separadamente - truques de codificação se concentram lá.

2. Separe a política dos dados não confiáveis

A política do sistema deve residir em modelos controlados pelo servidor que os usuários não podem editar. O conteúdo não confiável deve chegar dentro de envelopes claramente rotulados: tags XML, campos JSON ou seções markdown cujos títulos afirmam que não são diretivas.

Para RAG, armazene citações separadamente de sentenças imperativas quando possível. Pipelines de recuperação devem remover tags de script e ataques de homóglifos antes de incorporar. Se sua pilha precisar incorporar chunks, pré-fixe um aviso fixo de que o texto do chunk é apenas para referência.

3. Minimizar a atuação do modelo em ações sensíveis

Cada permissão de ferramenta é uma injeção de payoff. Liste as ferramentas que leem segredos, enviam e-mails, movem dinheiro ou alteram configurações de produção. Exija confirmação humana, autenticação de escalonamento ou caminhos de código determinísticos para essas ações. Agentes que podem tanto navegar em URLs arbitrárias quanto postar resumos internos precisam de limites mais apertados do que bots de FAQ.

Aplique o privilégio mínimo aos escopos OAuth que respaldam as ferramentas. Gire os tokens e audite quais personas de agentes podem invocar quais endpoints. Uma injeção que alcança apenas um índice de FAQ somente leitura causa menos danos do que uma anexada a uma API de implantação.

4. Valide e normalize os dados de entrada no início

Defina comprimentos máximos por campo, rejeite cargas binárias inesperadas e normalize Unicode para uma forma canônica antes da tokenização. Bloqueie ou remova caracteres de controle conhecidos que alguns modelos tratam de forma estranha. A validação pertence ao código da aplicação, não à prosa da solicitação esperançosa que diz ao modelo para "ser seguro".

Para uploads, execute antivírus e detecção de tipo; não confie nas extensões. Converta documentos para texto em um sandbox com timeouts. Registre falhas de conversão em vez de silenciosamente descartar para strings vazias que podem mais tarde ser substituídas por conteúdo de atacante na repetição.

5. Executar regressão de injeção determinística

Manter um corpus de amostras maliciosas e benignas. Executar PromptShield ou motores de regras equivalentes no CI quando prompts, ferramentas ou configurações de recuperação mudam. O conjunto de regras prompt-injection@2026-07-19.2 cobre famílias de frases, personas de jailbreak, ataques de delimitador e wordings de exfiltração comuns - estenda-o com incidentes internos.

Tratar a regressão como testes unitários: falhar em uma amostra de ataque conhecida é um bloqueador de mesclagem. Passar em todas as amostras é necessário, mas não suficiente; paraphrases novas ainda requerem arquitetura e monitoramento. Publicar alterações no corpus em pull requests para que os revisores vejam a intenção.

6. Fortaleça quebras de jailbreak e caminhos sociais

As quebras de jailbreak exploram empatia e autoridade: emergências falsas, apelos para ajudar uma criança, alegações de status de funcionário da OpenAI ou cenários de role-play que pedem ao modelo para ignorar as políticas de ética. Treine as equipes de suporte e PM para não incorporar linguagem de override em macros. A educação do usuário reduz as quebras de jailbreak acidentais, mesmo quando não há malícia.

Alinhe o recuso e a cópia de escalonamento com o que o seu backend realmente executa. Se o modelo se desculpa, mas as ferramentas ainda executam, os usuários aprendem que as barreiras de texto são teatro. Faça com que as fronteiras narrativas correspondam às técnicas.

7. Controle a injeção indireta na recuperação

Atacantes envenenam wikis compartilhados, seções de comentários ou páginas de SEO que você crawla. Assine documentos em que confia; verifique assinaturas antes de indexar. Reduza a classificação ou exclua páginas geradas por usuários de corpora de alta confiabilidade. Monitore mudanças lexicais repentinas no conteúdo indexado que possam indicar atividade de campanha.

No momento da resposta, mostre aos usuários quais pedaços influenciaram uma resposta para que eles possam identificar citações absurdas. Quando os pedaços contêm sentenças imperativas, considere o down-weighting heurístico, a menos que corrobore com fontes confiáveis.

8. Manipulação de saída e resistência à extração

Mesmo os filtros de entrada perfeitos falham às vezes. Aplicar políticas de saída: bloquear regexes de chaves de API, nomes de host internos e padrões de PII em massa antes que as respostas alcancem os clientes. Para agentes, limpar as saídas das ferramentas antes de reentrar no loop de contexto do modelo. Limitar a taxa de quanto texto uma única sessão pode exportar para webhooks externos.

Desabilitar a renderização de HTML bruto em chats visíveis para o usuário quando não for necessário. Links do Markdown podem fazer chamadas de volta; use domínios da lista de permissões ou remover links nos modos de empresa.

9. Registro, privacidade e retenção

Realizar registros de tentativas de injeção com payloads hash, ids de regra e metadados de canal - não necessariamente segredos completos que os usuários colam por engano. Definir retenção alinhada com o interesse legítimo do GDPR ou consentimento, documentar em avisos de privacidade e suportar solicitações de exclusão. O monitoramento de segurança deve respeitar a minimização de dados.

Fornecer aos engenheiros de plantão manuais de operação que distinguem entre acertos de scanner, bloqueios de WAF e recusas de modelo. Tempestades de falsos positivos devem ser ajustáveis sem desabilitar entirely o registro.

10. Planos de resposta a incidentes

Quando a injeção é bem-sucedida, congele as versões de agentes afetadas, rotate as credenciais que podem ter vazado e capture os prompts para análise pós-mortem. Notifique os clientes se seus dados ou inquilinos foram afetados de acordo com as orientações do seu consultor jurídico. Atualize o corpus com a variante de payload bem-sucedida e adicione mapeamentos de cheat-sheet.

Pratique exercícios de mesa duas vezes por ano. Inclua jurídico, PR e sucesso do cliente - não apenas engenheiros.

11. Ângulos de multi-inquilino e cadeia de suprimentos

Produtos SaaS devem isolar índices de recuperação de inquilinos e lojas de memória. Ajustes finos compartilhados ou caches de prompts do sistema compartilhados podem contaminar as instruções. Plug-ins de terceiros introduzem riscos de cadeia de suprimentos; verifique os publicadores e fixe as versões.

12. Matriz de testes (ambiente de staging)

Para cada candidato à release, percorra esta matriz manualmente, mesmo que a automação passe:

- Strings de substituição direta no chat do usuário. - Instruções indiretas ocultas em rodapés de PDFs carregados. - Contrabando de argumentos de ferramenta via campos aninhados em JSON. - Persistência de memória de frases hostis em várias voltas. - Cargas codificadas (base64, hex, scripts mistos). - Pessoas que quebram a jailbreak e atualizações de política falsas.

Registre capturas de tela para auditores. Anote quais controles bloquearam o impacto versus quais produziram apenas uma recusa polida, enquanto as ferramentas ainda foram executadas — a recusa sem aplicação é uma descoberta.

13. Governança e propriedade

Atribuir um proprietário multifuncional para o rastreamento do. A segurança define limites; a plataforma implementa portais; o produto aceita o risco residual documentado nas notas de lançamento. Os executivos recebem métricas trimestrais: tamanho do corpus, itens de endurecimento abertos, incidentes, tempo médio para corrigir padrões.

Evitar "segurança por demonstração". As capturas de tela de marketing devem refletir as mesmas restrições de ferramentas usadas na produção. Modos de administrador ocultos para vendas invalidam a confiança do cliente se descobertos.

14. Usando saídas do PromptShield em revisões

Exporte resultados de varredura como artefatos de discussão anexados a tickets de lançamento. Cada linha sinalizada deve vincular-se a um item de lista de verificação acima e a um engenheiro nomeado. Feche itens com evidências: pull request, diff de configuração ou screenshot de monitoramento - não garantia verbal.

Quando o PromptShield permanece em silêncio sobre uma amostra preocupante, trate isso como uma lacuna no conjunto de regras a ser avaliada - não como prova de segurança. Proponha novas regras determinísticas com tags de versão seguindo as convenções de nomenclatura prompt-injection@2026-07-19.2.

15. Manutenção de longo prazo

Assine atualizações do OWASP GenAI e feeds de pesquisa confiáveis. Pesquise novamente na web trimestralmente; datas de mitigação desatualizadas são bugs. Ao atualizar modelos, execute novamente a matriz completa — a fine-tuning do tokenizador e da segurança altera o comportamento.

Orçamente tempo de engenheiro para higiene de catálogo. Atacantes iteram; sua lista de verificação deve iterar mais rápido que os ciclos de marketing, mas honestamente, sem prometer perfeição.

Acompanhe o desvio de regra da mesma forma que acompanha CVEs de dependência: cada nova versão do modelo ou conector de ferramenta ganha uma curta passagem de regressão contra as últimas três semanas de tickets reais, não apenas corpora sintéticos. Prefira pacotes de regra pequenos e versionados em vez de um filtro monolítico que ninguém ousa tocar. Quando uma regra dispara com frequência excessiva em produção, rebaixe-a para warn-only com um ticket — não exclua silenciosamente a cobertura durante um fim de semana de plantão.

16. Barreiras de acessibilidade e guardrails de UX

Interfaces de chat amigáveis ao leitor de tela ainda expõem instruções ocultas em rótulos ARIA e texto de espaço reservado que os atacantes podem manipular. Revise esses campos no seu modelo de ameaça. Sugestões de autocompletar não devem preencher silenciosamente diretivas do sistema derivadas de histórico não confiável.

Clientes móveis que armazenam rascunhos offline podem reproduzir strings hostis desatualizadas quando a conectividade for restaurada; limpe rascunhos arriscados após atualizações de política. Equipes de UX devem coordenar com a segurança antes de enviar "divertidos" prompts de Páscoa que se assemelham a modelos de jailbreak.

Tabela de referência rápida

- Escopo do : injeção direta e indireta contra aplicativos e agentes.

- Papel do PromptShield: padrão determinístico + regressão de jailbreak em amostras.

- Tag de conjunto de regras: prompt-injection@2026-07-19.2.

- Resultado: tarefas de endurecimento priorizadas — não uma nota de passar/falhar de pentest.

Referências

- OWASP :2025 — Injeção de Prompt - Folha de Prevenção de Injeção de Prompt OWASP LLM

PromptShield Aberto

Atualizado 2026-09-26 · checklist para suporte à decisão · sem garantia de cobertura completa