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

1. Inventariação de 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 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. Faltar um canal garante um ponto cego que os atacantes vã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á. Revisite o inventário trimestralmente ou sempre que adicionar plugins.

2. Separação da política de dados não confiáveis

A política do sistema deve residir em modelos controlados pelo servidor que os utilizadores não podem editar. O conteúdo não confiável deve chegar dentro de envelopes claramente rotulados: tags XML, campos JSON ou secções markdown cujos títulos indicam que não são directivas. Nunca interpolados texto do utilizador na string do sistema sem escapar e sem separação estrutural recomendada na folha de dicas do OWASP.

Para RAG, armazenar citações separadamente de frases imperativas quando possível. Os pipelines de recuperação devem remover tags de script e ataques de homóglifos antes de incorporar. Se a sua pilha tiver de incluir pedaços, pré-pender um aviso fixo de que o texto do pedaço é apenas de referência.

3. Minimizar a agência do modelo em ações sensíveis

Cada permissão de ferramenta é um pagamento de injeção. 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. Os agentes que podem tanto navegar em URLs arbitrárias quanto publicar resumos internos precisam de limites mais apertados do que os bots de FAQ.

Aplique o privilégio mínimo aos escopos OAuth que respaldam as ferramentas. Gire os tokens e audite quais personas de agente podem invocar quais endpoints. Uma injeção que apenas alcança um índice de FAQ somente leitura causa menos danos do que uma injeção 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 a Unicode para uma forma canónica antes da tokenização. Bloqueie ou remova caracteres de controlo conhecidos que alguns modelos tratam de forma estranha. A validação pertence ao código da aplicação, não à prosa da prompt esperançosa que diz ao modelo para "ser seguro".

Para uploads, execute um antivírus e uma detecção de tipo; não confie nas extensões. Converta documentos para texto em um sandbox com tempos de espera. Registe falhas de conversão em vez de silenciosamente descartar para cadeias vazias que possam 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 em CI quando prompts, ferramentas ou configurações de recuperação mudam. O conjunto de regras prompt-injection@2026-07-19.2 abrange famílias de frases, personas de jailbreak, ataques de delimitadores e formulações 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; paráfrases novas ainda requerem arquitetura e monitorização. Publicar alterações no corpus em pedidos de pull para que os revisores vejam a intenção.

6. Reforçar a segurança contra jailbreak e caminhos sociais

Os jailbreaks exploram a empatia e a 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 equipas de suporte e PM para não incorporarem linguagem de override nos macros. A educação do utilizador reduz os jailbreaks acidentais mesmo quando não há má-fé.

Alinhe o texto de recusa e escalada com o que o seu backend realmente impõe. Se o modelo se desculpa, mas as ferramentas ainda executam, os utilizadores aprendem que as barreiras de texto são teatro. Faça corresponder as fronteiras narrativas às técnicas.

7. Controlo da injeção indireta na recuperação

Os atacantes envenenam wikis partilhados, secções de comentários ou páginas de SEO que você indexa. Assine documentos que você confia; verifique assinaturas antes de indexar. Reduza a classificação ou exclua páginas geradas por utilizadores de corpora de alta confiança. Monitore alterações lexicais repentinas no conteúdo indexado que possam indicar atividade de campanha.

No momento da resposta, mostre aos utilizadores quais pedaços influenciaram uma resposta para que eles possam detectar citações absurdas. Quando os pedaços contêm frases imperativas, considere um descarte heurístico a menos que seja corroborado por fontes de confiança.

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

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 quantos textos uma única sessão pode exportar para hooks web externos.

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

9. Registo, privacidade e retenção

Registar tentativas de injeção com payloads hash, ids de regra e metadados de canal - não necessariamente segredos completos que os utilizadores colam por engano. Definir retenção alinhada com o interesse legítimo do GDPR ou consentimento, documentar nas notificações de privacidade e suportar pedidos de eliminação. O monitoramento de segurança deve respeitar a minimização de dados.

Fornecer aos engenheiros de serviço de chamada runbooks que distinguem entre acertos de scanner, bloqueios de WAF e recusas de modelo. Tempestades de falsos positivos devem ser ajustáveis sem desativar entirely o registo.

10. Planos de resposta a incidentes

Quando a injeção tem sucesso, congele as versões de agentes afetadas, rode as credenciais que podem ter sido comprometidas e capture os prompts para análise pós-incidente. 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 folha de truques.

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

11. Ângulos multi-tenant e de cadeia de fornecimento

Os produtos SaaS devem isolar os índices de recuperação de inquilinos e as lojas de memória. Os ajustes finos compartilhados ou as caches de prompts do sistema compartilhadas podem cruzar contaminações de instruções. Os plugins de terceiros introduzem riscos de cadeia de fornecimento; verifique os publicadores e fixe as versões.

12. Matriz de testes (ambiente de teste)

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

- Cordas de substituição direta no bate-papo do utilizador. - Instruções indiretas ocultas em rodapés de PDF carregados. - Contrabando de argumentos de ferramenta via campos aninhados JSON. - Persistência de memória de frases hostis em várias voltas. - Cargas codificadas (base64, hex, scripts mistos).

Registe capturas de ecrã para auditores. Anote quais os controlos que bloquearam o impacto versus quais produziram apenas um recusa polida enquanto as ferramentas ainda funcionavam—recusa sem aplicação é uma descoberta.

13. Governança e Propriedade

Assignar um proprietário transversal para o rastreio do. A segurança define limiares; a plataforma implementa barreiras; 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 a "segurança por demonstração". As capturas de ecrã de marketing devem refletir as mesmas restrições de ferramentas que a produção utiliza. Os modos de administração ocultos para vendas invalidam a confiança do cliente se forem descobertos.

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

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

Quando o PromptShield permanece silencioso 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 etiquetas de versão seguindo as convenções de nomenclatura prompt-injection@2026-07-19.2.

15. Manutenção a longo prazo

Subscreva as atualizações do OWASP GenAI e feeds de investigação reputáveis. Faça uma nova pesquisa na internet trimestralmente; datas de mitigação desatualizadas são bugs. Quando atualizar modelos, execute novamente a matriz completa — a fine-tuning do tokenizer e da segurança altera o comportamento.

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

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

16. Barreiras de Acessibilidade e Guardrails de UX

Interfaces de chat amigáveis ao leitor de ecrã 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 pré-pender silenciosamente diretivas do sistema derivadas de histórico não confiável.

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

Tabela de referência rápida

- Âmbito do : injeção direta e indireta contra aplicações e agentes.

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

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

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

Referências

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

Open PromptShield

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