-
-
one autonomous agent that takes on four security roles in a single verified loop.
-
Attacker role the agent writes a real exploit and confirms the vulnerability verified by both the test result and the actual attack artifact
-
Defender role: the patch blocks the exploit while keeping the function working — verified, not assumed.
-
Analyst role: an evidence-based security report, built only from what the agent actually proved.
-
Threat Hunter role: profiling attacker behavior from simulated honeypot traffic (clearly labeled as sample data).
Inspiration
Most security scanners flood developers with alerts that say "this might be a vulnerability." Many are false alarms, so real issues get ignored in the noise. We asked a different question: what if an AI agent didn't just point at a vulnerability, but actually proved it was real, fixed it, and then proved the fix worked?
What it does
SolarAgent is a single autonomous security agent that switches between four roles in one continuous loop:
- Analyst — triages the code and identifies the vulnerability (e.g. CWE-78 Command Injection).
- Attacker — writes a real working exploit and runs it inside an isolated sandbox.
- Defender — patches the code, then re-runs the exact same exploit to prove it's blocked.
- Threat Hunter — analyzes honeypot traffic to profile attacker behavior.
The core idea is evidence-based verification: SunShine never claims a fix succeeded unless two independent signals agree — the test result and the actual attack artifact inside the container. The patched function is also re-tested to confirm it still works, so a "fix" that simply breaks the code is rejected.
How we built it
- Nebius Token Factory for model inference (required track condition).
- NVIDIA Nemotron open-weight model as the reasoning engine behind all four roles.
- Docker to run every exploit and patch in an isolated, network-disabled sandbox with memory, CPU, and process limits.
- pytest for automated verification, cross-checked against the real filesystem.
- Streamlit for the interface.
Each run executes in its own fresh temporary directory, so runs never interfere with each other.
Challenges we ran into
The hardest part wasn't getting it to work — it was making the verification trustworthy. Early versions could report a "verified patch" when the test had actually failed for an unrelated reason (a missing system tool, a syntax error, or a test that crashed). We rebuilt the logic to distinguish a genuine security result from an infrastructure error, and to require direct evidence (the attack artifact) before trusting any verdict.
Accomplishments that we're proud of
- Trustworthy verification, not just output. SunShine never reports a "verified fix" on a model's word alone — every verdict is cross-checked against the real attack artifact inside the sandbox, and infrastructure errors are never mistaken for success.
- One agent, four roles. Instead of stitching together separate tools, we built a single autonomous agent that attacks, defends, analyzes, and hunts — showing the full offensive-and-defensive loop end to end.
- Safe by design. Every piece of model-generated code runs in an isolated, network-disabled container with strict resource limits, and the app refuses to execute code at all when no safe sandbox is available.
- Honest scope. We clearly label what's real and what's simulated, and we resisted the temptation to overclaim — which we believe makes the project stronger, not weaker.
- Shipped a complete, working product in under 48 hours — from first API call to a polished interface, a live demo, and a documented repository.
What we learned
A real security tool's value is in what it can prove, not what it can guess. We also learned to be honest about limits: safe-by-design choices sometimes cost convenience, and that's a trade-off worth making.
What's next for SolarAgent
- Support for multiple vulnerability classes beyond Command Injection.
- Scanning real GitHub repositories.
- A live honeypot instead of simulated traffic.
Note: This is a proof of concept built, focused on one vulnerability class. The honeypot traffic is simulated sample data. The live demo link shows the interface; the full attack-patch-verify cycle requires a local Docker sandbox for safety — shown fully in the demo video.
Log in or sign up for Devpost to join the conversation.