Teste de segurança para LLM: o que testar e o que a evidência comprova
Testar a segurança de uma aplicação LLM significa verificar se ela preserva seus limites quando entradas, contexto, ferramentas e comportamento do modelo se tornam adversariais.
Um teste útil é uma tentativa controlada e repetível de violar um limite de segurança definido. Ele registra entrada, defesa esperada, comportamento observado e evidência para reprodução. Uma lista de prompts, sozinha, não é um programa de segurança.
Para quem é: Para times de AppSec, engenharia de IA, engenharia de segurança e produto preparando uma aplicação LLM para lançamento.
Teste a aplicação, não apenas o modelo
Uma aplicação LLM combina instruções, recuperação de contexto, ferramentas, identidade, regras de negócio, filtros e observabilidade. Uma recusa segura do modelo-base não comprova que o sistema montado protege dados ou limita ações.
Comece nomeando ativos e fronteiras de confiança: instruções de sistema, documentos recuperados, credenciais, permissões de ferramentas, dados de usuários, consumidores da saída e controles de custo. Depois conecte cada teste a um caminho plausível de abuso.
- Prompt injection direta e indireta
- Exposição de informação sensível
- Uso não autorizado de ferramentas e agência excessiva
- Vazamento de contexto entre usuários ou tenants
- Consumo sem limite e abuso operacional
Um ciclo repetível de teste de segurança
Mantenha o fluxo determinístico ao redor do modelo para que o resultado sustente uma decisão de engenharia.
- 01
Defina o limite
Declare o que o sistema nunca pode revelar, executar, recuperar ou gastar sem autorização.
- 02
Mapeie ataques representativos
Use taxonomias públicas como OWASP e MITRE ATLAS e adapte os casos à arquitetura real.
- 03
Varie o comportamento
Teste paráfrases, codificações, pressão em múltiplos turnos, instruções recuperadas e caminhos mediados por ferramentas.
- 04
Observe a defesa
Registre qual controle bloqueou a ação e diferencie bloqueio seguro de falha de transporte ou resposta inconclusiva.
- 05
Repita após a correção
Congele o caso, execute novamente e preserve evidência de que o caminho foi fechado sem quebrar o uso legítimo.
O que um teste pode ou não concluir
- Mostrar que um caminho específico funcionou ou foi bloqueado nas condições registradas
- Comparar guardrails sob variações controladas
- Produzir evidência reproduzível para remediação e gates
- Revelar controles ausentes entre modelo, aplicação e ferramentas
- Provar segurança contra todo ataque futuro
- Substituir modelagem de ameaças, revisão de código ou testes de autorização
- Transformar uma recusa em prova de proteção sistêmica
- Estimar prevalência real sem dados operacionais
Evidência mínima para um resultado acionável
- 01Ativo e limite de segurança nomeados
- 02Taxonomia e identificador do cenário
- 03Impressão digital sanitizada da entrada e resultado esperado
- 04Resultado separado de erros de infraestrutura
- 05Controle ou sinal de detecção que disparou
- 06Passos de reprodução e estado da repetição pós-correção
Fontes primárias
- OWASP Top 10 for LLM Applications 2025
OWASP GenAI Security Project
Taxonomia pública de riscos para aplicações LLM e GenAI.
- Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile (NIST AI 600-1)
National Institute of Standards and Technology
Orientação para governar, mapear, medir e gerenciar riscos de GenAI.
- MITRE ATLAS — Adversarial Threat Landscape for Artificial-Intelligence Systems
MITRE
Base viva de táticas e técnicas adversariais contra sistemas de IA.