Testar se uma IA responde corretamente é só uma parte do problema. Antes de colocá-la em produção, é preciso descobrir como ela se comporta quando o usuário é malicioso, o documento recuperado está contaminado, a ferramenta retorna conteúdo manipulador ou a própria integração possui permissões excessivas.
Muitos projetos ainda tratam segurança de IA como uma bateria de prompts de jailbreak. Isso ajuda, mas é pouco. Uma aplicação real inclui modelo, RAG, APIs, identidade, storage, ferramentas, secrets, infraestrutura e decisões de negócio. O teste precisa acompanhar o sistema inteiro.
Threat model antes do red team
Sem threat model, red teaming vira criatividade sem direção.
O primeiro passo é entender o que a IA faz. Um chatbot público que responde FAQ tem um risco. Um agente interno que acessa ERP e e-mail tem outro. Um modelo que classifica documentos não deveria ser testado da mesma forma que um agente capaz de executar código.
É preciso mapear ativos, dados sensíveis, tipos de usuário, fontes externas, ferramentas, identidade, caminhos de autorização e impacto possível.
Testar frases conhecidas de jailbreak é fácil. O desafio é avaliar como a aplicação reage a instruções maliciosas escondidas nos canais que ela realmente consome.
Em um sistema RAG, isso significa documentos. Em um agente web, páginas. Em MCP, respostas de ferramentas. Em e-mail, mensagens recebidas.
O teste deve tentar cruzar a fronteira entre conteúdo não confiável e ações privilegiadas.
Notícias Relacionadas
- STF identifica prompt injection em petição e expõe novo risco para sistemas de IA
- Gemini acessa sistemas reais em teste e expõe novo risco dos agentes autônomos de IA
Dados sensíveis exigem teste de exposição
A aplicação consegue revelar documentos de outro usuário? Recupera chunks fora do escopo? Inclui secrets nos logs? Envia conteúdo para uma API externa? Memória entre sessões mistura contextos?
Essas perguntas não são teóricas. Boa parte do risco de IA corporativa está no sistema de dados ao redor do modelo.
Se o agente possui tool calling, o teste deve verificar se a ferramenta valida autorização independentemente do modelo.
Também vale testar parâmetros inesperados, repetição de chamadas, escalonamento de escopo, mudança de identidade e tentativa de executar ação administrativa a partir de contexto não autorizado.
O modelo pode ser manipulado. A API não pode assumir que toda tool call é legítima só porque veio do agente.
Containers, APIs, bibliotecas, storage, secrets e rede seguem sujeitos às mesmas classes de falha conhecidas. Uma aplicação de IA pode ter prompt injection e SSRF ao mesmo tempo. Pode ter um modelo bem controlado e uma API vulnerável a IDOR.
Por isso, segurança de IA não substitui AppSec. Ela adiciona novas superfícies.
O que deveria entrar em um plano de testes
- Prompt injection e jailbreak. Diretos e indiretos, incluindo conteúdo recuperado.
- Exposição de dados. Dados pessoais, documentos, secrets, memória e logs.
- Autorização de ferramentas. Escopos, identidades e limites de cada ação.
- Abuso de recursos. Loops, consumo excessivo, rate limiting e custos.
- Infraestrutura tradicional. APIs, dependências, containers, storage e rede.
- Supply chain. Modelos, datasets, pacotes e serviços externos.
- Adversarial ML. Quando aplicável, evasão, poisoning e ataques à privacidade.
O NIST usa o conceito de Test, Evaluation, Verification and Validation para estruturar avaliação de sistemas de IA. A vantagem é sair do teste pontual e pensar em evidência ao longo do ciclo.
Não basta descobrir um problema. É preciso conseguir reproduzi-lo, corrigir e retestar. Caso contrário, a equipe fica com uma coleção de prompts interessantes e pouca melhoria concreta.
O que significa “passou”? Quantos vazamentos são aceitáveis? Quais ações exigem confirmação? Qual taxa de falso positivo é tolerável? Que classes de risco impedem produção?
Sem critérios claros, segurança vira discussão subjetiva no final do projeto, normalmente quando a pressão por lançamento já é alta.
Nenhum ambiente de homologação reproduz completamente usuários, dados e comportamento reais. Modelos também mudam, assim como fontes de RAG e ferramentas.
Por isso, monitoramento pós-deploy faz parte da segurança. O NIST reforça a necessidade de avaliação contínua de sistemas de IA implantados.
Nem todo cenário adversarial começa com alguém externo. Um usuário legítimo pode tentar acessar dados de outra área, abusar de uma ferramenta para executar tarefa fora do escopo ou explorar o agente para contornar um processo de aprovação.
Esse tipo de teste é importante porque sistemas internos tendem a confiar demais no fato de o usuário já estar autenticado. Autenticação prova quem é a pessoa; não prova que toda ação solicitada por ela está autorizada.
Conclusão
Testar IA com segurança exige abandonar a ideia de que o modelo é o sistema inteiro.
A avaliação precisa cobrir comportamento do modelo, dados, identidade, ferramentas, infraestrutura e impacto. Red teaming é importante, mas funciona melhor quando parte de um threat model e termina em correção verificável.
Quanto mais autonomia a IA recebe, mais o teste precisa se aproximar da consequência real de uma decisão errada.
Veja também
- Segurança em LLMs: guia técnico para avaliar, proteger e mitigar a superfície de ataque
- Agentes de IA podem modificar o próprio modelo sem ordem explícita, mostra pesquisa
Be the first to comment