Introducing dfs-large1: A New Frontier for Cybersecurity

Introduction

dfs-large1 is now in preview within the depthfirst platform. It is our most capable model to date, designed for vulnerability discovery and validation across large enterprise repositories. Built on GLM 5.2, it was post-trained inside depthfirst’s security agent harness using our RL stack, in partnership with Fireworks AI to scale training and inference.

dfs-large1 has shown consistent gains throughout our ongoing RL climb on long-horizon tasks that combine repository-level context, tool use, and executable verification. Performance continues to improve, with no clear sign of plateauing. Across our evaluations, dfs-large1 achieves best-in-class performance and establishes a new Pareto frontier for our production workload.

depthfirst-bench

Score

Task price

Note: Mythos and GPT-5.6 Cyber are omitted from this comparison because we did not have access to either model during evaluation.

To measure progress, we constructed depthfirst-bench to reflect the complexity of real-world security audits. Tasks are sourced from vulnerabilities in large repositories, where the evidence needed to establish a finding may be distributed across multiple components or repositories. Individual tasks can also contain several vulnerabilities, requiring the model to continue beyond the first plausible issue. depthfirst-bench captures the full workflow of a security audit, requiring findings to hold up under broader analysis and, where possible, executable verification. We will describe the construction and methodology of depthfirst-bench in greater detail in a future post.

In this report, we describe the multi-task RL recipe used to train dfs-large1, the audit behaviors that have emerged during training, and zero-day vulnerabilities discovered by the model.

Security Harness

Large enterprise monorepos are difficult for single-agent architectures to audit effectively. As repositories grow, audits become more expensive while code coverage and performance degrade. Our production security harness divides each repository into targeted audit scopes, giving every agent a bounded investigation surface while preserving the broader context required for vulnerability analysis. Each agent receives a bounded list of files and the corresponding scoped threat model, including attack surfaces, trust boundaries, and relevant data flows. Its shell remains rooted at the full repository, so it can inspect shared libraries, callers, dependencies, and other out-of-scope files when tracing reachability or exploitability. In multi-repository audits, related repositories are also available as supporting context. The harness executes these scopes concurrently at scale, allowing us to maximize code coverage while shortening the time required to assess the repository as a whole. dfs-large1 is optimized to operate within this framework across even the largest repositories.

Repository context is essential because vulnerability analysis is rarely local. An input that appears attacker-controlled may have been validated upstream, while a dangerous-looking sink may be unreachable from any untrusted path. Code that looks safe in isolation may also become exploitable through behavior elsewhere in the repository. Consequently, agents that reason only from local snippets can miss real vulnerabilities or report findings that do not survive broader analysis.

dfs-large1 is trained jointly on three tasks: detecting vulnerabilities in application code, detecting vulnerabilities in low-level systems code, and validating candidate findings. We include both detection and validation as learning objectives because they provide complementary learning signals. Low-level repositories often expose fuzz targets and reproducers that make defects directly testable, with a reproducible address sanitizer (ASan) report providing strong evidence of reachable memory corruption. Web application findings are harder to validate automatically because they often depend on application state and external services. Training across both combines direct verification signals from systems code with the diversity of application security tasks, while relying on the same core reasoning about attacker control and reachability.

The training recipe below targets the reasoning required for broad vulnerability discovery, rigorous validation, and end-to-end data flow analysis. It also optimizes for efficient token and tool use.

Training Recipe

dfs-large1 is post-trained with a multi-task RL recipe designed for long-horizon tasks.

Reward Design

Each completed trajectory receives a scalar task reward, which we shape before computing advantages. The adjusted reward incorporates two behavioral priors motivated by our production workload: an effort penalty that encourages efficient investigation and a report budget that discourages speculative findings.

Effort Penalty

We measure trajectory effort using a linear combination of action tokens, agent rounds, and tokens returned by tools. We then apply the following penalty as a function of effort:

C_{\text{effort}}(x) = \lambda \frac{\log(1 + \alpha x)}{\log(1 + \alpha)}

Here, $x$ represents aggregate trajectory effort, $\lambda$ controls the overall penalty strength, and $\alpha$ controls its curvature. We choose an increasing and concave penalty function because we believe the marginal penalty for additional work should decrease as effort grows. In this manner, extra action tokens, turns, and tool output tokens for short rollouts are penalized more heavily than long investigations. This is inspired by Composer 2’s rationale, where they encourage efficiency on simpler tasks without suppressing the sustained exploitation required for more difficult tasks [1]. We use a simpler logarithmic form with one curvature parameter to make tuning simpler.

We observed that including this additive effort cost in the shaped reward increased parallel tool use while reducing or holding constant the number of agent rounds and policy action tokens. In ablations without the penalty, rounds and action tokens continued to grow indefinitely with additional RL compute.

Finding Budget

Within an agent audit scope, true vulnerabilities are typically sparse, so we apply a soft budget penalty to the number of findings returned by our detection agent:

q(n; B_t) = \frac{1}{\max(1, n - B_t + 1)}

Here, $n$ is the number of reported vulnerabilities and $B_t$ is the full-credit budget at training stage $t$ . Reports within the budget retain full credit, while additional vulnerabilities reported progressively scale it down. Our desire is to discourage speculative findings proposed by an agent without imposing a hard cap for audit scopes genuinely containing multiple vulnerabilities.

We begin training with a large budget and gradually lower it in stages, increasing pressure against over-reporting only after the policy has established baseline recall. In controlled toy runs, we found this penalty was essential to preserve data-flow reasoning; without it, the policy would devolve into reporting locally plausible vulnerabilities without establishing any reachability or exploitability evidence. As discussed below, this penalty also encouraged greater use of project harnesses to test reachability and exploitability.

Policy Optimization

We optimized dfs-large1 with a masked importance sampling objective chosen for stability under the policy mismatch introduced by our training system. Our asynchronous actor-learner pipeline overlaps rollout generation with optimization, which is essential for tasks that span roughly 100 agent turns. Synchronizing each update on the slowest trajectories would otherwise leave GPUs idle [2], [3]. The tradeoff for this speedup is policy lag, since the learner may advance several steps before consuming trajectories sampled by our actors.

A separate source of mismatch exists between rollout and training engines. Even under identical weights, differences in numerical precision, kernel implementations, etc. can produce different token probabilities [4]. In MoE models, these small numerical differences can also change which experts are selected, further amplifying this discrepancy. We mitigate this by recording the expert routes selected per generated token and replaying them in the training forward pass [5].

We correct for both sources of mismatch using a masked importance-sampling REINFORCE update presented by Periodic Labs [6]. Following this formulation, the update is:

\begin{gathered} \nabla_\theta J_{\mathrm{MIS}}(\theta) = \mathbb{E}_{y \sim \pi_{\theta_{\mathrm{old}}}}\!\left[ \sum_{t=1}^{|y|} M_t \cdot r_t(\theta) \cdot \hat{A}_t \cdot \nabla_\theta \log \pi_\theta(a_t \mid s_t) \right], \\[2em] r_t(\theta) = \frac{\pi_\theta(a_t \mid s_t)} {\pi_{\theta_{\mathrm{old}}}(a_t \mid s_t)}, \qquad M_t = \mathbb{I}_{\left\{ 1 - \epsilon_l < r_t(\theta) < 1 + \epsilon_h \right\}} \end{gathered}

Empirically, masking tokens outside our trust region from the surrogate objective produced more stable asynchronous training than clipped alternatives. CISPO clips extreme importance weights while retaining every token’s gradient contribution [7], but this was less effective for our long-horizon tasks. We suspect that a substantial fraction of these $p_{99}$ logprob differences reflect trainer-sampler mismatch from numerical and systems differences rather than useful policy movement. We therefore treat ratios outside the trusted interval as unreliable training signals, and we remove them from the loss calculation.

Advantage Estimation

We use Dr. GRPO to compute advantages, centering rewards within each rollout group while removing group standard deviation and response-length normalization [8]. These terms can overweight low-variance prompts and weaken negative updates on long trajectories.

In multi-task training, however, different task families can produce advantages at substantially different scales. We’ve observed that this can lead high-variance tasks to dominate the shared policy update for reasons unrelated to the quality of their learning signals. Following AgentRL [9], we apply an additional task-level normalization:

\begin{gathered} A_{i,s,g,t,k} = \frac{\hat{A}_{i,s,g,t,k} - \mu_i}{\sigma_i + \epsilon} \\[12pt] \mu_i = \frac{1}{N_i} \sum_{s,g,t,k} m_{i,s,g,t,k} \cdot \hat{A}_{i,s,g,t,k}, \qquad \sigma_i = \operatorname{Stdev}(\{\hat{A}_{i,s,g,t,k} : m_{i,s,g,t,k} = 1\}) \end{gathered}

Context Compaction

For long-horizon rollouts, dfs-large1 reuses the summarization-based context compaction recipe introduced with dfs-mini1 [10]. As the context window fills up, the policy compresses the trajectory into a concise state summary and continues from that representation rather than the full transcript. Because the same policy generates these summaries and receives the final trajectory reward, context management becomes part of the learned agent behavior.

Results: Learned Audit Strategy

During training, we observed that dfs-large1’s audit strategy shifted from broad enumeration toward testing specific vulnerability hypotheses. In judged samples, later checkpoints spent a larger share of turns tracing attacker-controlled inputs and used executable harnesses more often, while repository reads and searches declined.

These two condensed trajectories show the shift: dfs-large1 tests critical assumptions and carries hypotheses through to executable evidence.

Comparison

dfs-large1 verifies that unused entries are uninitialized and reproduces the crash; GLM 5.2 assumes they are NULL and stops at a memory leak.

dfs-large1

Reasoning 1

With *TotalFiles = 2, the transfer loop fills entries [0] and [1]. Entries [2] and [3] are unfilled.

When the processing loop runs, ix=0 accesses names_array[0]; ix=2 accesses names_array[2] (garbage).

Tool call

Traces how names_array is allocated, populated, and iterated.

Reasoning 2

Four slots are allocated, but only the first filename/reference pair is initialized. The later loop still processes the uninitialized second pair.

The / in /application/pdf is a PDF delimiter. I need to escape it as /application#2Fpdf or use the %PDF- content-check path.

Tool call

Repairs PDF detection while retaining a non-string filename key.

Reasoning 3

The revised collection contains one valid filename pair followed by a pair whose filename is the integer 42. The malformed pair now reaches the uninitialized-array path.

Now let me regenerate and test.

Tool call

Runs the malformed collection through the Address Sanitizer build.

Crash reproduced

The processor opens the valid temporary file, then attempts the garbage filename c. The corrupted state subsequently crashes during context cleanup.

GLM 5.2

Reasoning 1

Unused entries might be NULL, and gs_free_object handles NULL safely. Therefore the cleanup is correct.

Tool call

Reviews the cleanup-loop bounds and looks for unreleased entries.

Reasoning 2

The cleanup loop frees fewer working_array entries than were allocated.

This means entries at indices 3, 4, and 5 are leaked. This is a memory leak, not a security issue.

Tool call

Continues searching for a different crash primitive.

Comparison

dfs-large1 carries the metadata mismatch through exact buffer arithmetic to a reproduced over-read; GLM 5.2 abandons it for an untested theory.

dfs-large1

Reasoning 1

What if the TIFF declares SamplesPerPixel=1, but its photometric mode selects a decoder that assumes multiple samples? Validation checks these fields independently rather than checking that they agree.

Tool call

Compares how libtiff sizes the scanline with what each libcupsfilters decoder consumes.

Reasoning 2

The loader accepts PhotometricInterpretation=SEPARATED with SamplesPerPixel=1, but the selected decoder advances by four bytes per pixel.

With ImageWidth=100, that is a 100-byte scanline. But the loop reads 4 × 100 = 400 bytes. The vulnerability requires PhotometricInterpretation=SEPARATED and SamplesPerPixel=1.

Tool call

Constructs the smallest inconsistent TIFF and decodes it under Address Sanitizer.

Crash reproduced

The decoder reads past the 100-byte scanline at image-tiff.c:1434, matching the agent's allocation and consumption calculation.

GLM 5.2

Reasoning 1

Even with SamplesPerPixel=1, the SEPARATED path is entered. The scanline is one byte per pixel, but the loop reads four bytes per iteration.

Tool call

Models the SEPARATED path's pointer movement across image dimensions.

Reasoning 2

TIFFScanlineSize = xsize bytes, but the loop reads four bytes per iteration.

The OOB condition is xsize > ysize + 1, regardless of the samples value.

Tool call

Analyzes the column-major output pointer and derives a dimension-based condition.

Figure 2. Agent trajectory comparison.

We suspect the finding budget, effort penalty, and joint training on vulnerability validation all contributed to this shift. The finding budget creates pressure against unsupported reports, the effort penalty rewards targeted investigation over repeated browsing, and validation training rewards turning a hypothesis into executable evidence.

Real-World Vulnerability Discovery

Beyond our evaluations, we are testing dfs-large1 across production code-scanning workflows. Separately, a previous checkpoint supported parts of our Ruby ecosystem campaign. That broader campaign validated 105 vulnerabilities across 34 projects, roughly 61% of them memory-safety issues [11]. We plan to apply dfs-large1 to more open-source security research.

Continued Training

Ultimately, our goal is to deliver the best possible agentic product experience for customers using the depthfirst security harness. That means shorter time to actionable findings, lower cost per audit, and fewer false positives.

We have collected thousands of executable security environments. We have not yet saturated these environments, leaving substantial headroom to keep scaling the training recipe, annealing our finding penalty to further reduce false positives, and improving token and turn efficiency.

Evaluation Methodology

Unless otherwise specified, all models are evaluated at high thinking difficulty and executed within depthfirst’s security harness. To preserve evaluation integrity, our sandboxes block internet access and expose only a shallow clone of each repository with depth 1 and no commit history. We also use LLM behavioral monitors to flag reward hacking, superficial pattern matching, or attempts to obtain information unavailable in the evaluation by searching the internet or inspecting future commits containing vulnerability patch information.

Finally, we reviewed every passing trajectory to verify that it reflected authentic vulnerability discovery, and we confirmed that no failures resulted from cybersecurity-safety refusals.