What this isA working catalogue, not a census
Three years ago the AI offensive security category was a handful of research prototypes. It is now a crowded market with three distinct supply chains: community projects on GitHub, funded commercial platforms, and the research, benchmark and adversary-side artefacts that surround both. Hadrian catalogued roughly 70 open-source offensive AI tools by early 2026 across autonomous agents, vulnerability discovery, reverse engineering, recon, LLM red teaming, CTF agents and unguardrailed cyber LLMs — and that count moves monthly.
This page splits the landscape three ways, maps each entry to the engagement phase it actually serves, and gives you a phased adoption checklist. It is built for someone deciding what to run, not what to buy.
Agentic pentest frameworks, LLM red-team scanners, and AI-augmented versions of the classic toolchain. Free, attributable to no one, and improving fastest. Maturity is uneven — in one comparative test only two of eight agentic frameworks completed an end-to-end assessment without setup or execution failures.
Autonomous exposure validation, agentic web and API offence, breach and attack simulation, and PTaaS with AI triage. You are buying evidence chains, safe-exploitation guarantees, remediation verification and compliance reporting more than raw capability.
Benchmarks, datasets, offensive-tuned models, risk taxonomies, and the adversary side — LLM-enabled malware and guardrail-free models sold in criminal markets. Not tools you deploy; context that tells you whether the tools work and what the other side is running.
Scaffolding beats model size
The harness matters more than the base model. Fine-tuned mid-size models like xOffense and CIPHER now beat larger frontier models on offensive sub-tasks — domain adaptation beats raw scale.
MCP became the delivery layer
MCP servers such as HexStrike wire 150+ security tools to any compatible model. Building an offensive agent is mostly integration-free now; the constraint is operator judgement, not tool access.
The bar moved from "does it work" to "does it fit"
The question is no longer whether AI pentesting works. It is whether a platform can prove findings safely, keep an evidence trail, and deliver into the workflow your team already uses.
Attribution ambiguity favours attackers
Open-source offensive AI is free and leaves no procurement trail. Defenders can no longer assume an attack required state-level resourcing — community tooling and advanced actors look the same from the outside.
How to read thisTools mapped to the phase they earn their place in
Most tools in this space market themselves as end-to-end. Very few are. Mapping by phase makes the overlaps and the gaps visible — and it is the honest way to see that a stack needs three or four tools, not one. Click any tool to open it in the Catalogue with that phase filtered.
Loadable examplesFour stacks for four different jobs
Each example loads a filtered view of the catalogue. They are starting points drawn from how these tools are actually combined in practice, not vendor-endorsed reference architectures.
AdoptionFour phases from evaluation to production
The failure mode with agentic offensive tooling is not that it does nothing — it is that it does something unscoped, at speed, against a target you did not mean to touch, and produces findings nobody can reproduce. This sequence front-loads the controls that prevent that.
0 of 0 complete
MethodologyHow this catalogue was built
Scope. Tools where AI or an LLM is load-bearing to the offensive function — autonomous decision-making, exploit reasoning, adversarial prompt generation, or agentic orchestration. Conventional tools with an AI-generated summary layer bolted on are excluded unless the AI component changes what the tool can find.
Sourcing. Vendor and project primary material first (GitHub repositories, product documentation, published papers), then independent comparative testing and practitioner write-ups. Where a comparative claim is repeated only by a vendor about its own product, it is either attributed or omitted.
Three-way split. Open source means a public repository under an OSI-approved licence, regardless of whether a paid tier exists. Commercial means the core capability requires a paid licence or subscription. Other covers benchmarks, datasets, taxonomies, research models and adversary-side artefacts — things that inform the category without being deployable tooling.
Phase mapping. Phases follow a standard engagement arc (recon → discovery → exploitation → post-exploitation → validation and reporting) with two additions: AI-target testing for tools that attack an LLM or agent rather than use one, and governance for taxonomies and assurance frameworks. A tool is mapped to a phase only where it does substantive work, not where it merely touches it.
Confidence and staleness. Maturity assessments come from published comparative testing where available and are labelled as such. This category turns over fast: entries appear, get acquired, and go dormant within a quarter. Treat this as a snapshot dated August 2026 and re-verify anything before it goes into a proposal.
Known limitations. Coverage is biased toward tools with English-language documentation and public repositories. Capability claims for closed commercial platforms cannot be independently verified here. The adversary-side section is deliberately descriptive — capability categories and observed use, with no access or acquisition detail.
CaveatsWhere the rules bend in practice
The methodology above is the intended standard. The catalogue applies it with judgment in a few places worth naming explicitly if you are using this as an audit reference or building on top of it.
Research models vs the three-way split. The split text places research models under Other, but offensive-tuned models such as xOffense and CIPHER are catalogued under Open source with a dedicated Offensive-tuned models category. CIPHER has a public repository; xOffense is paper-only with no published weights or repo at time of writing. They are included as deployable research artefacts, not as benchmarks — but the licence bucket and the written definition do not align literally.
AI-augmented classics at the scope boundary. Nuclei, Semgrep and Caido meet the scope bar clearly — the AI component changes detection or payload generation. Katana, AutoRecon and pwncat-cs are included because their structured output is commonly fed into an LLM prioritisation layer, even though the tools themselves are conventional. They sit in the catalogue as stack components, not as AI-native platforms.
ASM and PTaaS with secondary AI. Several attack-surface and PTaaS entries — Detectify, Intruder, HackerOne, Bugcrowd and others — are included primarily for AI-assisted triage, duplicate detection or platform automation rather than autonomous offensive reasoning. They belong in a landscape view of how AI enters the workflow, but sit at the weaker end of the load-bearing AI threshold.
Category axis is operational, not defined above. Beyond the three-way split, entries are grouped into twelve categories (agentic frameworks, LLM red teaming, AI-augmented classics, exposure validation, and so on). These drive the filter panel and phase map but are not enumerated in the methodology proper — they reflect how practitioners combine tools, not a formal taxonomy.
Primary-source links on catalogue cards. GitHub and official URLs on each card reflect the sourcing hierarchy but were added after the initial catalogue pass. Absence of a link — as with guardrail-free criminal-market LLMs — means no authoritative public source exists, not that the entry is unverified.
Assessing a tool before you trust it
Five questions that separate the usable from the demo-ware, in the order they tend to fail:
| Question | What a good answer looks like |
|---|---|
| Does it install? | Reproducible setup on a clean host. A surprising share of agentic frameworks fail here — initialisation errors, database problems, provider misconfiguration. |
| Can it stay in scope? | Explicit target allowlisting enforced in code, not in the prompt. Prompt-level scoping is not a control. |
| Does it prove the finding? | Deterministic validation or a reproducible proof-of-concept. An LLM asserting exploitability is a hypothesis, not a finding. |
| Is the trail intact? | Full command and response logging, model and version recorded, replayable. Required for client deliverables and for your own regression testing. |
| Where does the data go? | Local model support, or a contractual position on target data leaving your network. This decides whether the tool is usable on a sensitive engagement at all. |