O modelo não é o produto: o que um CISO deveria avaliar antes de contratar segurança ofensiva com IA

Durante anos, comprar segurança ofensiva foi uma decisão binária. Ou você contratava uma equipe de pentesters humanos, com tudo o que isso implica em tempo e custo, ou se resignava a um scanner automático que cuspia falsos positivos. Branco ou preto. Essa época acabou.

A IA ofensiva já encontra e explora vulnerabilidades reais (daquelas que são pagas) com uma velocidade e uma escala que o pentest manual não alcança. Deixou de ser uma promessa de laboratório para se tornar uma capacidade disponível. E isso obriga qualquer líder de segurança a repensar não só quem contrata, mas como compra segurança ofensiva.

Se eu estivesse do outro lado da mesa como CISO, decidindo a quem confio a superfície de ataque da minha empresa, essa realidade não me levaria a uma conclusão simples. Me levaria a uma pergunta melhor.

Dois caminhos válidos, não dois lados

Hoje existem, pelo menos, duas opções legítimas, e convém não confundi-las.

A primeira são as empresas de pentest tradicional que potencializam seus pentesters com ferramentas de IA e com licenças de modelos como o Claude. Não é marketing vazio: um bom pentester com um copiloto como o Claude raciocina melhor sobre o código, as respostas e as hipóteses, e ganha nas duas coisas que historicamente escapavam ao pentest manual: tempo e cobertura. Cobre mais superfície em menos dias. É uma melhoria genuína do modelo clássico.

A segunda opção não é entregar um modelo a um humano e confiar no seu critério, e sim construir uma arquitetura e um modelo de valor em torno do LLM: onde o modelo não é o produto, mas mais um componente, governado por um sistema que o cerca. É a abordagem da Strike, mas a distinção de fundo não está em dizer que se usa IA, e sim em onde mora o controle.

Não estão em lados opostos. São caminhos distintos. E isso não invalida o trabalho do pentester aumentado com IA; na verdade, os melhores sistemas combinam humanos, modelos e controles. A pergunta não é "quem usa mais IA" (os dois usam), e sim onde mora a garantia operacional.

Como se vê hoje "equipar um pentester com o Claude": skills

Convém aterrissar o que significa, na prática de 2026, potencializar um pentester com uma ferramenta como o Claude. Hoje significa, sobretudo, skills: módulos que empacotam instruções, scripts e conhecimento para uma tarefa concreta. Reconhecimento, o teste de um tipo de vulnerabilidade, a geração de um relatório. É a forma como o setor está estendendo os modelos, e é genuinamente boa: encapsula experiência repetível e a deixa a um comando de distância.

A chave está em como o modelo decide qual skill usar. O Claude não carrega todas as skills de uma vez; usa recuperação progressiva (progressive disclosure). No início ele só vê o nome e a descrição de cada skill (apenas uma centena de tokens por skill). Com esses metadados, e nada mais, julga se uma skill é relevante para a tarefa. Só quando "acredita" que se aplica é que carrega o corpo de instruções; e só então, os scripts e arquivos que essa skill referencia. É elegante: mantém o contexto leve e escala para centenas de capacidades.

Mas é aí mesmo que está a fissura. Essa decisão inicial de esta skill se aplica ao que estou fazendo? é um juízo do modelo sobre uma descrição de uma linha, não uma regra determinística. Com poucas skills funciona bem. Com muitas, as descrições competem e se sobrepõem, e o modelo pode não acionar a skill correta, acionar a errada, ou simplesmente deixá-la passar. E faz isso em silêncio: não há exceção, não há um log dizendo "ignorei a skill que testava IDOR no body". Pior ainda, à medida que o contexto se acumula, a fidelidade com que o modelo segue cada instrução se degrada (o chamado context rot): a informação continua "ali", mas pesa menos.

Para um pentest, essa fissura é justamente a perigosa. Que o modelo omita a skill que validava um vetor, ou o controle que delimitava o escopo, não gera uma falha evidente: gera um teste incompleto que aparenta estar completo. E é aí que aparece a pergunta de fundo.

A pergunta que de fato importa: quem controla o fluxo?

Quando uma parte importante do controle operacional fica delegada ao modelo, ao prompt ou a instruções em linguagem natural, aparece uma fragilidade que um CISO deveria olhar com cuidado. Não é um problema de talento do pentester nem de qual modelo se escolhe: é uma questão de onde reside a garantia.

Como se garante que o LLM não saia do escopo autorizado? Que não exceda a taxa de requisições por segundo negociada com o cliente? Que não dispare uma ação destrutiva sobre um recurso que não deveria tocar? Se a resposta para tudo isso mora dentro de instruções em linguagem natural, então, quando algo dá errado, a pergunta incômoda é: como se depura um erro de prompt?

Não se depura como se depura o código. Um modelo de linguagem é não determinístico por design. O mesmo prompt pode se comportar de forma diferente duas vezes. Não há breakpoint, não há stack trace, não há um teste que reproduza a falha de forma confiável. Na maioria das disciplinas isso é um inconveniente. Em pentesting, onde uma única requisição fora de escopo ou um pico de tráfego podem derrubar um sistema produtivo do cliente ou a conectividade de uma equipe inteira por uma única variável mal propagada, é um risco operacional sério.

O modelo não é o produto: a arquitetura sim

É aqui que mover o controle para fora do modelo muda a equação. A ideia central é deliberadamente pouco glamorosa: cercar o modelo com uma arquitetura determinística, e usar o LLM apenas onde ele agrega valor real —raciocinar, interpretar, priorizar—, não como o piloto que toma todas as decisões.

Na prática, isso significa um processo por etapas onde cada passo executa ferramentas em uma ordem fixa, reproduzível e testável, e o modelo entra como um perceptor que interpreta resultados, não como um agente solto que decide o que atacar e como. O escopo não é "pedido" ao modelo em um parágrafo: é validado em um portão determinístico antes que uma única requisição seja disparada. A taxa de requisições não depende de o LLM "lembrar" de não exceder: o sistema a impõe. As ações destrutivas não ficam a critério do prompt: estão protegidas por guardas no código.

A regra prática é simples: o controle operacional não deveria morar na cabeça do modelo. Um agente não deveria lembrar o escopo; deveria consultar uma política assinada antes de cada requisição. Não deveria tentar não fazer requisições demais; deveria ter um rate limiter externo ao modelo. Não deveria decidir se um achado é reportável; deveria passar por um validador reproduzível.

E quando o juízo humano é insubstituível, o sistema não improvisa: cede o controle em pontos de handoff explícitos, faz 95% do trabalho de forma automática e deixa que a pessoa toque apenas nos 5% onde o modelo não rende. Precisão acima de autonomia aparente.

Essa mistura de arquitetura determinística mais juízo humano nas bordas é o que permite separar o raciocínio em etapas auditáveis e confirmar cada achado com um validador determinístico e uma prova de exploração reproduzível antes de reportá-lo.

A arquitetura na prática: codificando o know-how operacional

Mas uma arquitetura sólida, por si só, também não basta. Em segurança ofensiva, o controle do fluxo só tem valor se estiver construído sobre conhecimento real da matéria. E aí há uma diferença importante: a Strike não está tentando construir segurança ofensiva com IA a partir de uma folha em branco, nem de um conjunto de prompts isolados. Está construindo sobre anos de experiência fazendo pentesting no mercado, com milhares de horas de testes em empresas, aplicações e contextos muito distintos: bancos, fintech, e-commerce, varejo, SaaS, saúde, energia, telecomunicações e plataformas internas.

Esse percurso dá ao sistema algo que um modelo sozinho não tem: norte. Por trás de cada decisão de arquitetura há um hacking team com experiência em exploração, validação, triagem, relatório e discussão de impacto com clientes reais; e equipes de engenharia e inteligência artificial analisando execuções, bifurcações e resultados para melhorar o agente de forma contínua.

Tudo isso vive dentro de uma plataforma que sustenta a operação: ordena execuções, centraliza evidências, facilita a rastreabilidade, conecta o trabalho do agente com o critério humano e ajuda os achados a chegarem ao cliente com contexto, validação e controle.

Esse cruzamento entre hacking skills, security engineering, prompt engineering, inteligência artificial, plataforma e experiência operacional é o que transforma a arquitetura em produto. Não se trata só de automatizar tarefas ofensivas; trata-se de codificar o know-how acumulado da Strike em regras, validadores, fluxos e critérios que o sistema possa repetir com controle.

O que, como CISO, eu teria que garantir ao meu negócio

É isso que acaba inclinando a balança. Os erros vão acontecer (nenhum fornecedor honesto promete o contrário). A diferença é que com uma arquitetura determinística em torno do modelo eu sei onde o agente pode falhar e onde o humano falha, e isso é justamente o que posso transferir como garantia ao meu negócio:

Escopo: não se rompe, porque é validado em código antes de cada ação, não em um parágrafo de instruções.

Carga: a taxa de requisições é imposta pela arquitetura, não pela memória do modelo.

Reprodutibilidade: um achado vem com uma prova que posso rodar de novo; um erro vem com um ponto do fluxo que posso inspecionar e corrigir.

Decisões conforme a arquitetura de cada aplicação: SPAs, APIs, GraphQL, esquemas de autenticação distintos (cada um com suas regras) são tratados com lógica explícita, não com a esperança de que o modelo "entenda".

Um pentester potencializado com IA é, sem dúvida, melhor que um pentester sem ela. A diferença não está em quem usa IA, e sim em onde mora a garantia: se no critério de uma pessoa confiando em uma caixa não determinística, ou em uma arquitetura que cerca o modelo. Esta última me dá algo diferente: controle do fluxo em cada etapa do pentest, rastreabilidade quando algo se rompe, e regras fixas que não dependem de o modelo ter um bom dia.

Por isso, se eu fosse o CISO, me inclinaria por um fornecedor construído com essa filosofia. Não por usar IA, mas por uma ideia de fundo: a próxima geração de segurança ofensiva não se ganha com prompts melhores, e sim com arquiteturas que convertem o raciocínio probabilístico em processos controlados, auditáveis e reproduzíveis. Em segurança ofensiva, o modelo não pode ser o produto. O produto é o controle.

‍