Lançamento do ThreatBook RedAgents Coloca Múltiplos Pentesters de IA Contra o Modelo de Agente Único
A ThreatBook lançou o RedAgents com pelo menos quatro agentes de pentest com IA, contestando a ideia de que um único testador autônomo possa fornecer uma avaliação completa de segurança. O lançamento do ThreatBook RedAgents transforma sistemas ofensivos concorrentes em um conjunto coordenado de testes. Ainda assim, a empresa não publicou uma comparação independente que comprove que a abordagem combinada encontra mais vulnerabilidades com menos falsos positivos.
O RedAgents entra em um mercado já moldado por plataformas de segurança autônoma como XBOW e Horizon3.ai. Esses concorrentes vendem, em grande parte, o desempenho de uma plataforma e de seu sistema de testes. A ThreatBook aposta em algo diferente: as equipes de segurança devem reunir vários agentes e comparar seus resultados por meio de uma única interface.
Essa distinção cria a verdadeira história. Mais agentes podem explorar caminhos de ataque distintos, mas também aumentam o número de ferramentas, permissões e decisões que os operadores precisam governar. O RedAgents precisa provar que a agregação amplia a cobertura sem multiplicar o risco operacional.
O Lançamento do ThreatBook RedAgents Muda a Unidade de Competição
A ThreatBook não está apresentando apenas mais um scanner autônomo. Ela está posicionando a coleção de agentes como o produto.
A ThreatBook anunciou o RedAgents em 16 de outubro de 2026. A empresa o descreve como uma plataforma de software como serviço para executar múltiplos agentes de teste de penetração com IA contra o mesmo alvo autorizado.
Um agente de pentest com IA usa modelos, ferramentas de segurança e planejamento iterativo para identificar e, às vezes, validar fraquezas exploráveis. O RedAgents oferece às equipes de segurança uma interface unificada para escolher agentes, definir um alvo e revisar seus resultados.
A lista inicial inclui Artex Pro, Cyber(YanJi), Yanxun e CyberStrikeAI Enterprise Edition. A ThreatBook afirma que a plataforma pode executar esses sistemas de forma independente ou em paralelo, dependendo da avaliação.
Essa escolha importa porque agentes individuais de pentest não necessariamente abordam um alvo da mesma maneira. Um pode priorizar a lógica de aplicações web, enquanto outro dedica mais tempo ao reconhecimento ou a caminhos de credenciais.
O CEO da ThreatBook, Feng Xue, descreveu o modelo de fornecedor único como uma fonte de visibilidade limitada. Seu argumento é que dois agentes podem encontrar vulnerabilidades diferentes, mesmo quando ambos recebem o mesmo alvo.
A empresa afirma que o RedAgents consolida dados de testes, logs e descobertas de vulnerabilidades em uma única visualização. Esse design deve reduzir o trabalho manual envolvido na operação de produtos separados e na conciliação de seus relatórios.
O lançamento do RedAgents também inclui várias alegações de segurança em torno dessa camada de orquestração. A ThreatBook afirma que os clientes definem o escopo dos testes por meio de uma lista de permissões, e que os agentes devem permanecer dentro desses parâmetros autorizados.
A empresa também afirma que os dados de teste permanecem em seu ambiente, em vez de serem transferidos para agentes de terceiros. Ela também anuncia retenção zero de dados, o que permite aos clientes solicitar a exclusão completa de seus dados de teste.
Essas continuam sendo alegações do fornecedor até que clientes ou avaliadores independentes as verifiquem em condições realistas. O anúncio não explica como o RedAgents impõe limites quando um agente gera um comando inesperado.
Também não especifica se cada comando passa por verificações determinísticas de políticas. O comunicado não fornece detalhes sobre interrupção de emergência, limites de taxa, isolamento de privilégios ou aprovação humana para ações sensíveis.
Ainda assim, o produto muda a questão competitiva. Os compradores não estão mais sendo questionados apenas sobre qual pentester autônomo tem o melhor desempenho.
Eles são questionados se escolher um único sistema é a arquitetura errada. A ThreatBook quer que a camada de orquestração se torne mais valiosa do que qualquer agente individual conectado a ela.
Essa proposta se assemelha à varredura antimalware com múltiplos mecanismos, em que vários sistemas de detecção inspecionam o mesmo objeto. A ThreatBook usa explicitamente essa ideia para explicar por que descobertas sobrepostas e não sobrepostas podem melhorar a cobertura.
No entanto, o pentesting cria um problema de coordenação mais difícil. Um mecanismo antimalware avalia um artefato, enquanto um agente de pentest pode interagir com serviços ativos, contas, bancos de dados e controles de rede.
Portanto, combinar agentes exige mais do que coletar resultados. A plataforma precisa coordenar ações, evitar interferências, normalizar evidências e identificar descobertas duplicadas sem ocultar diferenças significativas.
Esses requisitos transformam o RedAgents de um pacote de produtos em um plano de controle operacional. Seu desempenho confiável nesse papel determinará se o modelo de agregador oferece valor real.
Por Que o Pentesting com IA Multiagente Está Chegando Agora
O momento reflete uma mudança de avaliações de segurança agendadas para validação contínua em velocidade de máquina.
Testes de penetração tradicionais frequentemente dependem de especialistas humanos escassos, janelas de contratação fixas e relatórios preparados manualmente. Essa estrutura oferece uma visão detalhada, mas o ambiente pode mudar logo após o fim dos testes.
As aplicações agora recebem lançamentos frequentes, ativos de nuvem surgem dinamicamente e serviços expostos mudam sem esperar pela próxima avaliação. O intervalo entre testes pode, portanto, se tornar uma janela de risco não gerenciada.
A ThreatBook argumenta que agentes de IA tornam práticos ciclos de testes mais curtos. O RedAgents foi projetado para permitir que equipes de segurança executem avaliações diariamente, semanalmente ou mensalmente, em vez de tratar o pentesting como um exercício anual.
Essa ideia não é exclusiva da ThreatBook. Fornecedores de testes autônomos já promovem avaliações contínuas, novos testes e validação de caminhos de ataque como alternativas a projetos isolados de consultoria.
A XBOW afirma que seu sistema encontra e explora vulnerabilidades web de forma autônoma, ao mesmo tempo que produz evidências para as fraquezas que valida. A empresa informou ter alcançado a primeira posição no ranking dos Estados Unidos da HackerOne em 2025.
Seu relato publicado afirma que o sistema enviou quase 1.060 vulnerabilidades durante esse esforço. Revisores humanos verificaram os relatórios quanto à conformidade com o programa, mas a XBOW afirma que eles não participaram da descoberta ou exploração.
Esses números vêm da XBOW e não devem servir como referência direta para o RedAgents. Ainda assim, mostram por que o pentesting autônomo avançou além das demonstrações de laboratório.
O histórico de benchmarks da XBOW também ilustra a dificuldade de medir o progresso. A empresa primeiro usou desafios de treinamento estabelecidos, depois criou cenários inéditos e avançou para alvos de bug bounty em produção.
A ThreatBook não publicou uma avaliação comparável para a plataforma RedAgents completa. Em vez disso, aponta para conquistas associadas a agentes individuais de sua lista.
A empresa afirma que o Cyber(YanJi) resolveu 54 dos 54 problemas visados em um hackathon da Tencent Cloud. Também afirma que a versão open source do Artex venceu o Agent+ Offensive and Defensive Challenge da Baidu em setembro de 2026.
O CyberStrikeAI teria acumulado mais de 7.800 estrelas no GitHub antes de a ThreatBook adquiri-lo em setembro de 2026. A popularidade pode indicar interesse de desenvolvedores, mas não mede a precisão dos testes empresariais nem a execução segura.
Esses sinais em nível de agente explicam por que a agregação parece atraente. Um comprador pode acessar várias abordagens sem prever qual agente dominará cada aplicação, classe de vulnerabilidade ou ambiente de infraestrutura.
O modelo também dá à ThreatBook uma forma de incorporar sistemas futuros. Sua página de produto afirma que a plataforma continuará adicionando agentes comerciais, acadêmicos e open source.
Isso cria um caminho de atualização potencialmente mais rápido do que reconstruir um agente proprietário para cada nova técnica. A plataforma pode adicionar um especialista quando esse especialista oferece uma capacidade distinta.
No entanto, o mesmo design transfere a responsabilidade para avaliação e governança. A ThreatBook precisa decidir quais agentes se qualificam, quais permissões recebem e como os clientes podem comparar seu comportamento.
Uma equipe de segurança também precisa saber se dois agentes realmente fornecem perspectivas independentes. Vários produtos ainda podem herdar as mesmas fraquezas de modelo, dados de treinamento, ferramentas ou padrões de planejamento.
A tese multiagente só se torna valiosa quando a diversidade produz cobertura útil. Executar agentes semelhantes várias vezes pode aumentar a atividade sem ampliar a percepção.
É por isso que a métrica mais importante do RedAgents não é o número de ferramentas conectadas. É o número de descobertas validadas e não duplicadas que essas ferramentas encontram com segurança além de uma forte referência de agente único.
RedAgents Versus o Modelo de Pentesting com Agente Único
A disputa central é entre a cobertura de portfólio e a consistência de um sistema de testes rigidamente controlado.
Fornecedores de plataforma única podem otimizar cada parte da avaliação em torno de uma arquitetura. Eles controlam planejamento, acesso a ferramentas, padrões de evidência, regras de segurança, relatórios e novos testes.
Essa integração vertical pode simplificar a responsabilização. Quando um teste se comporta de forma inadequada ou uma descoberta se mostra pouco confiável, o cliente tem um sistema e um fornecedor para examinar.
A ThreatBook abre mão de parte dessa simplicidade para obter diversidade. O RedAgents pode reunir agentes criados por equipes diferentes, com diferentes pontos fortes e trajetórias técnicas.
Sua plataforma multiagente apresenta a seleção como uma escolha do cliente. Uma equipe pode implantar um agente para uma tarefa focada ou vários agentes para uma validação cruzada mais ampla.
Isso se assemelha à formação de uma equipe humana de red team com especialistas em diferentes superfícies de ataque. Um especialista em aplicações web, um especialista em identidade e um testador de nuvem podem enxergar rotas diferentes pelo mesmo ambiente.
No entanto, membros de equipes humanas se comunicam, resolvem conflitos e reconsideram premissas juntos. Agentes de software precisam de orquestração explícita para alcançar a mesma coordenação.
A execução paralela também pode criar interferências. Um agente pode alterar o estado de uma aplicação, consumir um token, acionar um bloqueio ou modificar evidências antes que outro agente alcance o mesmo caminho.
Os materiais de lançamento não explicam como o RedAgents lida com essas colisões. Também não dizem se a plataforma serializa ações perigosas ou isola cada agente em um ambiente de teste distinto.
A agregação de resultados introduz outro desafio. Dois agentes podem relatar a mesma vulnerabilidade subjacente com descrições, classificações de severidade ou evidências de exploração diferentes.
Uma plataforma útil deve reconhecer essa sobreposição sem fundir caminhos de ataque distintos. Ela também deve preservar evidências suficientes para que um testador humano reproduza e priorize cada descoberta.
A ThreatBook afirma que o RedAgents elimina duplicidades e classifica descobertas automaticamente. Ela não divulgou dados que mostrem quão precisamente esse processo funciona em toda a lista inicial de agentes.
A redução de falsos positivos é outra alegação central. Executar vários agentes não faz automaticamente um resultado incorreto desaparecer.
Os agentes podem repetir a mesma premissa falsa, especialmente quando compartilham um modelo subjacente ou uma ferramenta de segurança. Por outro lado, uma descoberta correta de um especialista pode aparecer apenas uma vez.
Um sistema de votação poderia, portanto, rejeitar um resultado valioso porque outros agentes não o reproduziram. A união de todas as descobertas poderia gerar o problema oposto e sobrecarregar os revisores.
O RedAgents precisa de um mecanismo de decisão melhor do que um simples consenso. Ele deve distinguir descobertas reproduzidas, descobertas identificadas de forma independente e descobertas de especialistas que exigem validação manual.
A plataforma também enfrenta concorrência de serviços consolidados de pentesting autônomo. O NodeZero, da Horizon3.ai, se concentra na descoberta autônoma de caminhos de ataque, enquanto o XBOW enfatiza vulnerabilidades web validadas e evidências de produção.
Esses sistemas oferecem um ponto de referência para as expectativas dos compradores. Os clientes vão querer exploits reproduzíveis, ativos afetados claramente identificados, orientações de remediação e confirmação confiável após uma correção.
O RedAgents pode se diferenciar se vários agentes descobrirem fraquezas materialmente distintas durante o mesmo engajamento. Ele também pode se destacar se um único plano de controle tornar esses resultados mais fáceis de gerenciar do que vários contratos separados.
O agregador perde sua vantagem se os clientes precisarem investigar manualmente resultados conflitantes. Também perde se os agentes conectados não conseguirem igualar a profundidade de uma plataforma especializada.
Portanto, as primeiras comparações relevantes devem usar alvos, escopos e janelas de teste idênticos. Elas devem medir descobertas únicas validadas, falsos positivos, incidentes operacionais e tempo de revisão humana.
Sem essas evidências, o RedAgents continua sendo uma arquitetura plausível, e não um substituto comprovado. O lançamento estabelece a direção do produto, não sua superioridade.
O Mecanismo Só Funciona se a Orquestração Acrescentar Sinal
Mais agentes melhoram a cobertura apenas quando o RedAgents controla suas ações e transforma seus resultados em evidências defensáveis.
A primeira função da plataforma é a aplicação do escopo. Testes de penetração envolvem ações que não seriam autorizadas fora de um engajamento definido.
O Instituto Nacional de Padrões e Tecnologia dos Estados Unidos define regras de engajamento como restrições estabelecidas antes do início dos testes. Essas regras concedem autoridade para atividades especificadas sem fornecer permissão ilimitada.
As orientações do NIST identificam alvos, sistemas restritos, técnicas aceitas, períodos de teste e endereços de origem como detalhes importantes do engajamento. As regras de teste permanecem relevantes mesmo quando o software realiza o trabalho.
A ThreatBook afirma que o RedAgents usa listas de permissões para definir o escopo de teste. Uma lista de permissões pode restringir endereços de destino, mas a operação segura exige controles mais granulares.
As equipes podem precisar proibir técnicas de negação de serviço, ações destrutivas em bancos de dados, alterações de senha ou acesso a registros de clientes em produção. Elas também podem precisar de janelas de manutenção e limites de taxa de solicitações.
Uma plataforma multiagente deve aplicar essas restrições de forma consistente em todos os sistemas conectados. Ela não pode presumir que cada agente interpreta uma instrução escrita da mesma maneira.
A autorização deve ser aplicada fora do ciclo de raciocínio do modelo. Controles de rede, credenciais isoladas, políticas de comandos e permissões por alvo fornecem limites mais fortes do que prompts isoladamente.
Isso importa porque agentes de modelos de linguagem podem selecionar ferramentas e gerar sequências de ações dinamicamente. Sua flexibilidade os ajuda a explorar ambientes desconhecidos, mas também torna difícil prever cada ação futura.
A OWASP chama uma versão desse problema de agência excessiva. Ela ocorre quando um sistema de IA recebe mais funcionalidades, permissões ou autonomia do que sua tarefa exige.
A OWASP recomenda reduzir as ferramentas disponíveis, limitar permissões, exigir aprovação humana para ações consequentes e aplicar a autorização em sistemas downstream. Suas orientações sobre agência excessiva também alertam sobre agentes pares comprometidos em ambientes multiagente.
Esse alerta se aplica diretamente ao RedAgents. Um agregador deve tratar cada agente conectado tanto como fonte de capacidade de segurança quanto como um componente que pode falhar.
O registro centralizado pode ajudar. O RedAgents afirma que registra logs e resultados dos agentes participantes em um único local, oferecendo aos revisores uma trilha de auditoria comum.
Uma trilha compartilhada deve mostrar qual agente emitiu cada comando, qual identidade utilizou, qual alvo respondeu e se um controle alterou a ação solicitada. Ela também deve reter evidências de cada descoberta validada.
A retenção zero de dados acrescenta outro trade-off operacional. Excluir dados sensíveis de teste pode reduzir a exposição, mas os clientes podem precisar de evidências selecionadas para remediação, auditoria e revisão de incidentes.
Portanto, a plataforma deve tornar as políticas de retenção precisas. Os compradores precisam saber o que a “exclusão completa” abrange, quando a exclusão ocorre e se backups ou logs de diagnóstico seguem a mesma política.
O isolamento de dados se torna mais complexo quando agentes de terceiros entram na plataforma. A ThreatBook afirma que os dados de teste dos clientes permanecem em seu ambiente, em vez de chegar a esses provedores.
Essa afirmação exige explicação arquitetural. Os clientes devem entender se o código dos agentes é executado em isolamento gerenciado pela ThreatBook, se modelos externos recebem prompts e como os segredos são filtrados.
O valor da plataforma vem, em última instância, de seu pipeline de evidências. A descoberta, por si só, é insuficiente se as equipes de segurança não puderem confiar, reproduzir e priorizar as descobertas.
Um fluxo de trabalho multiagente confiável preservaria as evidências individuais enquanto geraria uma avaliação unificada. Ele mostraria quando os agentes concordam, quando discordam e por que a plataforma selecionou sua severidade final.
O RedAgents descreveu o design de alto nível, mas não esse nível de implementação. A documentação técnica e as avaliações controladas de clientes determinarão se a orquestração realmente acrescenta sinal.
A Questão da Segurança Faz Parte do Produto
O RedAgents combina capacidades ofensivas que devem continuar úteis para defensores sem se tornarem uma infraestrutura de ataque descontrolada.
Todo produto de pentesting autônomo enfrenta um problema de uso dual. As mesmas capacidades que ajudam uma empresa a validar defesas podem ajudar um invasor a automatizar reconhecimento e exploração.
A lista inicial da ThreatBook torna essa tensão especialmente visível. A empresa afirma que o Artex passou de código aberto para código fechado em 8 de outubro de 2026, após suposto uso indevido em ataques.
O anúncio da ThreatBook relaciona essa decisão a incidentes que afetaram organizações financeiras sul-coreanas. No entanto, o comunicado não fornece um relatório completo e independente de incidentes que sustente todos os detalhes.
O episódio ainda levanta uma questão direta de governança. Se um agente passa a ser associado a abusos, como o RedAgents avalia seu código, modelos, dependências e comportamento operacional antes da implantação?
A empresa afirma que o Artex Pro adiciona controle, estabilidade e rastreabilidade além da edição de código aberto. Essas descrições não receberam validação independente nos materiais de lançamento.
Adquirir ou comercializar uma ferramenta pode criar responsabilização, mas não torna a ferramenta segura automaticamente. Os controles precisam ser testados contra falhas, instruções maliciosas, dependências comprometidas e respostas inesperadas dos alvos.
A diversidade de agentes pode ampliar a superfície de ataque dentro da plataforma de testes. Cada conector, integração de ferramenta, endpoint de modelo, repositório de credenciais e caminho de relatórios cria outra fraqueza potencial.
O agregador também precisa se defender contra injeção de prompt. Um alvo hostil poderia apresentar conteúdo criado para manipular um agente a ignorar restrições ou expor informações sensíveis.
A comunicação multiagente introduz outra rota. Um agente comprometido poderia produzir contexto enganoso que afete as escolhas de um orquestrador ou de um agente par.
A OWASP recomenda tratar entradas e saídas de agentes como não confiáveis. Controles determinísticos devem mediar solicitações consequentes, em vez de delegar todas as decisões de autorização a um modelo.
A lista de permissões e o modelo de dados centralizado da ThreatBook abordam parte desse problema. Eles não respondem se comandos individuais recebem aplicação de políticas antes da execução.
A empresa também não identificou auditorias externas, parceiros de design nomeados ou clientes de produção para o RedAgents. Testes limitados podem gerar essas evidências, mas os primeiros adotantes devem exigir limites claros.
Os compradores devem perguntar quais sistemas são compatíveis, quais ações exigem aprovação e como as credenciais são delimitadas. Também devem perguntar o que acontece quando um agente sai do fluxo de trabalho atribuído.
A reversão e a interrupção de emergência merecem igual atenção. Um operador de segurança precisa de uma forma confiável de interromper todos os agentes ativos, revogar credenciais e preservar evidências durante um teste anormal.
Benchmarks independentes devem incluir resultados de segurança, não apenas contagens de vulnerabilidades. Um sistema que encontra mais problemas enquanto causa interrupções ou lida inadequadamente com segredos não oferece uma avaliação melhor.
Os testes também devem separar ambientes de treinamento de sistemas de produção. Mesmo plataformas autônomas maduras reconhecem que nenhuma avaliação automatizada de segurança pode prometer impacto zero.
A carga aumenta quando vários agentes operam simultaneamente. Mais atividade pode acionar controles defensivos, bloquear contas ou afetar serviços sensíveis à taxa.
O RedAgents deve tornar a simultaneidade visível e configurável. Os clientes precisam controlar janelas de teste, taxas de solicitação, endpoints protegidos e o número máximo de ações simultâneas.
Uma implementação cautelosa começaria com aplicações isoladas, réplicas que não estão em produção e ativos externos com escopo estritamente definido. As equipes poderiam então comparar as descobertas com validação humana antes de ampliar o acesso.
Essa abordagem não enfraqueceria o valor do produto. Ela daria às equipes de segurança evidências sobre quais agentes têm bom desempenho em seu próprio ambiente.
Portanto, o lançamento apresenta capacidade e risco como uma única questão inseparável. O RedAgents só terá sucesso se seu plano de controle for pelo menos tão sofisticado quanto os sistemas ofensivos que coordena.
Três Sinais Mostrarão se o RedAgents Cumpre o Prometido
A próxima fase deve ser julgada por evidências comparativas, controles de segurança aplicáveis e adoção real por clientes.
O primeiro sinal é um benchmark controlado contra uma forte linha de base de agente único. A ThreatBook deve publicar testes usando alvos, credenciais, escopos e limites de tempo idênticos.
O resultado útil não seria uma contagem total de alertas. Ele mostraria vulnerabilidades únicas validadas, descobertas duplicadas, falsos positivos, distribuição de severidade e tempo de verificação humana.
Esse benchmark fortaleceria o argumento multiagente se o RedAgents encontrasse consistentemente problemas importantes não identificados por cada participante individual. Resultados semelhantes com mais trabalho operacional o enfraqueceriam.
O segundo sinal é uma documentação detalhada de segurança. A ThreatBook deve explicar a mediação de comandos, o isolamento de agentes, os controles de credenciais, os mecanismos de aprovação, o comportamento de retenção e a interrupção de emergência.
Testes independentes teriam mais peso do que uma lista de funcionalidades. Os compradores precisam de evidências de que um agente não pode sair de seu escopo devido a injeção de prompt, erro de modelo ou saída comprometida de um agente par.
O terceiro sinal é a adoção recorrente além de testes limitados. Estudos de caso nomeados devem mostrar com que frequência as organizações executam testes, quais agentes selecionam e se as descobertas levam a correções verificadas.
Os dados de adoção também revelariam se os clientes valorizam a escolha de agentes ou simplesmente selecionam um sistema padrão. A tese do agregador enfraquece se a maioria dos usuários ignorar a lista mais ampla.
O RedAgents entra no mercado com uma resposta coerente para uma limitação real. Nenhuma abordagem única de teste descobre todas as vulnerabilidades, e mudanças frequentes no software tornam a avaliação periódica menos suficiente.
No entanto, adicionar agentes não garante melhor segurança. A plataforma deve provar que sua orquestração cria descobertas diversas e validadas sem criar um conjunto igualmente diverso de riscos.
Líderes de segurança que avaliam o lançamento do ThreatBook RedAgents devem começar com uma comparação restrita. Atribuam ao RedAgents e a uma alternativa consolidada o mesmo alvo autorizado e, em seguida, meçam as descobertas confirmadas e a carga de trabalho dos operadores.
Eles devem preservar a revisão humana para ações consequentes e exigir regras explícitas de engajamento. Os resultados devem ser julgados por reprodutibilidade, valor para remediação e execução segura.
A questão para o próximo trimestre é concreta: a ThreatBook conseguirá publicar evidências de que vários agentes governados superam um pentester autônomo maduro? Esse resultado — e não o tamanho da equipe — determinará se o pentesting com IA multiagente se tornará uma categoria duradoura.
