Security teams have spent years hearing some version of the same promise: AI will find your vulnerabilities before attackers do.
What followed was usually a wave of tools that confidently listed bugs, explained them in plausible detail, and were quietly wrong about a third of them. The triage work alone could take longer than just reading the code yourself.
That dynamic is what makes OpenHack worth paying attention to. Not because it is the most powerful AI security tool in existence, it explicitly is not. But because it is the first open-source framework that confronts the actual failure modes of AI-assisted code review head-on, names them precisely, and builds an architecture specifically to fix them.
That sounds like a small engineering distinction. It is actually a significant shift in how this category of tool gets built.
A Tool Built from Real Findings
On May 20, 2026, Amsterdam-based offensive security firm Hadrian released OpenHack, a free, MIT-licensed agent workflow for AI-powered source code vulnerability research. It runs inside Claude Code, OpenAI Codex, or Cursor, requires no proprietary infrastructure, and is available in full on GitHub.
The release was not a pivot to open source for goodwill. It came directly out of concrete research results. Hadrian’s team had spent months using a similar internal methodology to audit open-source applications used by Dutch government agencies. The results were sobering: hundreds of vulnerabilities surfaced in hours. Among them, a critical-severity flaw that exposed server credentials and provided direct access to an underlying Azure database.
That finding made the release feel urgent.
As Hadrian’s CEO, Rogier Fischer, put it plainly: “Attackers have workflows like this already, in one form or another. We’d rather hand defenders the same scaffolding we use internally than watch them re-derive it under pressure.”
The result is OpenHack, a framework that codifies how a skilled human research team would structure an AI-assisted code review, so that the agents doing the work operate with the same rigour a senior researcher would demand.
How OpenHack Actually Works
The central insight behind OpenHack is that most AI code review fails not because the model is unintelligent, but because the workflow has no structure. Ask a large language model to read a codebase and identify vulnerabilities, and you will get output. It may be quite sophisticated output. But two failure modes reliably degrade quality:
- Unscoped prompts. The agent doesn’t know exactly what question it’s answering, so it answers all of them at low confidence, producing a mixture of real bugs, hallucinated bugs, and plausible-but-wrong explanations.
- Self-graded findings. The same agent that proposed the vulnerability decides whether it’s real. There is no independent verification step. Confidence becomes a proxy for correctness, and models are systematically overconfident.
OpenHack’s architecture is built to eliminate both of these.
The State Machine Model
OpenHack operates as a file-based state machine. Every stage of a review produces durable output stored as plain files on disk, cloned source, recon items, scenario prompts, scenario results, finding candidates, triage decisions, and logs. This is not just an engineering convenience. It means the entire review is fully auditable, restartable, and human-reviewable at every stage.
The operating pattern is simple and strict: a command advances the run to the next state, an agent answers the prompt for that state, and a recorder command validates the answer before materialising new work. No state can be skipped. No agent can self-approve its own output. Human operators are embedded at every major phase transition. The expert scope must be approved before reconnaissance begins. Scenario routing is approved after recon. The scenario backlog is approved before expert agents begin work. And the finding-triage backlog is approved before candidates become final findings.
It reads like a research methodology, not a software architecture. That’s the point.
The Agent Hierarchy
The workflow flows through three distinct layers of agents, each with a defined scope:
- Recon Agents map the attack surface of the codebase. They identify review surfaces: routes, authentication boundaries, upload paths, parser entry points, admin areas, manifest files, and data sinks. Their job is enumeration, not judgment.
- The Scenario Router takes those recon items and translates them into scoped scenarios. Each scenario is a tightly defined unit of work: one surface, one expert family, one specific proof question. The router is what prevents the “find everything wrong” prompt from ever being issued.
- Expert Agents receive a single, scoped scenario and attempt to prove or reject it. Twelve expert families exist in the current registry, each defined by a Markdown manifest that declares its id, category, applicable standards, and routing signals.
- The Triage Agent is entirely independent of the expert agents. It reviews each finding candidate against the original evidence and makes a binary decision: is this a verified vulnerability, or not? The proposing agent has no role in this decision.
The separation between the expert agents and the triage agent is where OpenHack diverges most sharply from typical LLM security tooling. It is also, arguably, where most of the quality improvement comes from.
A finding only becomes a finding when a second agent, with no knowledge of who proposed it, independently confirms it.
What OpenHack Actually Represents
To understand why this matters beyond its specific features, it helps to look at the landscape it was released into. Hadrian’s own research catalogued 70 open-source AI penetration testing tools as of March 2026. Fewer than five existed before GPT-4’s release in April 2023. The remaining 65-plus launched in under two years.
Most of those tools are proof-of-concepts or thin wrappers: give the model a target, get output.
The benchmark literature from 2024 through early 2026 produces a consistent finding: AI offensive capability is strongest at the reconnaissance phase and degrades significantly through exploitation and verification.
OpenHack’s answer to this is structural: keep AI at what it’s good at, pattern recognition and exhaustive enumeration and build human-verifiable checkpoints around the parts where AI is unreliable. This is different from building a smarter model. It’s building a smarter workflow around the models that already exist.
There’s also a more uncomfortable dimension to this release. The same methodology that finds vulnerabilities defensively is available to anyone. Rogier Fischer acknowledged it directly: attackers already have workflows like this. The argument for open-sourcing OpenHack is that defenders shouldn’t have to build it from scratch under pressure, but the dual-use reality is real.
Meanwhile, the threat environment is shifting rapidly. Google’s Threat Intelligence Group reported in May 2026 that adversary use of AI has matured from experimental to industrial-scale application, with threat actors maintaining pooled access to frontier model tiers and actively using them for vulnerability exploitation, phishing, and initial access operations.
Against that backdrop, OpenHack is less a product announcement and more a position paper. It argues that the security community’s response to AI-assisted offence should be AI-assisted defence, structured carefully, not panicked automation.
“AI-powered vulnerability discovery must transition from being a research curiosity to a commodity capability.” — Rogier Fischer, CEO, Hadrian
The Democratisation Argument
The word “democratisation” gets overused in tech press releases. In this case, it has some real weight. One in five organisations reported an LLM security incident in 2026, according to Cobalt’s State of Pentesting Report. Security confidence in keeping pace with AI-driven threats has dropped from 64% to 51% in a single year. Demand for formal pentests is rising faster than the supply of qualified humans to conduct them.
OpenHack doesn’t replace a human penetration tester. But it does make it possible for a security engineer without deep offensive expertise to run a structured, verifiable, documented code review against their own application, one that produces findings worthy of triage, not just a list of things an AI thought sounded suspicious.
That is the gap it fills. And it’s a gap most teams feel every day.
Key Takeaways
- OpenHack is free, MIT-licensed, and available now at github.com/hadriansecurity/openhack. No proprietary infrastructure required.
- It runs inside Claude Code, Codex, or Cursor, harness-agnostic and model-agnostic.
- The core innovation is architectural, not model-based. Scenario-first scoping eliminates unscoped prompts; independent triage eliminates self-graded findings.
- Twelve expert families cover OWASP Top 10:2025 and key MITRE CWE categories, with optional Semgrep enrichment during recon.
- Every stage produces durable, auditable files; the full review is inspectable end to end.
- Human approval gates exist at every phase transition. OpenHack augments human judgment; it does not replace it.
- Real-world validation is compelling: a similar internal methodology surfaced hundreds of vulnerabilities in Dutch government software in hours, including a critical Azure credential exposure.
- The dual-use reality is explicit: Hadrian acknowledges that attackers have comparable workflows. The release is a deliberate attempt to level the playing field for defenders.
- The 2026 AI offensive security landscape has 70+ tools. OpenHack is one of very few built with rigorous attention to reducing hallucination and unverified output.
- Python 3.9+ required. Responsible disclosure guidance is included in SECURITY.md.
Conclusion
There is something quietly clarifying about the way OpenHack was built. Not through a model breakthrough, not through proprietary data, and not through a locked platform that makes it expensive to access. Through methodology.
The insight that agents should not grade their own findings, that the proposer and the verifier should be separate, is not a machine learning insight. It is a research methodology insight. It is the kind of thing that any experienced security researcher would recognise immediately and any AI product team might miss entirely.
That is what makes OpenHack worth watching beyond its current feature set. It represents a design philosophy: that reliable AI-assisted security work requires structure, not just capability. That the humans in the loop matter. That auditability is a feature, not a constraint. In a year when AI offensive tools are proliferating faster than security teams can evaluate them, that design philosophy is actually a rare thing.
The question OpenHack implicitly poses to every security team isn’t whether to use AI. It’s whether the AI they’re using has been built to be trusted or just built to produce output.
The answer to that question matters more than any single vulnerability it finds.
