Using AI as a Security Practitioner: What It's Actually Good For

The AI red teaming roadmap on this site is explicit that it's about attacking AI systems, not using AI tools to help with traditional hacking. This guide is the other half of that: not "is AI going to replace hackers" — a question that mostly generates hot takes — but the narrower, more useful one: what specific tasks does it actually help with right now, and where does it still need a human holding the leash.

What AI is actually good for here

Grunt work at a scale you wouldn't do by hand. Cross-referencing large public datasets, checking a long list of candidates against a narrower set of criteria, pulling the one relevant detail out of a wall of documentation — this is exactly the kind of repetitive, well-defined, high-volume work that used to mean either skipping it or paying someone to do it manually.

Long-context understanding. Reviewing an entire codebase, a lengthy advisory alongside its supporting research, or a large log file in one pass — without losing track of something mentioned three files ago — is a genuinely different capability than the shorter-context tools most people are used to, and it matters for anything that requires holding a lot of related detail at once.

Multi-step, tool-calling work that runs unattended. Research something, act on what it finds, check whether that action actually worked, adjust and retry if it didn't, then document precisely what was and wasn't confirmed — that's a long sequence of dependent steps, not a single prompt-and-response. Agentic tool use is what makes this kind of multi-hour, multi-step work practical to run on a schedule instead of requiring a human to babysit every step.

A concrete example: how pwnmi.com actually uses this

This isn't theoretical. The CVE labs on this site are produced by exactly this kind of automated research-and-verification process, not written from a CVE description and hoped to be accurate. Before anything gets published, the underlying exploit is actually run against a live, isolated target and the result is directly observed — not assumed to work because the write-up reads convincingly.

CVE-2026-62183 (Apache Syncope), CVE-2026-53595 (FreeScout), and CVE-2026-11349 (WordPress plugin SQLi) all went through this. A human reads and verifies every one before it goes live — the automation drafts, it doesn't get the final word.

Where it still needs a human

Verifying claims, not trusting output. The single most important habit in the pipeline above is the explicit distinction between "verified — the exploit chain was actually run against a live container and the result observed directly" and "best-effort — this looks right but wasn't confirmed working." An agent will produce output either way; only a human (or a second, skeptical verification pass) catches the difference. Anything an AI tool tells you about a target — a version number, a supposedly-open port, a "confirmed" vulnerability — deserves the same independent verification you'd apply to a tool like Nikto or sqlmap: a fast first pass, not a final answer.

Exploitation judgment. Deciding whether a technique is safe to run against a specific target, understanding what could actually break versus what's merely noisy, recognizing when a "quick check" would cross into something that needs separate authorization — none of this is something to hand to an automated pipeline. The CVE lab pipeline above only ever runs against infrastructure it stands up itself, in an isolated Docker network, specifically because that judgment call has already been made in advance rather than left to the agent mid-run.

Scope and authorization. An agent has no inherent sense of what's in scope. That boundary has to be set by a human before anything runs — the same rule that applies throughout this site, from the OSINT fundamentals guide's point that "public information" isn't the same as "in scope," to the script privesc checklist's emphasis on only running against infrastructure you're authorized to touch.

If you want to build something like this yourself

The practical constraint on running this kind of long, multi-step agentic work isn't the idea, it's having somewhere to actually run the model. If you're experimenting with a large open-weight model rather than a proprietary API, self-hosting the inference layer is a real option worth knowing about — you get a specific model rather than whatever a closed API decides to serve you, without needing to provision and manage GPU infrastructure yourself.

Moonshot AI's Kimi K3 is a useful example of why model choice matters for this kind of work specifically: it's a roughly 2.8-trillion-parameter open-weight model — currently the largest openly-released model in that class — with a 1-million-token context window, which is genuinely relevant for reviewing an entire codebase or a long log capture in a single pass rather than splitting it into chunks and losing cross-file context. It uses a sparse mixture-of-experts architecture (896 experts, 16 active per token), which is what keeps inference cost and latency reasonable despite the model's raw size — the kind of design detail that actually matters if you're running many long agentic sessions rather than one-off queries.

For running a model like this without managing your own GPU cluster, DigitalOcean's Serverless Inference is a pay-as-you-go option worth a look. Disclosure: that's an affiliate link.

Common mistakes

• Trusting AI-generated findings without independent verification. The gap between "the agent said it's vulnerable" and "the exploit was actually confirmed against a live target" is exactly where false positives live.
• Using AI for the exploitation decision instead of just the grunt work around it. Automating recon and analysis is a force multiplier. Automating the judgment call of whether and how to actually exploit something is a different, much riskier proposition.
• Assuming the newest or largest model is automatically the right fit. For most of this kind of work, the binding constraint is context length or tool-calling reliability for your specific workflow, not raw benchmark scores. A smaller model that reliably calls tools in the right sequence beats a larger one that doesn't.

Next step

For the security-focused flip side of this topic — attacking AI systems rather than using them — see the AI red teaming roadmap. To see this approach applied end-to-end, start with any of the CVE labs, or Docker for Security Labs for the infrastructure piece underneath them.