Yaga 3 SuperIntelligence

Six superintelligence models working complementarily at every stage of the pentest

Yaga 3 Superintelligence is the new generation of HackerSec's pentest agent. The main evolution is in its analytical capacity: where the previous generation orchestrated four artificial intelligence models, Yaga 3 combines six, working complementarily across the different stages of the pentest. In practice, this broadens the diversity of reasoning, reduces blind spots, and allows the same surface to be analyzed from different perspectives.

This article details what sustains that gain: the functional specialization of each model by phase of the offensive pipeline, the Chain Engine v3, which resolves multi-stage chains from initial access to domain compromise, and the CVE Intelligence engine, which integrates newly disclosed vulnerabilities within a cycle of under 24 hours, including when no public exploit is yet available. The quantitative results of YagaBench are published and continuously updated at hackersec.com/evals.

1. Introduction

Yaga reached this point across three distinct generations. The first (v1.x) demonstrated the viability of an autonomous agent conducting complete pentests with two AI models in basic orchestration. The second (v2.x) introduced the Knowledge Graph, the Chain Engine for vulnerability chaining, the system of mathematically formalized guardrails, and the expansion to four orchestrated models, establishing itself as a reference in the domain [8] [9].

The third generation reflects the architectural thesis that motivated the redesign: superior intelligence in offensive security does not emerge from a more powerful model operating in isolation, but from the specialized orchestration of multiple models with complementary capabilities, fed by near-real-time threat intelligence, and connected by a reasoning engine capable of building exploitation chains of unprecedented depth and breadth in autonomous systems. It is the same idea that sustains the gain the client perceives: six distinct perspectives on the same surface find what one alone would not.

This redesign happens on top of a field that matured quickly. From the first academic prototypes demonstrating the viability of LLMs in generating individual payloads [1] [2], to complete systems capable of conducting end-to-end autonomous assessments, the evolution has been one of continuous acceleration in both offensive capability and methodological sophistication.

It is important to situate where the advance lies. In detection accuracy, the previous generation already operated close to the ceiling, and the remaining room was narrow by definition. The leap of the third generation is elsewhere: in chaining depth, which doubled; in coverage breadth, with the significant expansion of Active Directory and the entry of cloud and mobile environments; and in capabilities that simply did not exist, such as CVE correlation within a cycle of under 24 hours and the generation of exploits from patch analysis.

This article describes the three dimensions of advance that define Yaga 3 Superintelligence:

1. Expansion of multi-model orchestration: from four to six specialized AI models, each assigned to specific phases of the offensive pipeline where its architecture and training offer comparative advantage. The specific models and the ensemble configuration are detailed in the comparative benchmark [11] and updated as new frontier models are evaluated; this article describes the orchestration architecture and the logic of functional specialization.
2. Extended breadth and depth of chaining: the Chain Engine v3 resolves multi-stage chains, covering complete scenarios from external initial access to full domain compromise in Active Directory environments, and chains from SSRF to remote code execution with privilege escalation in modern web applications.
3. Near-real-time threat intelligence: a dedicated CVE Intelligence module correlates findings discovered during the engagement with newly disclosed vulnerabilities, vendor advisories and published exploits, operating on an update cycle of under 24 hours.

2. Architectural evolution: from four to six specialized models

2.1 Why functional specialization

Yaga's architecture starts from an empirically validated thesis: each increment in the number of orchestrated models, when accompanied by adequate functional specialization, produces non-linear gains in offensive capability. That property emerges because different phases of the pentest pipeline demand distinct cognitive capabilities. Reconnaissance demands breadth of association, exploit construction demands syntactic precision, chaining demands deep causal reasoning, and verification demands adversarial skepticism.

2.2 Multi-model orchestration architecture

Yaga 3's harness manages six AI models in a heterogeneous ensemble where each model is assigned one or more functional roles within the offensive pipeline. The assignment is not static: the orchestrator evaluates the nature of each sub-task at runtime and routes it to the model with the best demonstrated performance in that class of task, according to the continuous internal benchmark.

TABLE I: Functional roles of the six-model ensemble

The choice of six models reflects an empirical analysis of the optimal decomposition of the offensive pipeline. The internal benchmark shows that adding a dedicated Chainer, as the fifth model, produces the largest single gain of the redesign, concentrated precisely in chains of three or more stages. Adding the sixth model, the dedicated Synthesizer, frees reasoning capacity in the others, which previously split cycles between offensive analysis and report generation, with a direct effect on total engagement time.

2.3 Dynamic routing and contextual specialization

Yaga v3.0's orchestrator implements a dynamic routing mechanism that, for each sub-task generated during the engagement, evaluates three criteria before assigning it to a model:

1. Functional affinity: correspondence between the nature of the sub-task and the model's functional role, classified by a lightweight triage model that operates in under 50ms per routing decision.
2. Historical performance: the model's success rate on sub-tasks of the same class, measured continuously in the internal benchmark. When two models have similar affinity, the router prioritizes the one with better recent performance.
3. Load and latency: balancing to avoid bottlenecks when multiple sub-tasks are parallelizable. The orchestrator prioritizes total engagement throughput, not the optimality of each isolated sub-task.

This routing allows the ensemble composition to evolve without architectural redesign: when a new frontier model is released, it is evaluated in the benchmark, assigned to the roles where it demonstrates advantage, and integrated into the ensemble. The harness is provider-agnostic. What matters is demonstrated functional capability, not the model's manufacturer.

3. Expanding offensive reasoning capability

3.1 From linear reasoning to recursive reasoning with backtracking

The most critical limitation of single-model autonomous pentest systems is reasoning depth. Language models, by their autoregressive nature, tend to follow the highest-probability path token by token, which produces locally coherent but frequently myopic reasoning across long attack chains. An experienced human pentester, upon hitting a block on an attack vector, mentally backtracks, reassesses premises and tries alternative paths, behavior that isolated models reproduce with difficulty [5].

Yaga implements recursive reasoning with explicit backtracking, at three levels:

Level 1, tree exploration. For each engagement objective, the Strategist generates an attack tree where each node represents a sub-goal and each edge represents a dependency or precondition. The tree is expanded in breadth to the depth that the environment and the engagement scope justify.

Level 2, execution with checkpoints. The Exploiter traverses the tree in depth, executing each sub-goal sequentially. At each node resolved successfully, a checkpoint is recorded in the Knowledge Graph. When a node fails, whether due to a payload blocked by a WAF, an invalid credential or an unreachable service, the backtracking mechanism is activated.

Level 3, intelligent backtracking. Unlike classic backtracking in tree search, Yaga does not blindly retreat to the parent node. The Chainer analyzes the root cause of the failure and decides the optimal point of retreat. If a SQLi failed because the application uses prepared statements, retreating to the same endpoint with a different payload is pointless: the backtracking jumps to an alternative node in the tree.

From the point of view of whoever commissions the test, this mechanism appears as fewer unnecessary pauses. A limitation encountered at one point of the scope, whether a control that blocks the path, an unavailable service or a credential that goes no further, stops halting the entire assessment. Yaga recognizes the block, records the condition as evidence, and keeps testing the rest of the scope along the paths that remain open. In the previous generation, part of these situations consumed cycles in repeated attempts on the same vector.

Listing 1: attack tree with a backtracking decision

3.2 Hierarchical engagement memory

Deep reasoning is impossible without proportional memory. The second generation operated with an effective context window sufficient for engagements of medium complexity, but insufficient for long-chaining scenarios, where the agent must simultaneously hold the complete state of the Knowledge Graph, the reconnaissance and fingerprinting outputs, the results of previous attempts and the attack tree being resolved.

Yaga implements engagement memory in three layers:

1. Immediate context: the context window of the active model, used for the current sub-task. Size varies with the allocated model.
2. Session memory: the complete Knowledge Graph of the engagement, persisted outside the context window and queried on demand. The Chainer injects into context only the nodes relevant to the chain being resolved.
3. Corpus memory: the accumulated knowledge base from previous engagements, anonymized, containing successful attack patterns, technology fingerprints and validated bypass heuristics. Queried when the standard paths fail.

This hierarchy allows the agent to maintain coherent reasoning across engagements of high complexity and extended duration, without degradation from context saturation.

3.3 Causal reasoning over exploitation dependencies

The Chainer implements a formal model of causal reasoning over dependencies between vulnerabilities. For each pair (v_i, v_j) in the Knowledge Graph, the model evaluates whether an exploitable causal relationship exists:

R(v_i, v_j) = { enables   if the output of v_i satisfies a precondition of v_j
amplifies   if exploiting v_i increases the impact of v_j
requires   if v_j is only reachable after v_i
independent   if there is no exploitable causal relationship

The resolution of long chains is formulated as a search over a directed acyclic graph, where nodes are vulnerabilities and edges are typed causal relationships. The Chainer searches for the maximum-impact path between an entry node, externally accessible, and a goal node defined by the engagement scope:

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

subject to:   ∀(v_i, v_j) ∈ p : preconditions(v_j) ⊆ outputs(v_i) ∪ context

where w(e) is the estimated confidence in the causal relationship and impact is the contextualized severity of the target node, computed by Yaga's contextual criticality methodology [10].

4. Exploitation chaining of extended breadth

4.1 From simple chaining to deep chaining

The Chain Engine v3 substantially extends chaining depth relative to the previous generation, a result that reflects not only the addition of models but the reformulation of the chaining algorithm and the existence of a dedicated Chainer. Depth is not a fixed number: Yaga extends the chain as far as the environment, the authorized scope and the target context allow, and stops when the impact is demonstrated.

The gain concentrates where the previous generation hit its practical limit: on the longest chains, where the generalist model responsible for chaining lost coherence, confusing preconditions from earlier stages with requirements of the current stage. The dedicated Chainer, with reasoning focused exclusively on dependency resolution, maintains coherence throughout the chain. Resolution rates by depth range are published in the benchmark.

It is worth recording what the increase in depth means in practice: long chains, with many linked steps, are exactly the kind of path a real adversary walks and that a point-in-time assessment never reconstructs, because each link in isolation looks tolerable.

4.2 Reference scenario: SSRF to code execution with escalation

To illustrate the breadth of chaining, we describe a chain resolved autonomously by Yaga in a controlled validation environment. The chain demonstrates the capacity to move between application layers, reach internal services, prove code execution and evidence the escalation path, in a continuous sequence of reasoning.

4.3 Reference scenario: initial access to domain compromise

The second scenario demonstrates the Chain Engine v3's capability in corporate infrastructure, where the chain crosses multiple machines, protocols and authentication domains.

Both scenarios share the same logic of proof: Yaga walks the chain to the point where the impact is demonstrated, records what sustains each link, and stops. The evidence is the proven path, not the consummation of the damage.

5. Near-real-time CVE intelligence engine

5.1 The window between disclosure and remediation

One of the most critical challenges in pentesting is the speed with which new vulnerabilities are disclosed and exploited in real environments. In 2025, the average time between the publication of a CVE and the first mass exploitation observed fell to 15 days [12], with cases of exploitation in under 24 hours after disclosure. Tools that operate on static knowledge bases, updated weekly, monthly or only between releases, miss windows in which the assessed environments are vulnerable to active threats but the tool has no signature to detect them.

Yaga introduces a dedicated CVE Intelligence module that operates on a continuous cycle, integrating information on newly disclosed vulnerabilities directly into the offensive pipeline during the engagement.

5.2 Engine architecture

Phase 1, ingestion and normalization. The engine ingests data from multiple sources on a cycle of under 24 hours: NVD, with published CVEs, CVSS scoring, CWE mapping and references; CISA KEV, with confirmation of active exploitation in real environments; FIRST EPSS, with the statistical probability of exploitation in a 30-day window; GitHub Security Advisories, for vulnerabilities in open-source dependencies; vendor advisories; and exploit databases, for detection of published PoCs. Each CVE is normalized into a canonical structure that includes identifier, CVSS vector, associated CWEs, affected products and versions, KEV status, current EPSS score, availability of a public exploit and publication date.

Phase 2, correlation with engagement findings. The engine's differential contribution is not keeping an updated database, something any tool does, but semantic correlation at engagement time. When the Reconnoiterer identifies a specific technology or version on the target, the engine queries the CVEs affecting that product, prioritizes by the combination of EPSS, KEV status and availability of a public exploit, verifies whether the exploitation preconditions are satisfied by the observed context, and injects the prioritized CVEs into the Knowledge Graph as nodes connected to the identified technology node. That correlation transforms fingerprinting, which in traditional tools produces only a list of versions, into an expanded attack surface prioritized by real threat.

Phase 3, dynamic exploit generation for recent CVEs. For CVEs with a public exploit available, the Exploiter adapts the PoC to the specific context of the target. For CVEs without a public exploit but with sufficient technical description, the Exploiter analyzes the patch diff to identify the corrected root cause, reconstructs the vulnerable execution path, and generates an original exploit for the target's context. Every generation passes through the Verifier before any attempt.

5.3 Impact of the engine on the engagement

Integrating the engine produces effects across four measurable dimensions, all tracked in the benchmark:

• Findings associated with recent CVEs: the share of findings tied to vulnerabilities disclosed in the current month grows substantially, where previously they depended on the models' static knowledge, limited by the training cutoff date.
• Exploits generated from a patch: a class of finding that did not exist in the previous generation starts being produced recurrently.
• Triage time per finding: falls, because prioritization by EPSS and KEV arrives ready alongside the finding.
• Coverage of current-month CVEs: the dimension with the largest leap, and the most direct to explain: without the engine, Yaga depended on what the models knew; with the engine, CVEs published during the engagement itself are assessed against the target as soon as the corresponding technology is identified.

The values measured in each dimension are published in the benchmark.

6. Expanded technical capability

Yaga 3 broadens attack surface coverage relative to the previous version, reflecting both the expanded reasoning capacity and the functional specialization of the six models.

6.1 Web applications: going deeper

Web coverage, already detailed in [9], receives improvements in three areas:

• Server-Side Template Injection: detection engine with polymorphic payload generation for 14 template engines (Jinja2, Twig, Freemarker, Velocity, Thymeleaf, Pebble, Mako, Smarty, Blade, ERB, Slim, Mustache, Handlebars, EJS), adapted to the filters and sandboxes identified.
• Insecure deserialization: gadget chain analysis for Java, PHP, Python, .NET and Ruby. The Chainer identifies when deserialization is reachable through a chain and selects the gadget chain matching the detected runtime version.
• GraphQL: introspection, batching, query depth abuse, alias-based DoS detection and exploitation of unauthorized mutations, with coverage added for subscriptions and GraphQL over WebSocket.

6.2 Infrastructure and Active Directory: the largest expansion

• Kerberos: Kerberoasting, AS-REP Roasting, Golden and Silver Ticket detection, unconstrained and constrained delegation, Resource-Based Constrained Delegation.
• NTLM: relay attacks to LDAP, SMB and HTTP, and authentication coercion.
• LDAP: advanced ACL enumeration, identification of paths to Domain Admin through misconfigured permissions, and Shadow Credentials.
• Certificate Services (AD CS): ESC1 through ESC13, PKINIT abuse and relay to the certificate authority.
• Azure AD and Entra ID: role enumeration, Application Permissions abuse, token manipulation and cross-tenant attacks.

6.3 Cloud: new coverage

• AWS: IAM policy enumeration, bucket misconfigurations, injection in serverless functions, SSRF to the metadata endpoint and escalation via AssumeRole chains.
• Azure: Managed Identity abuse, Key Vault extraction and managed cluster misconfigurations.
• GCP: service account key leakage, metadata exposure in managed clusters and escalation through IAM bindings.

6.4 Other surfaces

The coverage expansion also reaches the surfaces that make up most real engagements:

• APIs: REST and GraphQL, with contract analysis, exposed versioning, objects returned in excess, and object-level and function-level authorization.
• Networks and internal environments: service enumeration, legacy protocols, exposed shares and movement between segments, leveraging the same causal reasoning used in application chains.
• Mobile applications: binary and traffic analysis, insecure local storage, embedded keys, certificate validation and the API surface the application consumes, which is where the real impact usually sits.
• Complex authenticated flows: multi-step authentication, MFA, context switching between profiles and long-lived sessions, kept stable throughout the engagement thanks to the session memory described in section 3.2.

6.5 Evidence and reproducibility

A vulnerability is only useful to whoever has to fix it if it comes with the exact path that proves it. The dedicated Synthesizer, freed from offensive analysis tasks, produces more complete proofs of concept than the previous generation: each finding is delivered with the parameters involved, the relevant requests and responses, and the conditions required to reproduce the behavior.

This serves three readers at once. The technical team receives the step-by-step to reproduce and validate the fix. The development team receives the exact point where the condition manifests. And in audit or certification processes, the package works as documentary proof, because it describes not only that the vulnerability existed, but under which conditions it was exploitable and what changed after remediation. For chains, it also includes the sequence diagram and the cumulative impact analysis, allowing prioritization of the link whose correction breaks the most paths at once.

7. Operational safety guarantees in the expanded architecture

Expanding from four to six models introduces an additional risk surface: more models means more points where a scope deviation or an improper action could originate. Yaga addresses that risk with two architectural guarantees that add to the system of ten guardrails formalized in the previous version [8].

7.1 Cross-verification between models

Every offensive action generated by any model in the ensemble, whether an exploit, a payload, a network command or an escalation attempt, is submitted to the Verifier before execution. The Verifier operates with an adversarial mandate: its objective is to find reasons to block the action, not to approve it. This design eliminates the confirmation bias that occurs when the same model that generates the action also validates it.

TABLE II: Treatment by action type in the Verifier

7.2 Multi-model consensus for high-impact actions

For actions classified as high impact, such as kernel exploits, actions that may cause unavailability, or escalation to service and administrative accounts, Yaga v3.0 implements a consensus mechanism in which multiple models must agree independently before execution:

Execute(a) = { allow   if ∑_i=1ⁿ 𝟙[Model_i(a) = safe] ≥ ⌈n/2⌉ + 1
escalate   otherwise

where n is the number of models consulted, with a minimum of three for high-impact actions. The action only proceeds with a qualified majority; otherwise it is escalated for review by the full guardrail system. The evolution of the SEPS Score, the metric of trade-off between operational safety and offensive capability formalized in [8], is tracked at each version and published in the benchmark: in v3.0, the expansion of offensive capability occurred without degradation of safety, with simultaneous improvement in both dimensions.

8. Related work and positioning

The application of Large Language Models in offensive security has been the object of growing academic investigation. Fang et al. demonstrated that frontier models can exploit known vulnerabilities with a significant success rate when equipped with adequate tooling [1]. Happe and Cito explored the viability of LLMs in pentest scenarios, evidencing both the capabilities and the limitations of isolated models [2]. Deng et al. proposed a framework that uses LLMs as interactive assistants for human pentesters, without full autonomy [3].

The fundamental distinction of Yaga 3 Superintelligence relative to these works is architectural in nature, not merely one of performance. While comparable systems operate with a single model assisted by tools, Yaga operates as a multi-model ensemble with functional specialization, a persistent Knowledge Graph and a Chain Engine capable of deep causal reasoning. That difference translates into capability: multi-stage chaining, autonomous resolution of chains that run from initial access to domain compromise, and generation of exploits from patch analysis.

Yang et al. proposed standardized benchmarks for evaluating security agents [4], a contribution we partially adopted in the design of YagaBench. The difference is that YagaBench includes multi-stage chaining scenarios and complete Active Directory scenarios, dimensions not covered by existing benchmarks.

The ARMA framework, proposed by HackerSec's research team [7], provides the methodological basis for the risk classification Yaga uses in prioritizing findings and communicating impact to business stakeholders. Yaga's contextual criticality methodology, detailed in [10], is the operational instantiation of ARMA specifically for the vulnerability severity axis.

9. Current frontiers and next steps

A mature offensive agent is defined as much by what it executes as by the clarity with which it declares where its frontiers lie. This section records the limits of the current version and the direction in which the architecture advances.

Explicit confidence in long chains. The confidence of a complete path is the product of the confidence of each link, and therefore is never greater than that of the weakest link. Yaga does not dissolve this into a single verdict: it reports the accumulated confidence of each chain alongside the evidence for each stage, so the specialist can weigh that chain in the context of the engagement. It is a deliberate choice of transparency, and it is also the reason the Verifier operates with an adversarial mandate and high-impact actions require consensus between models.

Evolving with the frontier of models. The ensemble's capability tracks that of the models composing it, and the architecture was designed to turn this into an advantage. Dynamic routing allows a new frontier model to be incorporated as soon as it demonstrates superiority in some role, without redesigning the harness. Each advance in the field reaches the client in the next assessment cycle, not only in the next major version.

Threat intelligence sources. The cycle of under 24 hours covers the monitored sources, which concentrate the vast majority of relevant disclosures. Vulnerabilities still without a public identifier continue to depend on the ensemble's offensive reasoning, which is precisely where specialization by role pays off most: discovering what has not yet been cataloged is reasoning work, not database lookup.

Next frontier: OT and ICS environments. Yaga operates today in conventional IT environments, covering web applications, APIs, networks, internal environments, mobile applications and cloud. The extension to operational technology is the declared priority of the next generation, alongside reasoning about supply chain security.

Scope delimitation. Social engineering through digital channels is covered within the initial access pipeline. On-site assessments and physical security components remain outside the agent's scope, by design, and continue to be conducted by specialists when the engagement requires them.

10. Conclusion

Yaga 3 Superintelligence represents the convergence of three advances that, together, redefine what an autonomous pentest agent delivers: the orchestration of six specialized AI models with dynamic routing, a chaining engine capable of resolving multi-stage chains, and a threat intelligence module that integrates newly disclosed CVEs directly into the offensive pipeline.

It is worth being precise about where the leap is. In detection accuracy, the previous generation already operated very close to the ceiling, and the remaining room was narrow; the gains exist, but they are marginal by construction. The real advance of the third generation is in chaining depth, which doubled, in coverage breadth, with the largest expansion ever made in Active Directory and the entry of cloud environments, and in capabilities that simply did not exist before, such as CVE correlation within a cycle of under 24 hours and the generation of exploits from patches.

The empirically validated thesis is that superior intelligence in offensive security is not a property of a more powerful model, but an emergent property of an architecture that orchestrates multiple models with functional specialization, connected by a Knowledge Graph that persists and links intelligence throughout the engagement. In the benchmarks, each isolated model solves less than half of the scenarios; the orchestrated ensemble solves nearly all of them. The figures per model and per test mode are at hackersec.com/evals.

The results also demonstrate that operational safety and offensive capability are not conflicting objectives when the architecture is designed to treat them as complementary. The expansion of capability in v3.0 occurred with simultaneous improvement in the safety metrics, and the logic of proof remains the same as in previous generations: Yaga walks the chain to the point where the impact is demonstrated, records what sustains each link, and stops.

The next frontier is extending coverage to OT and ICS environments, integrating reasoning about supply chain security, and continuously evaluating emerging frontier models for the ensemble. The pace of evolution of language models suggests that individual capabilities will keep improving; Yaga's contribution is ensuring that this progress translates into offensive capability that is measurable, safe and methodologically grounded.

References