Best AI for Hacking? How to Actually Choose (2026)

Search "best AI for hacking" and you'll get a dozen lists, each crowning a different model, most of them already out of date. That's not laziness. It's that the question has a short shelf life. The model that tops the leaderboard this month gets overtaken next month, and any article built around a single winner is stale before it ranks.

But the deeper problem is that "which model" is the wrong question to lead with. Most security people using AI today are prompting a raw chatbot for one answer at a time, and getting a fraction of what's possible out of it. There's a wide gap between what people do with AI and what a security professional can do with it, and it isn't the model that closes that gap. You need the model, no argument. On its own, though, it's a limited thing: spiky and inconsistent, it forgets you between sessions, and it refuses a lot of legitimate security work by default. The people pulling ahead aren't the ones who found this month's smartest model. They're the ones who built a system around it to direct it. That's where the leverage lives, and it's the thread running through everything below.

So this guide doesn't hand you a winner. It gives you the parts that don't expire: how working pentesters and bug bounty hunters actually use AI (narrower and more honest than the hype), how to judge a model for security specifically, and the part almost nobody explains, which is the three ways to get past the guardrails when the strongest models refuse your work by default. I've just been through the main one myself, across three accounts, so I'll show you exactly how it works.

One line before we go deeper, because the title is broad and the intent here isn't. This is for authorised work: pentesting under contract, bug bounty inside a program's scope, red teaming systems you have written permission to touch. That's not a disclaimer at the bottom of the page. It's the frame the whole thing is built on, and by the end you'll see the access programs are designed around exactly that distinction. Let's get into it.

What Security Pros Actually Do With AI (Not the Hype)

A raw chatbot won't hack for you. From the people doing it for a living, it's a very good assistant that does the boring 80% while you do the part that matters. (Wrap it in the right system and that changes, which is the whole point of this piece, but we'll get there.)

Bugcrowd's 2026 survey of over 2,000 hackers found 82% now use AI in their workflow, up from 64% in 2023. But only 27% believe AI actually outperforms hackers. The pros overwhelmingly treat it as augmentation, not a replacement. (Bugcrowd, Inside the Mind of a Hacker 2026)

What they actually point it at is specific and unglamorous:

Then there's the half the marketing leaves out. Ask hunters where AI fails and they're blunt: business-logic bugs, multi-step chained logic, genuinely novel attack paths. As one put it after testing AI scanners against ten real products, they're good at textbook vulnerabilities and "terrible at understanding business logic… it requires understanding how the pieces connect." The phrase you'll hear again and again is that AI is "a first pass, not a final answer." (r/bugbounty)

AI handles the volume; you supply the judgement. So the real question was never "which model is smartest." It's which model, wrapped in what, run by someone who knows what they're doing. That "wrapped in what" is where the whole thing is won: a raw model you prompt one question at a time is where most people stop, and it's the least you can do with it. The edge is the system you build to direct it.

Send me the book →

By submitting you'll get the book + occasional related emails. Unsubscribe anytime. Privacy.

What That Actually Looks Like

To make that concrete, because "build a system" sounds vague until you see what it does:

Here's one example — and I want to stress one, because it's a single narrow slice of what this does. Reviewing web-app source for vulnerabilities is one job out of dozens. The same infrastructure can be extended, with the right tools and controls, to network recon, cloud misconfiguration review, API fuzzing, phishing-campaign simulation, malware analysis, or stages of a full red-team engagement. I'm using a source-review job here only because it's easy to picture end-to-end.

So here's that one job, handed to my AI infrastructure as a single instruction. Take a set of web-app plugins, download them, run a multi-agent adversarial review over the source (different models arguing about the same code so one isn't marking its own homework), then run the usual tools against them, collect the candidate vulnerabilities, spin up a fresh Docker environment to test in, write an exploit for the most promising finding, run it, and confirm whether it actually works. Then move to the next target and do it again.

I don't sit and drive each of those steps. The system does the download, the review, the tooling, the environment, the exploit attempt, and the proof, then hands me back the ones that are real. My job is to point it at authorised targets, set the standard, and make the final call.

I've run exactly this against a security plugin installed on around four million WordPress sites. The system reviewed the source, identified a known authentication-bypass flaw, stood up a throwaway WordPress in Docker, wrote the exploit, and fired it. One unauthenticated request, no password, and WordPress handed back a valid administrator session. I used a known flaw on purpose here, since I'm not about to publish a live zero-day against four million sites, but the method doesn't care whether a bug has a CVE number yet: it reads the source and finds what's there. The whole chain, from reading the code to proving the exploit in a live environment, ran as one directed job instead of a week of manual work.

That's the difference the whole article is about. Prompting a chatbot for a payload is one keystroke in that chain. What most people call "using AI for security" is that single keystroke, over and over, by hand. What's possible is the whole chain running itself, with you directing it — and again, that source-review job was just one example. The same orchestration pattern can support many kinds of authorised offensive work once you build in the right tools and checks: recon and enumeration, exploit development, credential attacks in an authorised lab, cloud and container review, wireless, social-engineering simulations, malware reverse-engineering, individual stages of red-team campaigns. Many programmatically executable workflows can be built around the same principles, though the tooling, controls, and reliability differ from one to the next. A chatbot's ceiling is one conversation. A system's ceiling is however much you're willing to build.

The catch is that a chain that can prove an exploit can also do real damage if you point it at the wrong thing. That's why the next section isn't optional.

First, the Line That Matters: Authorised Work Only

This one's quick but non-negotiable, because "best AI for hacking" attracts two very different readers.

If you're a penetration tester, a bug bounty hunter working inside a program's rules, or a red teamer with written scope, this is for you, and all of it is aimed at making authorised work faster.

The Benchmarks That Predict Offensive-Security Performance

If you're going to judge a model for security work, judge it on security tasks, not the coding or general-reasoning leaderboards most "best model" lists lean on. There's a specific set built for this, and knowing them is most of the skill. (The general craft of reading any benchmark without being fooled, contamination and gaming and the private-eval habit, I've written up in full in our guide to choosing a model; it applies here unchanged, so I won't repeat it.)

The ones worth knowing, all checked against their source papers:

Here's that point, and it's the one that survives every leaderboard shuffle. In AutoPenBench's 2024 GPT-4o experiment across 33 tasks, a fully autonomous agent solved 21%. Swap the architecture for one where a human decomposes each goal into steps and it solved 64%, three times as many. (arXiv 2410.03225) Raw model scores have shot up since — but that operator gap is the part that persists, and it's why "AI plus a skilled operator beats AI alone" is the durable finding, not this month's benchmark number. First pass, not final answer.

So benchmarks get you a shortlist. But there's a wall every security professional hits within a day, and no benchmark shows it to you.

The Three Ways Past the Guardrails

The wall is refusals. The best-aligned models block a lot of legitimate security work out of the box: explaining how a published CVE is exploited, walking through what a known piece of malware does, writing a realistic phishing sample to test a defence pipeline, generating red-team variations for an authorised engagement. Meta's CyberSecEval 3 gives one concrete data point on how often a safety filter wrongly blocks benign requests. Testing the Llama Guard filter on a borderline-request benchmark, the false-refusal rate came out at 2% as an output-only guard and 10% when used as both an input and output filter. (CyberSecEval 3, arXiv 2408.01605) For a professional, that friction is constant, and it's the real tax on using aligned models for security.

Here is how to get around it, in rough order of how most professionals should weigh the options.

1. Get vetted access (the big one)

The two largest providers now run formal programs that relax their safeguards for vetted professionals. Not a blanket switch-off, but an approved adjustment for the security work you describe. This is the part almost nobody explains, so here's how it actually works. I've just been through both.

Anthropic's Cyber Verification Program (CVP) is free and application-based. You describe the security work you do, provide something that proves you're a real practitioner (a LinkedIn profile, a conference talk, a bug-bounty history, or a security lead who'll vouch), and if approved, Anthropic adjusts its real-time cyber safeguards for your organisation, so Claude will help with dual-use pentesting, bug bounty, and red teaming it would otherwise refuse. (Anthropic CVP application)

Two things I learned doing it that the form doesn't spell out. Approval is tied to a specific organisation ID. It doesn't carry across accounts, so if you work under more than one, you apply for each. I did three; all three came back approved, and each took about twenty minutes, though Anthropic quotes up to a couple of business days. And in my experience the use-case answer wants a concrete task, not a category: "I run Claude against our own and client codebases to review for vulnerabilities and explain the exploitation path," worked far better for me than "we do security." What it never adjusts is genuinely prohibited use. Ransomware and mass data exfiltration stay blocked regardless. That's the authorisation line, enforced in the product.

OpenAI's Trusted Access for Cyber (TAC) is the heavier lift, and worth knowing before you start. It's an enterprise intake, not a quick form: you apply as an organisation (there's a separate individual path too), hand over your OpenAI org ID, verify your identity with a government ID and a face scan, complete a separate business-verification step, and sign a set of security-posture attestations as legally binding, including SSO and MFA and formal certifications like SOC 2 or ISO 27001. Access is layered: standard GPT-5.5, GPT-5.5 with TAC's adjusted safeguards for approved defensive and dual-use work, and a separately-approved cyber-specialised model on top. The heavier certifications bite hardest on that most-permissive layer. Whatever you apply for, don't attest to a certification you don't hold. The form makes that a material breach, not an optimistic tick-box. (OpenAI TAC application)

I've applied for it myself: submitted the application, cleared the government-ID and face-scan check and the separate business-verification step, all of which moved quickly. The final approval decision is still in review at the time of writing, so I can't yet tell you first-hand what the top tier unlocks. I'll update this once it lands.

Those two are the whole of the formal vetted-access route today — Anthropic and OpenAI are the only providers running one. The other hosted frontier models are worth knowing but sit outside it. xAI's Grok tends to refuse less offensive-security work by default and has sat near the top of the public Cybench board, and Google's Gemini is the strong all-rounder with a huge context window. Neither runs a comparable authorised-access program, so for dual-use work that an aligned model would otherwise block, they're situational: useful when they'll do the task, with no recourse when they won't. For authorised work you want a supported route, the two programs above are still the clean answer.

2. Go local — when the data can't leave your machine

The second route removes the provider's enforcement layer: run an open-weight model on your own hardware. Two reasons a professional cares. Depending on the model, it refuses far less of your security work, and there's no program to apply to (some open models still carry trained-in refusals, so this varies). And, more importantly for anyone under an NDA, a properly configured fully-local stack keeps your prompts and your client's data on your own machine, where a hosted API would ship them to a third party. (Worth being precise: "local" only holds if the whole stack is local, so watch for telemetry, update checks, or plugins that phone home.) For contracted engagement work, that data-residency point is often the deciding factor, not a nice-to-have.

The honest catch: several of the strongest, loosest open models come from Chinese labs (the GLM, DeepSeek, and Qwen families), and looser guardrails cut both ways. You inherit whatever bias and provenance came baked into weights you can't fully inspect. Running them locally rather than through a hosted API at least keeps the data-residency win intact. The mechanics of picking and running a local model I cover in the choosing-a-model guide and the free-API setup guide, so I won't duplicate them here.

You don't have to self-host to try the open models, either. GLM, DeepSeek, Qwen and Kimi are all reachable through hosted gateways like OpenRouter, DeepInfra, Novita, Together, Fireworks and SiliconFlow. Going direct to the vendor — Z.ai for GLM, DeepSeek's own API — is usually cheaper still than routing through an aggregator, so if cost matters and you're only testing capability, direct wins. But whichever route you take, it trades the data-residency win straight back — your prompts leave your machine again — so treat it as a way to test, not to handle NDA'd client data, and be doubly careful about sending anything confidential to an endpoint whose provenance you can't audit. And don't write the open tier off on capability: GLM-5.2 has beaten Claude on Semgrep's IDOR detection, so for cheap static-analysis triage it's genuinely competitive with the frontier, at a fraction of the cost.

3. Tune your own (real, but not for most hunters)

The advanced end: fine-tune an open model on offensive-security data, which can reduce how much it refuses and sharpen it on the specific work, though how much you gain is evaluation-dependent, not guaranteed. It's more accessible than it sounds. One hobbyist recipe fine-tuned a small Qwen model on about 2,800 examples drawn from public sources like GTFOBins, HackTricks, and PayloadsAllTheThings, and trained it on a single consumer GPU in under twenty minutes. And at lab scale, tuned mid-size models can punch above their weight. xOffense, a Qwen3-32B model fine-tuned on chain-of-thought pentest data and wrapped in a multi-agent framework, reported a 79.17% sub-task completion rate on the AutoPenBench and AI-Pentest benchmarks, ahead of the far larger general-purpose Llama-3.1-405B at 69%. Read that number honestly: it's a lab benchmark, it counts a sub-task as solved if any of five runs succeeds (the all-five-runs figure was lower), and it credits the whole system, not the model alone. (arXiv 2509.13021) Cisco's Foundation-Sec-8B makes a similar point on the defensive side, an 8B security-tuned model rivalling models nearly ten times its size.

But be honest about who it's for. For a team or company with data and an evaluation pipeline, fine-tuning pays off, and that's where every credible result above comes from. For a solo bug bounty hunter, it mostly doesn't: security knowledge goes stale fast (tens of thousands of new CVEs a year), a fine-tuned model ages with it, and retraining is costly. That's exactly why the working hunters in the survey don't train their own weights. They prompt and orchestrate a strong base model and feed it fresh context with retrieval. The edge, for almost everyone, isn't a custom model. It's the system you build around a good one. (If you want to see what a real security fine-tune looks like, the open ones, WhiteRabbitNeo and Foundation-Sec-8B, are on Hugging Face to inspect.)

However you get to an unrefusing model, don't lock yourself to one provider. A local router or proxy, like 9Router or Claude Code Router (tools that run on your own machine), lets you point the same tooling (Claude Code, Cursor, Codex, whatever you use) at different model backends and switch between them, including the local models you're running yourself. That's the part that matters here: a hosted aggregator only reaches the models it hosts, whereas a local router puts your own models in the mix and keeps the switching on your machine. It's a portability layer, not a way around anyone's guardrails, so a request sent to an aligned model through any proxy still gets refused the same way. The setup, including pointing your coding assistant at a different model, is in our free-API guide.

Send me the book →

By submitting you'll get the book + occasional related emails. Unsubscribe anytime. Privacy.

The Actual Tool List Lives Here

You'll notice I haven't handed you a ranked list of tools. That's deliberate. We already maintain one, and keeping it in a static article would just let it rot. Our AI security tool directory is a filterable, regularly-updated list of the security-relevant AI tools with my verdict on each. If you want the inventory, that's the place; this article is about how to choose and access, which a directory can't be.

Keeping Your Pick Current

The models move monthly, so treat your choice as a subscription, not a purchase. The habit takes about ten minutes a month: check the security benchmarks for new entrants, then confirm your shortlist on a handful of your own real tasks, the ones you actually run, scored by you, since that's the one test a vendor can't game. The full version of that routine is in our choosing-a-model guide; the security-specific tweak is just swapping the coding leaderboards for the CTF ones above.

The model does the work, but it isn't the edge. On its own an LLM is the labourer: fast, capable, and spiky. The edge is the system you build around it. Orchestration, so it runs a fleet of agents at once instead of one chat at a time. Governance, so a bad output gets caught before it ships. Memory, so the problems you solve stay solved instead of starting fresh every session. A capable model inside a strong system will out-produce a brilliant model with none, repeatedly and by a wide margin.

That's the real gap in security right now. Most people are prompting a raw model and calling it AI; the ones pulling ahead have stopped shopping for models and started building the infrastructure that directs them. That's what we teach at StationX: how to turn the assistant you already have into an AI-driven security engineering system, with the orchestration and governance and compounding memory, that works the way you do. Get authorised access to a good model, then build the system around it. The model on top this month matters a lot less than what you wrap it in.

Frequently Asked Questions

About the Author

Nathan House, Founder & CEO of StationX

Nathan House has 30 years of hands-on cybersecurity experience and is Cambridge-educated, holding CISSP, CISA, CISM, OSCP, CEH, and SABSA. He founded StationX in 1999 — one of the UK’s first cybersecurity companies — and has secured £71 billion in UK mobile banking transactions and the London 2012 Olympics, advising clients including Microsoft, Cisco, BP, Vodafone, and VISA. He authored the world’s most popular cybersecurity course — a #1 Udemy bestseller taken by over 500,000 students — and was named Cyber Security Educator of the Year 2020, AI Security Educator of the Year, and a UK Top 25 Security Influencer 2025. A DEF CON speaker and featured expert on CNN, Fox News, NBC, and the BBC, Nathan leads StationX’s training of more than half a million students worldwide.