A verification harness for blue teams, not another autonomous-pentest demo.
- Founded2026
- Stagepre-alpha
- LicenseApache-2.0 (open core)
- Telemetrynone
- BuiltBergen / Oslo, Norway / remote
The hard part isn't generating detections. It's proving the ones you ship actually fire.
Who builds Riposte
Riposte grew out of a bachelor thesis question: do AI coding tools actually produce secure code. It is built in the open by two people working at the intersection of offensive security and software, an agentic security CLI in the spirit of Claude Code and Codex. Where those drive coding, Riposte drives offensive and defensive work: real recon, exploitation, and detection engineering.
Joakim Larssen
builder, architectKrister Eriksen
builder, architect
What we're building.
Riposte is a verification harness that closes a loop between offense and defense. Red reproduces an exploit on an authorized target and keeps the reproducible artifact. Blue auto-drafts a Sigma rule from that exact artifact, not from a prompt or a guess. The artifact is the spec.
A drafted rule does not ship because it looks right. It ships only if it survives four fail-closed gates: it compiles to your backend, it fires on the real exploit, it still catches a model-mutated variant of that attack, and it stays under your false-positive threshold against a benign corpus. Each rule that passes carries a 3-axis score (efficacy, robustness, cost), so you know what you are running, not just that it ran.
Safety is the architecture, not a setting you can forget to enable. Every run is bound to a signed Rules-of-Engagement, the scope is deny-by-default and checked before every action, tool execution is sandboxed, every action appends to a hash-chained audit log you can verify offline, and a global kill switch halts everything. Each control fails closed: if it cannot run, Riposte does not act.
How we work.
Riposte is built in the open by two people working at the intersection of offensive security and software. The engine is Apache-2.0; you can read every claim on this site by cloning the repo.
Every security-relevant slice is adversarially reviewed before it lands. A tool whose one job is to catch rules that are confidently wrong has no business shipping code that is confidently wrong, so review is the discipline, and the bugs it has caught are documented with the fixes in the repo.
We hold the marketing to the same standard as the harness: pre-alpha is stated plainly, nothing is overclaimed, and every claim is meant to survive a git clone. The way in is a design-partner approach, one blue team at a time, with a benign log corpus and an authorized target. We are looking for one design partner, not a waitlist.
Why this, why now.
There are two crowded rooms in AI security. Offensive-AI tools race to demonstrate more end-to-end attack capability. AI-SOC tools race to triage alerts and write detections at the speed of a language model. Both spaces are commoditizing fast, and neither owns the seam between them: detection-coverage drift, validated by real exploits.
That seam is the wedge. The offensive room proves attacks but does not ship you a detection. The defensive room ships detections but cannot prove they fire on a real exploit. LLM-written rules are frequently syntactically perfect and logically wrong, so the verification harness, not the generation, is the product. A generator is the easy part. Proving the rule you ship actually fires is the part nobody is doing.