Flash-01
Our first open-weights model trained specifically for security research
An open-weights model for security research, post-trained on real vulnerabilities from our own private dataset.
As AI models get better at cybersecurity, a bigger question keeps coming up: who should be allowed to use that capability, and under what conditions? Most of the safety debate right now is about controlling access, through closed models, API policies, usage limits and safeguards meant to keep advanced cyber capabilities from being misused.
The catch is that security is adversarial.
Attackers don't follow acceptable-use policies, procurement rules, data residency requirements or third-party risk checks. They can run open models locally, modify them, remove the safeguards and build tools on top of capabilities that are already out there. Defenders are the ones working under the tightest rules. That creates a lopsided kind of safety, where legitimate security teams get blocked from capabilities a determined attacker can still get.
Security went through a version of this debate back in the late '90s and early 2000s. Vulnerability disclosure, exploit development, scanners and offensive tools were all controversial, because the same tech could be used to attack a system or defend it. Over time, Nmap, Metasploit, public vulnerability research and reproducible exploits became part of the everyday infrastructure of security. The lesson wasn't that dual-use tech is harmless. It was that limiting what defenders know doesn't make the offensive capability go away.
AI brings that argument back, at a much bigger scale.
The question isn't whether these capabilities can be misused. They can. The question is whether limiting legitimate access actually limits attackers once capable open models already exist. We think it's more and more limiting defenders instead.
Attacks that run at machine speed need defense at machine speed. Defenders need models they can run, control and improve inside the systems they're responsible for protecting.
Stardust Flash-01 is our first contribution to that shared defense.
// 01 · HOW IT WAS BUILT
From security research to Stardust Flash-01
Turning real-world findings into production-like environments for agent training.
Step 1 · Discovery
Stardust finds vulnerabilities
Reviews, scans and investigations of software and protocols.
Step 2 · Environments
Build production-like gyms
Recreate the behavior, roles and system interactions that matter.
Step 3 · Vulnerabilities
Bring in the discovered bugs
Move validated findings into isolated training environments.
Step 4 · Difficulty
Tune exploit chains for difficulty
Balance the challenge against the information the agent has to work with.
Step 5 · Reinforcement learning
Train Stardust Flash-01
Train on agent trajectories with verified target outcomes.
Step 6 · Evaluation
Evaluate on unseen cases
Measure performance on held-out environments.
// 02 · THE FIRST TRAINING RUN
One case, three views
For this first training run, we built 150 tasks from 50 vulnerability cases. Each case comes in three views, and each view gives the agent a different level of information.
Tasks
Cases
Views each
Guided whitebox
Source code · detailed guidance
Full source code plus detailed guidance on the vulnerability and the exploit path. The agent still has to pull off a working exploit.
Information given
Focused whitebox
Source code · light direction
Full source code with only light direction toward a subsystem. The agent has to dig into the flaw and build the exploit on its own.
Information given
Focused blackbox
Running target only
Limited direction and access to the running target, with no source code available.
Information given
// 03 · COMPOSITION
Training case composition
How the 50 training cases split up by category.
- Access control, identity & scope72%
- Accounting & number precision18%
- Time checks & signature reuse4%
- Business logic & payment checks4%
- Server-side request forgery (SSRF)2%
// 04 · TRAINING
Trained on real security work
Base model
GLM-5.3-Flash
Method
Rank-256 LoRA + selective full-parameter training, GRPO
Training tasks
150, built from 50 cases
Role
Worker model, run by an orchestrator
We started from GLM-5.3-Flash and fine-tuned it with GRPO reinforcement learning.
Our security work keeps adding to a collection of vulnerability patterns, along with the context we need to turn them into training environments. We build on working open-source applications and protocols, add realistic flaws, and keep the surrounding complexity that makes an investigation worth doing.
Turning those environments into useful training data takes another layer of work. We change how much information the agent gets and tune the difficulty so a good investigation can succeed without the answer being handed over. As models get better, we can come back to the same environments with less guidance and harder combinations of flaws. Being able to keep creating, checking and refining cases is at the heart of what we're building.
The size of the training set also changed how we updated the model. We used rank-256 LoRA across all experts and routers, plus full-parameter updates on 16 experts picked by activation. Updating every parameter in every expert made the model collapse in our experiments. Our guess is that the small RL dataset pushed gradients into experts that weren't a good fit for agentic work.
A credible security RL gym takes more than adding a bug.
The environment, the information on hand and the success checks all have to support an investigation that makes sense. A task gets too leading when its setup gives the answer away, and close to impossible when key information is missing or the goal can't be reached. How the task prompt is worded matters a lot here: naming a function or pointing at a subsystem can change solve rates dramatically. Rebuilding the complexity of production systems makes this balance especially hard to get right.
That matters for methods like GRPO, which compare results across a group of rollouts on the same task. With a pass/fail reward, a group where every attempt passes or every attempt fails gives no contrast to learn from. Cases the model solves only some of the time are the ones that give a useful comparison. So we focus on realistic environments, clear verification, and difficulty that matches what the model can do today.
That limit also shaped what we built Stardust Flash-01 to do. It's designed as a strong worker model, run by a larger model that hands it a focused security task. Training a smaller model on challenges it almost never solves gives little useful GRPO signal, so we match difficulty to its current ability while keeping the real investigation work intact. Once it has a clear focus, the worker is persistent: it reads code, uses tools, tests ideas and confirms what it finds. We've seen this split of work let smaller models find bugs that still take deep investigation.
// 05 · ANATOMY
Anatomy of a training case
Each case is a small, realistic deployment: a pinned app release with one planted flaw, populated with believable data and reset before every attempt. The agent works from its own sandbox with a brief, a toolkit and limited access, while a verifier it can't see checks the end state and hands out a simple pass or fail. Scored runs go into training, and passing runs get a second look so that any case won through a shortcut is sent back for repair.
Example: artifact isolation in Forgejo
One of these environments rebuilt an authorization flaw around workflow artifacts in Forgejo, an open-source platform for hosting code. The bug class surfaced in our discovery pipeline, and we shaped the scenario after systems we had run into during real security engagements.
The agent started out with access to a single running workflow. A second workflow held an artifact it was not supposed to see. The boundary was simple: being allowed to fetch one workflow's outputs should never unlock another's.
We planted the flaw in how artifact access gets authorized. The signed download URL leaves out part of the workflow context that the app relies on later to pick which artifact to serve. Finding it meant linking two pieces of the system: what the signature actually covers, and what the download handler ends up returning.
The agent dug into that gap and showed its impact on the live application. The verifier then checked whether the protected artifact's contents had been recovered, which gave us a clear, concrete result to train on.
It mirrors a kind of authorization failure we see in real systems: each component looks fine on its own, yet they disagree on how far a permission reaches. Rebuilding that pattern inside a working system keeps the context that makes it hard to track down.
// 06 · PERFORMANCE & COST
Results per dollar
Stardust Flash-01 is a fine-tune of GLM-5.3-Flash, and on our internal held-out evaluation it beats the base model by a steady 5–8%. A full pass over all 60 tasks costs an estimated $2.38, against $4.56 for GLM-5.3-Flash and $74.68 for Claude Opus 5 High at provider pricing.
Public cyber benchmarks have their place, but they tend to boil security work down to tidy, academic puzzles. Our own environments are built to resemble the engagements we run for customers, down to real exploitable bugs we found, reported responsibly and, in many cases, were paid bounties for.
We've post-trained open models ranging from about 27B to 1T parameters. Stardust Flash-01 is the first we believe genuinely shifts the cost-to-capability frontier on real-world security work. Getting that balance right is what lets capable security agents become affordable for every company, not only the handful that can pay for frontier-model pricing.
Claude Opus 5 High
Reference
71.7%43/60 solvedFull run
$74.68
Stardust Flash-01
Our model
66.7%40/60 solvedFull run
$2.38
GLM-5.3-Flash
Base model
60.0%36/60 solvedFull run
$4.56
Score against spend
One pass over all 60 held-out tasks per model. Spend is estimated from each provider's list pricing. Up and to the right is better.
Built for the defenders
Download the weights, run them on your own infrastructure, and make them yours.