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 com modelo de linguagem (LLM) combina instruções, busca de documentos, ferramentas, identidade, regras de negócio, filtros e registros de execução. Uma recusa segura do modelo isolado não comprova que a aplicação completa protege dados ou limita ações.
Comece nomeando o que precisa ser protegido e onde a confiança muda: instruções de sistema, documentos buscados, credenciais, permissões de ferramentas, dados de usuários, sistemas que recebem a resposta e controles de custo. Depois conecte cada teste a uma forma plausível de abuso.
- Instruções maliciosas enviadas diretamente ou escondidas em documentos (prompt injection)
- Exposição de informação sensível
- Ações executadas sem autorização suficiente
- Vazamento de contexto entre usuários ou organizações
- Consumo sem limite e abuso operacional
Um ciclo repetível de teste de segurança
Mantenha iguais as etapas ao redor do modelo para que o resultado possa sustentar 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.
Exemplo resolvido: teste um limite de permissão
Considere um assistente de agenda que pode ler os compromissos da pessoa conectada, mas nunca a agenda privada de um colega. Primeiro, confirme que a pessoa consegue ler um compromisso próprio. Depois, faça uma requisição de teste entre usuários, sem nomes nem compromissos reais, e registre a resposta da aplicação, a chamada de ferramenta, a decisão de autorização e o evento de auditoria.
Se a autorização impedir a chamada da ferramenta, o caminho foi bloqueado por um controle. Se o serviço de agenda estiver indisponível, o resultado é inconclusivo — não seguro. O exemplo mostra por que o veredito precisa descrever tanto o efeito observado quanto o controle que o produziu.
O que um teste pode ou não concluir
- Mostrar que um caminho específico funcionou ou foi bloqueado nas condições registradas
- Comparar as proteções sob variações controladas
- Produzir evidência reproduzível para correção e critérios de liberação
- 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 do sistema inteiro
- Estimar frequência real sem dados operacionais
Evidência mínima para um resultado útil
- 01Dado ou ação protegida e limite de segurança nomeados
- 02Categoria e identificador do cenário
- 03Identificador seguro da entrada e resultado esperado
- 04Resultado separado de erros de infraestrutura
- 05Controle ou sinal de detecção que foi acionado
- 06Passos de reprodução e estado da repetição após a correção
Precisa aplicar isso à sua aplicação com LLM?
Defina o escopo de uma avaliação autorizada com remediação revisada por uma pessoa, um reteste validado por reexecução controlada e um pacote de evidências com integridade verificada por SHA-256.
Solicitar avaliação com escopoFontes 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.