💬 NLP

Agentic Security: A Systematization of Tools, Failure Modes, and Design Laws for LLM-Driven Penetration Testing

Este artigo sistematiza as falhas operacionais de ferramentas de teste de penetração impulsionadas por LLM por meio de uma avaliação prática, derivando leis de design quantitativas e um índice de fricção quadridimensional para orientar a construção de sistemas de segurança agentes robustos, exemplificados pela plataforma Inspectra.

Autores originais: Israt Moyeen Noumi, Tarannum Ahmed Nowshin, Md. Mehedi Hasan Nipu, Mohammad Sakib Mahmood, Md. Jakir Hossain, M. F. Mridha

Publicado 2026-08-25

📖 7 min de leitura🧠 Leitura aprofundada

CC BY 4.0

Autores originais: Israt Moyeen Noumi, Tarannum Ahmed Nowshin, Md. Mehedi Hasan Nipu, Mohammad Sakib Mahmood, Md. Jakir Hossain, M. F. Mridha

Artigo original sob licença CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta é uma explicação gerada por IA do artigo abaixo. Não foi escrita nem endossada pelos autores. Para precisão técnica, consulte o artigo original. Ler aviso legal completo

No mundo da segurança computacional, existe uma tradição de longa data de contratar humanos qualificados para invadir sistemas antes que os vilões o façam. Esses especialistas, conhecidos como testadores de penetração, passam seus dias caçando falhas ocultas em softwares, redes e infraestruturas de nuvem. Eles procuram senhas fracas, brechas não corrigidas e erros de lógica que poderiam permitir que um criminoso roubasse dados ou assumisse o controle. Por décadas, esse trabalho foi um ofício manual, impulsionado por humanos. No entanto, uma nova força entrou no campo: a inteligência artificial. Especificamente, modelos de linguagem de grande escala — sistemas treinados em vastas quantidades de texto que podem compreender e gerar linguagem humana — estão agora sendo solicitados a realizar o trabalho desses especialistas em segurança. A ideia é construir sistemas "agênticos": softwares que podem não apenas ler código e escanear redes, mas também planejar ataques, executá-los e escrever relatórios, tudo isso sem que um humano os conduza pela mão. Essa mudança promete tornar os testes de segurança mais rápidos e baratos, mas também introduz um novo conjunto de problemas. Quando você entrega um trabalho complexo e perigoso a uma máquina que pensa em probabilidades em vez de certezas, a máquina pode cometer erros que um humano jamais cometeria ou, pior, pode mentir com confiança sobre o que encontrou.

Uma equipe de pesquisadores partiu para entender exatamente como esses agentes de segurança de IA se comportam quando são deixados para trabalhar sozinhos. Eles não construíram apenas um modelo teórico; eles construíram uma plataforma real e funcional chamada Inspectra e a colocaram à prova contra uma variedade de ferramentas de segurança. O objetivo deles era ir além do entusiasmo sobre o que esses agentes poderiam fazer e documentar as duras realidades de engenharia do que eles realmente fazem quando as coisas dão errado. O que descobriram foi uma disciplina em sua infância, onde os mesmos fracassos aconteciam repetidamente, não porque a tecnologia estivesse quebrada, mas porque estava sendo usada de maneiras para as quais seus designers nunca pretendiam. Os pesquisadores descobriram que os maiores obstáculos não eram a falta de inteligência da IA, mas sim a falta de estrutura na forma como o sistema era construído. Eles identificaram padrões de falha específicos e previsíveis que ocorrem quando uma IA tenta lembrar demais, quando tenta julgar seu próprio trabalho e quando recebe um orçamento que não consegue controlar.

Um dos problemas mais imediatos que a equipe encontrou foi a questão da memória. Imagine um agente de IA que inicia uma investigação longa, lendo milhares de linhas de código e executando dezenas de testes. À medida que a investigação continua, a quantidade de informação que o sistema precisa manter em sua "mente" cresce. Eventualmente, o sistema fica sem espaço para guardar toda essa informação. Em termos humanos, isso é como tentar lembrar cada detalhe de uma conversa longa enquanto a pessoa continua falando; os detalhes mais antigos simplesmente desaparecem. Os pesquisadores descobriram que, quando um agente de IA trabalha em uma sessão única e contínua, ele inevitavelmente esquece as evidências coletadas no início da varredura. Quando chega ao fim para escrever seu relatório, ele pode descrever confiantemente arquivos que nunca sequer abriu ou alegar ter encontrado vulnerabilidades que foram registradas horas antes, mas que foram apagadas de sua memória. A solução proposta por eles foi dividir o trabalho em fases curtas e distintas. Em vez de uma única conversa longa, o sistema utiliza uma série de agentes de vida curta. Cada agente realiza uma pequena parte do trabalho, escreve suas descobertas em um arquivo permanente e organizado e então para. O próximo agente lê apenas um breve resumo desse arquivo, não os dados brutos. Essa abordagem permite que o sistema lide com tarefas muito maiores sem perder o fio da meada, estendendo efetivamente o horizonte do que a IA pode lembrar ao comprimir a informação que ela precisa carregar adiante.

Outro modo de falha crítico envolveu como o sistema julgava seu próprio sucesso. Quando uma ferramenta de red-teaming de IA tenta quebrar um sistema, ela precisa de uma maneira de decidir se um ataque realmente funcionou. Os pesquisadores descobriram que muitas ferramentas automatizadas eram ansiosas demais para dizer "sim, isso funcionou" ao verem certas palavras-chave, mesmo quando o ataque havia falhado. Isso levou a uma enxurrada de alarmes falsos. Para corrigir isso, a equipe projetou um processo de verificação de duas etapas. Primeiro, uma verificação rápida e barata filtraria falhas óbvias. Em seguida, um segundo juiz, mais cuidadoso, revisaria apenas os casos que passaram pela primeira verificação. Crucialmente, esse segundo juiz precisava ser um tipo de sistema diferente do primeiro; se ambos os juízes fossem do mesmo tipo de IA, eles cometeriam os mesmos erros e a segunda verificação seria inútil. Ao usar dois sistemas diferentes para verificar os resultados, a equipe conseguiu reduzir drasticamente o número de alarmes falsos, tornando o relatório final muito mais confiável. Eles também descobriram um viés sutil, mas perigoso: se um ataque falhasse de uma forma que o sistema não conseguisse compreender, o software frequentemente o registrava como um sucesso. Isso significava que os ataques mais perigosos e elusivos eram justamente os mais propensos a serem ocultados ou rotulados incorretamente, gerando uma falsa sensação de segurança.

Os pesquisadores também enfrentaram o problema de custo e controle. Ferramentas de segurança podem ser imprevisíveis; algumas rodam por segundos, enquanto outras podem ficar travadas e rodar por horas, consumindo enormes quantidades de dinheiro e poder computacional. A equipe mostrou que simplesmente dizer a uma IA "não gaste muito tempo" em uma instrução de texto não é suficiente. A IA pode ignorar a instrução ou pode se distrair com o conteúdo que está lendo e esquecer a regra. Em vez disso, o sistema precisa de um guardião externo rígido — um pedaço de código que reside fora do processo de tomada de decisão da IA. Esse guardião impõe limites estritos sobre quanto tempo uma ferramenta pode rodar e quanto pode gastar, interrompendo-a no momento em que ela atinge o limite. Isso garante que a IA não possa acidentalmente falir um projeto ou escanear um servidor que não está autorizada a tocar. Os pesquisadores enfatizaram que a IA nunca deve ser a autoridade final sobre sua própria segurança ou orçamento; esse papel deve sempre pertencer a uma camada de código separada e imutável.

Finalmente, a equipe analisou as próprias ferramentas. Eles testaram dez diferentes scanners de segurança e descobriram que os que eram mais fáceis de operar manualmente eram frequentemente os mais difíceis de usar em um sistema automatizado. Muitas ferramentas foram projetadas para um humano clicar em uma tela de login e depois entregar a sessão para o scanner. Quando uma IA tentava fazer isso, frequentemente falhava porque o processo de login era muito complexo ou a ferramenta não entendia como manter a sessão ativa. Os pesquisadores desenvolveram um padrão onde uma ferramenta de automação de navegador separada lidava com o login e, em seguida, passava uma lista limpa e autenticada de links para o scanner. Essa simples separação de deveres resolveu muitos dos problemas de integração. Eles também observaram que o cenário das políticas de segurança de IA é volátil; um modelo que permite um teste de segurança hoje pode bloqueá-lo amanhã devido a uma mudança nas regras do provedor. Isso significa que qualquer sistema construído sobre essas ferramentas deve ser flexível o suficiente para substituir os modelos de IA subjacentes sem quebrar todo o fluxo de trabalho.

O artigo conclui que o futuro da segurança automatizada não reside em tornar a IA mais inteligente, mas em construir uma melhor estrutura ao redor dela. Os sistemas mais eficazes são aqueles que tratam a IA como um trabalhador poderoso, porém falível, cercado por uma estrutura rígida de regras, ciclos de memória curtos e verificações independentes. Ao aceitar que a IA irá esquecer, cometerá erros e às vezes ignorará instruções, os engenheiros podem construir sistemas que sejam robustos o suficiente para lidar com o mundo real. O trabalho dos pesquisadores fornece um roteiro para mover-se de demonstrações experimentais para produtos confiáveis e implantados, garantindo que, quando um agente de segurança de IA diz que encontrou uma falha, ele realmente a encontrou, e que o fez sem quebrar o orçamento ou as regras.

Resumo Técnico: Segurança Agêntica: Uma Sistematização de Ferramentas, Modos de Falha e Leis de Design para Testes de Penetração Impulsionados por LLM

Declaração do Problema

O campo da segurança agêntica — o uso de agentes de Large Language Model (LLM) para planejar, despachar e interpretar ferramentas de segurança de forma autônoma — transitou rapidamente de demonstrações teóricas para produtos implantados. No entanto, os profissionais que entram nesta área estão encontrando um conjunto recorrente de falhas que não derivam da falta de capacidade do modelo, mas dos desafios de engenharia ao compor componentes díspares (scanners de segurança, motores de fluxo de trabalho e LLMs conversacionais) em um sistema confiável e não supervisionado.

Os sistemas atuais frequentemente falham devido a:

Saturação de Contexto: Sessões de longa duração perdem evidências residentes conforme a janela de contexto se preenche, fazendo com que o agente "esqueça" descobertas iniciais e gere relatórios que contradizem os dados registrados.
Fricção de Integração: Ferramentas projetadas para operadores humanos (ex: exigindo login manual ou interação com GUI) são difíceis de integrar em pipelines automatizados.
Ruído de Verificação: Pontuadores de red-teaming automatizados produzem altas taxas de falsos positivos, e a verificação em cascata frequentemente falha quando os pontuadores são correlacionados.
Deriva de Orçamento e Escopo: Agentes podem exceder orçamentos de tempo ou custo, ou violar restrições de escopo, porque esses controles são frequentemente colocados em prompts de sistema (que são vulneráveis a injeção) em vez de serem aplicados por código determinístico.
Volatilidade de Fornecedores: Políticas de segurança e disponibilidade de modelos de provedores podem mudar sem aviso prévio, interrompendo operações.

O artigo argumenta que estes não são bugs isolados, mas instâncias de fenômenos gerais com soluções fechadas quantificáveis.

Metodologia

Os autores conduziram uma avaliação prática de dez ferramentas de segurança amplamente utilizadas (análise estática, análise dinâmica, auditoria de nuvem, orquestração e red-teaming de IA) integradas em um pipeline personalizado construído para operação não supervisionada chamado Inspectra.

A metodologia envolve:

Sistematização de Ferramentas: Pontuar ferramentas em um Índice de Fricção de Integração (IFI) quadridimensional que cobre esforço de engenharia, custo organizacional, autorização legal e carga de manutenção.
Modelagem Quantitativa: Derivar modelos matemáticos de forma fechada para:
- Fidelidade de retenção de contexto em sessões de longa duração.
- A eficácia da verificação em cascata (razões de verossimilhança).
- Roteamento de modelos como um problema de otimização de mochila (knapsack).
- Limites de execução ideais para runtimes de ferramentas com cauda pesada.
Instanciação Arquitetônica: Usar o Inspectra como um "exemplo prático" para demonstrar estes princípios. Cada mecanismo no artigo é explicitamente rotulado como entregue (shipped), parcial ou planejado, fornecendo uma visão realista do hiato entre design e implementação.
Análise de Falhas: Catalogar modos de falha específicos (ex: "viés de colapso não pontuável") e derivar correções estruturais em vez de engenharia de prompt heurística.

Contribuições Principais

1. Um Vocabulário para Pipelines Agênticos

O artigo define um sistema agêntico como uma família de políticas estocásticas de LLM envolvidas por um mediador determinístico. Introduz uma métrica, $\alpha$ (autonomia), para distinguir empiricamente um pipeline genuinamente agêntico de um roteirizado, baseando-se em quanto a incerteza do plano é explicada pelas observações.

2. A Economia e Hierarquia do Contexto

Os autores derivam que sessões de longa duração perdem evidências a uma taxa inversamente proporcional ao número de fases.

Regra 1: Para estender o horizonte utilizável, os pipelines devem se dividir em sub-agentes de curta duração que escrevem resultados em um repositório de artefatos como resumos validados por esquema.
O ganho é determinado pela taxa de compressão ( $\rho = s/\delta$ , onde $s$ é o tamanho do resumo e $\delta$ é o custo de tokens brutos), não meramente pelo tamanho bruto da janela.
Para fases que excedem a janela, o empacotamento bin (bin-packing) com resumos de carry-forward é necessário, mas isso introduz um decaimento geomético da fidelidade ( $\lambda^{m-1}$ ). Fatos críticos devem ser relidos literalmente, não apenas resumidos.

3. Cálculo de Verificação para Red-Teaming

Verificação em Cascata: Uma cascata de veredicto de dois estágios multiplica as razões de verossimilhança de seus pontuadores, melhorando significativamente a precisão em baixa prevalência. No entanto, esse ganho colapsa se os dois pontuadores forem correlacionados (ex: mesma família de modelos).
Viés de Colapso Não Pontuável (Unscoreable-Collapse Bias): Registrar resultados não avaliáveis (erros, bloqueios) como "ataque falhou" enviesa o sistema para falsos negativos, especificamente escondendo os achados mais severos. O artigo propõe UNSCOREABLE (NÃO PONTUÁVEL) como uma categoria de resultado de primeira classe.
Algoritmo 2 detalha uma cascata de dois estágios que preserva resultados não pontuáveis e utiliza famílias de modelos distintas para garantir independência.

4. Custo, Roteamento e Orçamentos

Roteamento como Mochila (Knapsack): Atribuir papéis a níveis de modelos (planejador vs. trabalhador) é um problema de mochila 0–1. A estratégia ótima é atualizar papéis baseando-se na eficiência de roteamento ( $\theta_r = \Delta q_r / \Delta c_r$ ), não por convenção.
Limites de Execução Ótimos: Para ferramentas com runtimes de cauda pesada (distribuição de Pareto), o limite de execução ( $\beta^*$ ) que maximiza o valor esperado é dado pela forma fechada:
$\beta^* = \frac{\alpha v}{c}$
onde $\alpha$ é o parâmetro de forma da cauda, $v$ é o valor de uma invocação concluída e $c$ é a taxa de custo.
Regra 2: Orçamentos devem ser aplicados duas vezes (por chamada e por sessão) e os turnos do orquestrador devem ser limitados separadamente, fora da política do LLM.

5. A Base de Computação Confiável (TCB)

O artigo argumenta que a aplicação de escopo e orçamento não pode ser delegada a prompts de sistema.

Prompts são solicitações, não controles; são vulneráveis à saturação de contexto e injeção de prompt.
A camada de mediação determinística (predicado de escopo, contador de orçamento, log de auditoria) deve ser o TCB.
Algoritmo 3 descreve um caminho de invocação mediada onde as verificações de escopo e orçamento ocorrem antes da execução, garantindo que nenhuma política de LLM possa contornar essas restrições.

Resultados e Descobertas

Integração de Ferramentas: Ferramentas como OWASP ZAP e Nmap possuem alta fricção de integração devido à complexidade de autenticação e restrições legais, respectivamente. Ferramentas como Semgrep e Gitleaks são mais fáceis de integrar, mas requerem tratamento específico para ruído e falsos positivos.
Configuração do Inspectra: Os autores fornecem uma configuração do mundo real (Tabela IV) mostrando como estas leis de design são aplicadas, incluindo limites de orçamento específicos (ex: limites de 30 minutos para exploração) e atribuições de nível.
Modos de Falha: O artigo documenta que falhas "silenciosas" (ex: arquivos de saída ausentes, respostas não pontuáveis absorvidas como negativas) são mais perigosas do que crashes explícitos porque produzem uma falsa confiança.
Reprodutibilidade: A estabilidade semântica (deduplicação por hash de conteúdo) é alcançável mesmo que o acordo de trajetória byte a byte não seja, devido à natureza estocástica dos LLMs.

Significância e Alegações

O artigo afirma que a segurança agêntica não é bloqueada pela capacidade do modelo, mas pela disciplina de engenharia e design estrutural. Sua significância reside em:

Mudança da Demonstração para a Produção: Fornecer a "conta de engenharia" do que torna estes sistemas confiáveis, orçáveis e reproduzíveis.
Regularidades Quantitativas: Substituir heurísticas de tentativa e erro por leis de forma fechada (ex: a razão de compressão para contexto, a solução de mochila para roteamento, o limite $\alpha v/c$ para orçamentos).
Mudança Arquitetônica: Estabelecer que o LLM deve estar fora da Base de Computação Confiável (TCB). A única arquitetura defensável para um agente que lê conteúdo controlado por atacante e executa ferramentas é aquela onde o modelo propõe e o código determinístico dispõe.
Transparência: Ao rotular cada componente de sua própria plataforma (Inspectra) como entregue, parcial ou planejado, os autores fornecem uma calibração realista para outras equipes, reconhecendo que juízes secundários e cobertura total em nuvem são frequentemente "projetados, mas nunca construídos".

O artigo conclui que, embora a primeira falha (um relatório autocontraditório) seja inevitável, compreender estas leis de design permite que os profissionais reconheçam a causa imediatamente, reduzindo o tempo de depuração de meses para uma tarde.