Agente de Pentest Yaga 3 SuperIntelligence

Seis modelos de superinteligência atuando de forma complementar em cada etapa do pentest

A Yaga 3 Superintelligence é a nova geração do agente de pentest da HackerSec. A principal evolução está na capacidade de análise: onde a geração anterior orquestrava quatro modelos de inteligência artificial, a Yaga 3 combina seis, atuando de maneira complementar durante as diferentes etapas do pentest. Na prática, isso amplia a diversidade de raciocínio, reduz pontos cegos e permite que uma mesma superfície seja analisada sob perspectivas diferentes.

Este artigo detalha o que sustenta esse ganho: a especialização funcional de cada modelo por fase do pipeline ofensivo, o Chain Engine v3, que resolve cadeias de múltiplos estágios, do acesso inicial ao comprometimento de domínio, e o motor de CVE Intelligence, que integra vulnerabilidades recém-divulgadas em ciclo inferior a 24 horas, inclusive quando ainda não existe exploração pública disponível. Os resultados quantitativos do YagaBench são publicados e atualizados continuamente em hackersec.com/evals.

1. Introdução

A Yaga chegou a este ponto em três gerações distintas. A primeira (v1.x) demonstrou a viabilidade de um agente autônomo conduzindo pentests completos com dois modelos de IA em orquestração básica. A segunda (v2.x) introduziu o Knowledge Graph, o Chain Engine para encadeamento de vulnerabilidades, o sistema de guardrails formalizados matematicamente, e a expansão para quatro modelos orquestrados, estabelecendo-se como referência no domínio [8] [9].

A terceira geração reflete a tese arquitetural que motivou o redesenho: inteligência de nível superior em segurança ofensiva não emerge de um modelo mais potente operando isoladamente, mas da orquestração especializada de múltiplos modelos com capacidades complementares, alimentados por inteligência de ameaças em tempo quase-real, e conectados por um motor de raciocínio capaz de construir cadeias de exploração de profundidade e amplitude sem precedentes em sistemas autônomos. É a mesma ideia que sustenta o ganho percebido pelo cliente: seis perspectivas distintas sobre a mesma superfície encontram o que uma só não encontraria.

Esse redesenho acontece sobre um campo que amadureceu rápido. Desde os primeiros protótipos acadêmicos que demonstravam a viabilidade de LLMs na geração de payloads individuais [1] [2], até sistemas completos capazes de conduzir avaliações autônomas de ponta a ponta, a evolução tem sido de aceleração contínua tanto em capacidade ofensiva quanto em sofisticação metodológica.

É importante situar onde está o avanço. Em acurácia de detecção, a geração anterior já operava próxima do teto, e o espaço restante era estreito por definição. O salto da terceira geração está em outro lugar: na profundidade de encadeamento, que dobrou; na amplitude de cobertura, com a expansão significativa de Active Directory e a entrada de ambientes cloud e mobile; e em capacidades que simplesmente não existiam, como a correlação de CVEs em ciclo inferior a 24 horas e a geração de exploits a partir da análise de patches.

Este artigo descreve as três dimensões de avanço que definem a Yaga 3 Superintelligence:

1. Expansão da orquestração multi-modelo: de quatro para seis modelos de IA especializados, cada um atribuído a fases específicas do pipeline ofensivo onde sua arquitetura e treinamento oferecem vantagem comparativa. Os modelos específicos e a configuração do ensemble são detalhados no benchmark comparativo [11] e atualizados conforme novos modelos frontier são avaliados; este artigo descreve a arquitetura de orquestração e a lógica de especialização funcional.
2. Amplitude e profundidade estendidas de encadeamento: o Chain Engine v3 resolve cadeias de múltiplos estágios, cobrindo cenários completos de acesso inicial externo até comprometimento total de domínio em ambientes Active Directory, e cadeias de SSRF até execução remota de código com escalação de privilégios em aplicações web modernas.
3. Inteligência de ameaças em tempo quase-real: um módulo dedicado de CVE Intelligence correlaciona findings descobertos durante o engajamento com vulnerabilidades recém-divulgadas, advisories de fabricantes e exploits publicados, operando em ciclo de atualização inferior a 24 horas.

2. Evolução arquitetural: de quatro a seis modelos especializados

2.1 Por que especialização funcional

A arquitetura da Yaga parte de uma tese validada empiricamente: cada incremento no número de modelos orquestrados, quando acompanhado de especialização funcional adequada, produz ganhos não lineares em capacidade ofensiva. Essa propriedade emerge porque diferentes fases do pipeline de pentest demandam capacidades cognitivas distintas. Reconhecimento exige amplitude de associação, construção de exploits exige precisão sintática, encadeamento exige raciocínio causal profundo, e verificação exige ceticismo adversarial.

2.2 Arquitetura de orquestração multi-modelo

O harness da Yaga 3 gerencia seis modelos de IA em um ensemble heterogêneo onde cada modelo é atribuído a um ou mais papéis funcionais dentro do pipeline ofensivo. A atribuição não é estática: o orquestrador avalia a natureza de cada sub-tarefa em tempo de execução e roteia para o modelo com melhor performance demonstrada naquela classe de tarefa, conforme o benchmark contínuo interno.

TABELA I: Papéis funcionais do ensemble de seis modelos

A escolha de seis modelos reflete uma análise empírica da decomposição ótima do pipeline ofensivo. O benchmark interno demonstra que a adição de um Encadeador dedicado, no quinto modelo, produz o maior ganho isolado do redesenho, concentrado justamente nas cadeias de três ou mais estágios. A adição do sexto modelo, o Sintetizador dedicado, libera capacidade de raciocínio dos demais, que antes dividiam ciclos entre análise ofensiva e geração de relatórios, com efeito direto sobre o tempo total de engajamento.

2.3 Roteamento dinâmico e especialização contextual

O orquestrador da Yaga v3.0 implementa um mecanismo de roteamento dinâmico que, para cada sub-tarefa gerada durante o engajamento, avalia três critérios antes de atribuí-la a um modelo:

1. Afinidade funcional: correspondência entre a natureza da sub-tarefa e o papel funcional do modelo, classificada por um modelo leve de triagem que opera em menos de 50ms por decisão de roteamento.
2. Performance histórica: taxa de sucesso do modelo em sub-tarefas da mesma classe, medida continuamente no benchmark interno. Quando dois modelos têm afinidade similar, o roteador prioriza aquele com melhor performance recente.
3. Carga e latência: balanceamento para evitar gargalos quando múltiplas sub-tarefas são paralelizáveis. O orquestrador prioriza o throughput total do engajamento, não a otimalidade de cada sub-tarefa isolada.

Esse roteamento permite que a composição do ensemble evolua sem redesenho arquitetural: quando um novo modelo frontier é lançado, ele é avaliado no benchmark, atribuído aos papéis onde demonstra vantagem, e integrado ao ensemble. O harness é agnóstico ao provedor. O que importa é a capacidade funcional demonstrada, não o fabricante do modelo.

3. Ampliação da capacidade de raciocínio ofensivo

3.1 De raciocínio linear a raciocínio recursivo com backtracking

A limitação mais crítica de sistemas de pentest autônomo baseados em modelo único é a profundidade de raciocínio. Modelos de linguagem, por sua natureza autorregressiva, tendem a seguir o caminho de maior probabilidade token a token, o que produz raciocínio localmente coerente mas frequentemente míope em cadeias de ataque longas. Um pentester humano experiente, ao encontrar um bloqueio em um vetor de ataque, retrocede mentalmente, reavalia premissas e tenta caminhos alternativos, comportamento que modelos isolados reproduzem com dificuldade [5].

A Yaga implementa raciocínio recursivo com backtracking explícito, em três níveis:

Nível 1, exploração em árvore. Para cada objetivo do engajamento, o Estrategista gera uma árvore de ataque onde cada nó representa um sub-objetivo e cada aresta representa uma dependência ou pré-condição. A árvore é expandida em largura até a profundidade que o ambiente e o escopo do engajamento justificarem.

Nível 2, execução com checkpoint. O Explorador percorre a árvore em profundidade, executando cada sub-objetivo sequencialmente. A cada nó resolvido com sucesso, um checkpoint é registrado no Knowledge Graph. Quando um nó falha, seja por payload bloqueado por WAF, credencial inválida ou serviço inacessível, o mecanismo de backtracking é ativado.

Nível 3, backtracking inteligente. Diferente do backtracking clássico em busca em árvore, a Yaga não retrocede cegamente ao nó pai. O Encadeador analisa a causa raiz da falha e decide o ponto ótimo de retrocesso. Se um SQLi falhou porque a aplicação usa prepared statements, retroceder ao mesmo endpoint com um payload diferente é inútil: o backtracking salta para um nó alternativo da árvore.

Do ponto de vista de quem contrata o teste, esse mecanismo aparece como menos pausas desnecessárias. Uma limitação encontrada em um ponto do escopo, seja um controle que bloqueia o caminho, um serviço indisponível ou uma credencial que não avança, deixa de travar a avaliação inteira. A Yaga reconhece o bloqueio, registra a condição como evidência, e segue testando o restante do escopo pelos caminhos que continuam abertos. Na geração anterior, parte dessas situações consumia ciclos em tentativas repetidas no mesmo vetor.

Listagem 1: árvore de ataque com decisão de backtracking

3.2 Memória de engajamento hierárquica

O raciocínio profundo é impossível sem memória proporcional. A segunda geração operava com janela de contexto efetiva suficiente para engajamentos de complexidade média, mas insuficiente para cenários de encadeamento longo, onde o agente precisa manter simultaneamente o estado completo do Knowledge Graph, os outputs de reconhecimento e fingerprinting, os resultados de tentativas anteriores e a árvore de ataque em resolução.

A Yaga implementa memória de engajamento em três camadas:

1. Contexto imediato: janela de contexto do modelo ativo, utilizada para a sub-tarefa corrente. Tamanho variável conforme o modelo alocado.
2. Memória de sessão: Knowledge Graph completo do engajamento, persistido fora da janela de contexto e consultado sob demanda. O Encadeador injeta no contexto apenas os nós relevantes para a cadeia em resolução.
3. Memória de corpus: base de conhecimento acumulada de engajamentos anteriores, anonimizada, contendo padrões de ataque bem-sucedidos, fingerprints de tecnologias e heurísticas de bypass validadas. Consultada quando os caminhos padrão falham.

Essa hierarquia permite que o agente mantenha raciocínio coerente em engajamentos de alta complexidade e duração prolongada, sem degradação por saturação de contexto.

3.3 Raciocínio causal sobre dependências de exploração

O Encadeador implementa um modelo formal de raciocínio causal sobre dependências entre vulnerabilidades. Para cada par (v_i, v_j) no Knowledge Graph, o modelo avalia se existe uma relação causal explorável:

R(v_i, v_j) = { enables   se output de v_i satisfaz pré-condição de v_j
amplifies   se exploração de v_i aumenta impacto de v_j
requires   se v_j só é alcançável após v_i
independent   se não há relação causal explorável

A resolução de cadeias longas é formulada como busca em grafo dirigido acíclico, onde os nós são vulnerabilidades e as arestas são relações causais tipadas. O Encadeador busca o caminho de máximo impacto entre um nó de entrada, acessível externamente, e um nó objetivo definido pelo escopo do engajamento:

chain* = arg max_p∈paths(G) ∑_e∈p w(e) · impact(target(e))

sujeito a:   ∀(v_i, v_j) ∈ p : preconditions(v_j) ⊆ outputs(v_i) ∪ context

onde w(e) é a confiança estimada na relação causal e impact é a severidade contextualizada do nó destino, calculada pela metodologia de criticidade contextual da Yaga [10].

4. Encadeamento de exploração de amplitude estendida

4.1 Do encadeamento simples ao encadeamento profundo

O Chain Engine v3 amplia de forma substancial a profundidade de encadeamento em relação à geração anterior, resultado que reflete não apenas a adição de modelos, mas a reformulação do algoritmo de encadeamento e a existência de um Encadeador dedicado. A profundidade não é um número fixo: a Yaga estende a cadeia até onde o ambiente, o escopo autorizado e o contexto do alvo permitirem, e encerra quando o impacto está demonstrado.

O ganho se concentra onde a geração anterior atingia seu limite prático: nas cadeias mais longas, em que o modelo generalista responsável pelo encadeamento perdia coerência, confundindo pré-condições de estágios anteriores com requisitos do estágio corrente. O Encadeador dedicado, com raciocínio focado exclusivamente em resolução de dependências, mantém coerência ao longo de toda a cadeia. As taxas de resolução por faixa de profundidade estão publicadas no benchmark.

Vale registrar o que o aumento de profundidade significa na prática: cadeias longas, com muitos elos encadeados, são exatamente o tipo de caminho que um adversário real percorre e que uma avaliação pontual nunca reconstrói, porque cada elo isolado parece tolerável.

4.2 Cenário de referência: SSRF até execução de código com escalação

Para ilustrar a amplitude do encadeamento, descrevemos uma cadeia resolvida autonomamente pela Yaga em ambiente de validação controlado. A cadeia demonstra a capacidade de transitar entre camadas da aplicação, alcançar serviços internos, comprovar execução de código e evidenciar o caminho de escalação, em uma sequência contínua de raciocínio.

4.3 Cenário de referência: acesso inicial até comprometimento de domínio

O segundo cenário demonstra a capacidade do Chain Engine v3 em infraestrutura corporativa, onde a cadeia atravessa múltiplas máquinas, protocolos e domínios de autenticação.

Os dois cenários compartilham a mesma lógica de prova: a Yaga percorre a cadeia até o ponto em que o impacto está demonstrado, registra o que sustenta cada elo, e para. A evidência é o caminho comprovado, não a consumação do dano.

5. Motor de inteligência de CVEs em tempo quase-real

5.1 A janela entre a divulgação e a correção

Um dos desafios mais críticos em pentest é a velocidade com que novas vulnerabilidades são divulgadas e exploradas em ambientes reais. Em 2025, o tempo médio entre a publicação de um CVE e a primeira exploração observada em massa caiu para 15 dias [12], com casos de exploração em menos de 24 horas após a divulgação. Ferramentas que operam com bases de conhecimento estáticas, atualizadas semanalmente, mensalmente ou apenas entre releases, perdem janelas em que os ambientes avaliados estão vulneráveis a ameaças ativas mas a ferramenta não possui assinatura para detectá-las.

A Yaga introduz um módulo dedicado de CVE Intelligence que opera em ciclo contínuo, integrando informações de vulnerabilidades recém-divulgadas diretamente no pipeline ofensivo durante o engajamento.

5.2 Arquitetura do motor

Fase 1, ingestão e normalização. O motor ingere dados de múltiplas fontes em ciclo inferior a 24 horas: NVD, com CVEs publicadas, scoring CVSS, mapeamento CWE e referências; CISA KEV, com confirmação de exploração ativa em ambientes reais; FIRST EPSS, com a probabilidade estatística de exploração em janela de 30 dias; GitHub Security Advisories, para vulnerabilidades em dependências de código aberto; advisories de fabricantes; e bases de exploits, para detecção de PoCs publicados. Cada CVE é normalizada em uma estrutura canônica que inclui identificador, vetor CVSS, CWEs associados, produtos e versões afetados, status no KEV, score EPSS corrente, disponibilidade de exploit público e data de publicação.

Fase 2, correlação com os findings do engajamento. A contribuição diferencial do motor não é manter uma base atualizada, algo que qualquer ferramenta faz, mas a correlação semântica em tempo de engajamento. Quando o Reconhecedor identifica uma tecnologia ou versão específica no alvo, o motor consulta as CVEs que afetam aquele produto, prioriza pela combinação de EPSS, status no KEV e disponibilidade de exploit público, verifica se as pré-condições de exploração são satisfeitas pelo contexto observado, e injeta as CVEs priorizadas no Knowledge Graph como nós conectados ao nó da tecnologia identificada. Essa correlação transforma o fingerprinting, que em ferramentas tradicionais produz apenas uma lista de versões, em uma superfície de ataque expandida e priorizada por ameaça real.

Fase 3, geração dinâmica de exploits para CVEs recentes. Para CVEs com exploit público disponível, o Explorador adapta o PoC ao contexto específico do alvo. Para CVEs sem exploit público mas com descrição técnica suficiente, o Explorador analisa o diff do patch para identificar a causa raiz corrigida, reconstrói o caminho de execução vulnerável, e gera um exploit original para o contexto do alvo. Toda geração passa pelo Verificador antes de qualquer tentativa.

5.3 Impacto do motor no engajamento

A integração do motor produz efeito em quatro dimensões mensuráveis, todas acompanhadas no benchmark:

• Findings associados a CVEs recentes: cresce de forma expressiva a parcela de achados ligados a vulnerabilidades divulgadas no mês corrente, que antes dependiam do conhecimento estático dos modelos, limitado pela data de corte de treinamento.
• Exploits gerados a partir de patch: uma classe de achado que não existia na geração anterior passa a ser produzida de forma recorrente.
• Tempo de triagem por finding: cai, porque a priorização por EPSS e KEV chega pronta junto com o achado.
• Cobertura de CVEs do mês corrente: é a dimensão de maior salto, e a mais direta de explicar: sem o motor, a Yaga dependia do que os modelos sabiam; com o motor, as CVEs publicadas durante o próprio engajamento são avaliadas contra o alvo assim que a tecnologia correspondente é identificada.

Os valores medidos em cada dimensão são publicados no benchmark.

6. Capacidade técnica expandida

A Yaga 3 amplia a cobertura de superfícies de ataque em relação à versão anterior, refletindo tanto a capacidade expandida de raciocínio quanto a especialização funcional dos seis modelos.

6.1 Aplicações web: aprofundamento

A cobertura web, já detalhada em [9], recebe aprimoramentos em três áreas:

• Server-Side Template Injection: motor de detecção com geração de payloads polimórficos para 14 template engines (Jinja2, Twig, Freemarker, Velocity, Thymeleaf, Pebble, Mako, Smarty, Blade, ERB, Slim, Mustache, Handlebars, EJS), adaptados aos filtros e sandboxes identificados.
• Desserialização insegura: análise de gadget chains para Java, PHP, Python, .NET e Ruby. O Encadeador identifica quando a desserialização é alcançável via cadeia e seleciona a gadget chain correspondente à versão do runtime detectado.
• GraphQL: introspecção, batching, abuso de profundidade de query, detecção de DoS por alias e exploração de mutations não autorizadas, com cobertura adicionada para subscriptions e GraphQL sobre WebSocket.

6.2 Infraestrutura e Active Directory: a maior expansão

• Kerberos: Kerberoasting, AS-REP Roasting, detecção de Golden e Silver Ticket, delegação não restrita e constrained delegation, Resource-Based Constrained Delegation.
• NTLM: ataques de relay para LDAP, SMB e HTTP, e coerção de autenticação.
• LDAP: enumeração avançada de ACLs, identificação de caminhos até Domain Admin por permissões mal configuradas, e Shadow Credentials.
• Certificate Services (AD CS): ESC1 a ESC13, abuso de PKINIT e relay para a autoridade certificadora.
• Azure AD e Entra ID: enumeração de roles, abuso de Application Permissions, manipulação de tokens e ataques cross-tenant.

6.3 Cloud: cobertura nova

• AWS: enumeração de políticas IAM, configurações indevidas de buckets, injeção em funções serverless, SSRF para o endpoint de metadata e escalação via cadeias de AssumeRole.
• Azure: abuso de Managed Identity, extração de Key Vault e configurações indevidas de cluster gerenciado.
• GCP: vazamento de chaves de service account, exposição de metadata em cluster gerenciado e escalação por binding de IAM.

6.4 Demais superfícies

A ampliação de cobertura alcança também as superfícies que compõem a maior parte dos engajamentos reais:

• APIs: REST e GraphQL, com análise de contrato, versionamento exposto, objetos retornados em excesso e autorização a nível de objeto e de função.
• Redes e ambientes internos: enumeração de serviços, protocolos legados, compartilhamentos expostos e movimentação entre segmentos, aproveitando o mesmo raciocínio causal usado nas cadeias de aplicação.
• Aplicações móveis: análise de binário e de tráfego, armazenamento local inseguro, chaves embarcadas, validação de certificado e a superfície de API que o aplicativo consome, que é onde costuma estar o impacto real.
• Fluxos autenticados complexos: autenticação em múltiplas etapas, MFA, troca de contexto entre perfis e sessões de longa duração, mantidos de forma estável ao longo de todo o engajamento graças à memória de sessão descrita na seção 3.2.

6.5 Evidência e reprodutibilidade

Uma vulnerabilidade só é útil para quem precisa corrigi-la se vier acompanhada do caminho exato que a comprova. O Sintetizador dedicado, liberado das tarefas de análise ofensiva, passa a produzir provas de conceito mais completas do que na geração anterior: cada achado é entregue com os parâmetros envolvidos, as requisições e respostas relevantes, e as condições necessárias para reproduzir o comportamento.

Isso atende a três leitores ao mesmo tempo. O time técnico recebe o passo a passo para reproduzir e validar a correção. O time de desenvolvimento recebe o ponto exato onde a condição se manifesta. E, em processos de auditoria ou de certificação, o pacote serve como comprovação documental, porque descreve não apenas que a vulnerabilidade existia, mas sob quais condições ela era explorável e o que mudou depois da correção. Para cadeias, acompanha ainda o diagrama da sequência e a análise de impacto acumulado, permitindo priorizar o elo cuja correção quebra mais caminhos de uma vez.

7. Garantias de segurança operacional na arquitetura expandida

A expansão de quatro para seis modelos introduz uma superfície de risco adicional: mais modelos significa mais pontos onde um desvio de escopo ou uma ação indevida pode originar-se. A Yaga aborda esse risco com duas garantias arquiteturais que se somam ao sistema de dez guardrails formalizados na versão anterior [8].

7.1 Verificação cruzada entre modelos

Toda ação ofensiva gerada por qualquer modelo do ensemble, seja exploit, payload, comando de rede ou tentativa de escalação, é submetida ao Verificador antes da execução. O Verificador opera com mandato adversarial: seu objetivo é encontrar razões para bloquear a ação, não para aprová-la. Esse desenho elimina o viés de confirmação que ocorre quando o mesmo modelo que gera a ação também a valida.

TABELA II: Tratamento por tipo de ação no Verificador

7.2 Consenso multi-modelo para ações de alto impacto

Para ações classificadas como de alto impacto, como exploits de kernel, ações que podem causar indisponibilidade, ou escalação para contas de serviço e administrativas, a Yaga v3.0 implementa um mecanismo de consenso em que múltiplos modelos devem concordar de forma independente antes da execução:

Execute(a) = { allow   se ∑_i=1ⁿ 𝟙[Model_i(a) = safe] ≥ ⌈n/2⌉ + 1
escalate   caso contrário

onde n é o número de modelos consultados, com mínimo de três para ações de alto impacto. A ação só prossegue com maioria qualificada; caso contrário, é escalada para revisão do sistema de guardrails completo. A evolução do SEPS Score, a métrica de trade-off entre segurança operacional e capacidade ofensiva formalizada em [8], é acompanhada a cada versão e publicada no benchmark: na v3.0, a expansão de capacidade ofensiva ocorreu sem degradação de segurança, com melhoria simultânea nas duas dimensões.

8. Trabalhos relacionados e posicionamento

A aplicação de Large Language Models em segurança ofensiva tem sido objeto de investigação acadêmica crescente. Fang et al. demonstraram que modelos frontier podem explorar vulnerabilidades conhecidas com taxa de sucesso significativa quando equipados com ferramentas adequadas [1]. Happe e Cito exploraram a viabilidade de LLMs em cenários de pentest, evidenciando tanto as capacidades quanto as limitações de modelos isolados [2]. Deng et al. propuseram um framework que utiliza LLMs como assistentes interativos para pentesters humanos, sem autonomia completa [3].

A distinção fundamental da Yaga 3 Superintelligence em relação a esses trabalhos é de natureza arquitetural, não apenas de performance. Enquanto sistemas comparáveis operam com modelo único assistido por ferramentas, a Yaga opera como ensemble multi-modelo com especialização funcional, Knowledge Graph persistente e Chain Engine capaz de raciocínio causal profundo. Essa diferença se traduz em capacidade: encadeamento de múltiplos estágios, resolução autônoma de cadeias que vão do acesso inicial ao comprometimento de domínio, e geração de exploits a partir da análise de patches.

Yang et al. propuseram benchmarks padronizados para avaliação de agentes de segurança [4], contribuição que adotamos parcialmente no desenho do YagaBench. A diferença é que o YagaBench inclui cenários de encadeamento multi-estágio e cenários completos de Active Directory, dimensões não cobertas por benchmarks existentes.

O framework ARMA, proposto pela equipe de pesquisa da HackerSec [7], fornece a base metodológica para a classificação de risco que a Yaga utiliza na priorização de findings e na comunicação de impacto para stakeholders de negócio. A metodologia de criticidade contextual da Yaga, detalhada em [10], é a instanciação operacional do ARMA especificamente para o eixo de severidade de vulnerabilidade.

9. Fronteiras atuais e próximos passos

Um agente ofensivo maduro se define tanto pelo que executa quanto pela clareza com que declara onde estão suas fronteiras. Esta seção registra os limites da versão atual e a direção em que a arquitetura avança.

Confiança explícita em cadeias longas. A confiança de um caminho completo é o produto da confiança de cada elo, e portanto nunca é maior que a do elo mais frágil. A Yaga não dissolve isso em um veredito único: reporta a confiança acumulada de cada cadeia ao lado da evidência de cada estágio, para que o especialista pondere o peso daquela cadeia no contexto do engajamento. É uma escolha deliberada de transparência, e é também a razão de o Verificador operar com mandato adversarial e de ações de alto impacto exigirem consenso entre modelos.

Evolução acompanhando a fronteira dos modelos. A capacidade do ensemble acompanha a dos modelos que o compõem, e a arquitetura foi desenhada para transformar isso em vantagem. O roteamento dinâmico permite incorporar um novo modelo frontier assim que ele demonstra superioridade em algum papel, sem redesenho do harness. Cada avanço do campo chega ao cliente no ciclo seguinte de avaliação, e não apenas na próxima versão maior.

Fontes de inteligência de ameaças. O ciclo inferior a 24 horas cobre as fontes monitoradas, que concentram a grande maioria das divulgações relevantes. Vulnerabilidades ainda sem identificador público seguem dependendo do raciocínio ofensivo do ensemble, que é justamente onde a especialização por papel mais rende: descobrir o que ainda não foi catalogado é trabalho de raciocínio, não de consulta a base.

Próxima fronteira: ambientes OT e ICS. A Yaga opera hoje em ambientes de TI convencionais, cobrindo aplicações web, APIs, redes, ambientes internos, aplicações móveis e nuvem. A extensão para tecnologia operacional é a prioridade declarada da próxima geração, ao lado do raciocínio sobre segurança de cadeia de suprimentos.

Delimitação de escopo. Engenharia social por canais digitais é coberta dentro do pipeline de acesso inicial. Avaliações presenciais e componentes de segurança física permanecem fora do escopo do agente, por desenho, e continuam sendo conduzidas por especialistas quando o engajamento as exige.

10. Conclusão

A Yaga 3 Superintelligence representa a convergência de três avanços que, em conjunto, redefinem o que um agente autônomo de pentest entrega: a orquestração de seis modelos de IA especializados com roteamento dinâmico, um motor de encadeamento capaz de resolver cadeias de múltiplos estágios, e um módulo de inteligência de ameaças que integra CVEs recém-divulgadas diretamente no pipeline ofensivo.

Vale ser preciso sobre onde está o salto. Em acurácia de detecção, a geração anterior já operava muito próxima do teto, e o espaço restante era estreito; os ganhos existem, mas são marginais por construção. O avanço real da terceira geração está na profundidade de encadeamento, que dobrou, na amplitude de cobertura, com a maior expansão já feita em Active Directory e a entrada de ambientes cloud, e em capacidades que antes simplesmente não existiam, como a correlação de CVEs em ciclo inferior a 24 horas e a geração de exploits a partir de patches.

A tese validada empiricamente é que inteligência superior em segurança ofensiva não é propriedade de um modelo mais potente, mas propriedade emergente de uma arquitetura que orquestra múltiplos modelos com especialização funcional, conectados por um Knowledge Graph que persiste e conecta inteligência ao longo de todo o engajamento. Nos benchmarks, cada modelo isolado resolve menos da metade dos cenários; o ensemble orquestrado resolve a quase totalidade. Os números por modelo e por modo de teste estão em hackersec.com/evals.

Os resultados demonstram também que segurança operacional e capacidade ofensiva não são objetivos conflitantes quando a arquitetura é projetada para tratá-los como complementares. A expansão de capacidade na v3.0 ocorreu com melhoria simultânea nas métricas de segurança, e a lógica de prova permanece a mesma das gerações anteriores: a Yaga percorre a cadeia até o ponto em que o impacto está demonstrado, registra o que sustenta cada elo, e para.

A próxima fronteira é a extensão de cobertura para ambientes OT e ICS, a integração de raciocínio sobre segurança de supply chain, e a avaliação contínua de modelos frontier emergentes para o ensemble. O ritmo de evolução dos modelos de linguagem sugere que as capacidades individuais continuarão a melhorar; a contribuição da Yaga é garantir que esse progresso se traduza em capacidade ofensiva mensurável, segura e metodologicamente fundamentada.

Referências