pentest-ai-agents: 50 Claude Code Subagents for Offensive Security Work
Turn Claude Code into your offensive security research assistant. Specialized AI subagents for authorized penetration testing plan engagements, analyze recon, research exploits, build detections, audit STIGs, and write reports.
At a glance
- What is it?
- A file-copy install that routes Claude Code to specialist subagents for recon, exploitation, post-exploitation and reporting. The value is the routing and the scope guard, not the tooling, which you still have to install yourself.
- Who is it for?
- Adopt it if you already run Claude Code on authorized engagements and want a routing layer plus a findings database, and check that your target host has the underlying binaries that db/doctor.sh reports as missing before you trust any agent's suggested command line. Skip it if you want a scanner that finds things on its own, or if your engagement cannot tolerate prompt content leaving your machine.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 30 days ago.
- What is it written in?
- Mainly Shell, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem pentest-ai-agents actually solves
A general-purpose coding assistant asked to help with a penetration test produces generic answers. It does not know which enumeration order makes sense against Active Directory, it does not know that a finding needs a detection counterpart written alongside it, and it has no memory of what the previous phase of the engagement turned up. The repository's own framing is that it turns Claude into an offensive security research assistant by giving each domain its own subagent with domain-specific instructions. The README describes the intended workflow in three steps: install the agent files, open Claude Code, describe your task, and Claude routes to the right specialist. That routing is the product. The agents are markdown instruction files, not binaries, and the README states plainly that there are no servers, no Python dependencies, and no setup beyond copying files. The audience is therefore narrow and specific: people who already hold an authorized engagement, already use Claude Code, and want the assistant to behave like a domain specialist instead of a generalist. Bug bounty hunters, CTF players, red team operators and STIG auditors are the groups the topic list and agent names point at.
How routing and the Tier 1 / Tier 2 split work
The repository ships an agent map as a Mermaid flowchart, and it is the clearest statement of the architecture. Flow starts at engagement-planner, which hands off to opsec-anonymizer and threat-modeler. Recon runs osint-collector into recon-advisor into vuln-scanner, and vuln-scanner fans out to the exploitation cluster: web-hunter, api-security, bizlogic-hunter, bug-bounty, ad-attacker, cloud-security, mobile-pentester, wireless-pentester, llm-redteam. Post-exploitation agents sit downstream of the exploitation ones, so ad-attacker feeds credential-tester and privesc-advisor, while cloud-security feeds container-breakout, which also feeds privesc-advisor. Several agents converge on report-generator, with detection-engineer and forensics-analyst forming a defensive branch and stig-analyst reaching the report directly. Some edges are dotted: ctf-solver runs solo into report-generator, and cicd-redteam runs through a pipeline into swarm-orchestrator. The README states the split explicitly. Tier 1 agents are advisory and routable from any task. Tier 2 agents are execution-capable, require a declared scope, and live in the offensive operations cluster. That is a permission boundary expressed through file placement, and it is the most interesting design decision in the repository. The v3.1 notes add slash commands that make the routing inspectable: /recommend takes a freeform task and returns the right agent plus concrete commands, and /agents-for filters the catalog by tag.
Installing agents, slash commands and the Docker bundle
There are two install paths. The plugin path is two commands: /plugin marketplace add 0xSteph/pentest-ai-agents followed by /plugin install pentest-ai-agents@pentest-ai-agents. The older curl path through install.sh still works, and the v3.3 notes record fixes to it: curl piped to bash no longer crashes under set -u, the clone URL in the one-liner was corrected, slash commands now install alongside the agents, and --uninstall removes everything. There is also an opt-in flag, install.sh --tools, described in the truncated README as an opt-in installer. The v3.3 notes describe a minimal offline Docker bundle with a digest-pinned base and a non-root user, and state that it is packaging only with no tooling baked in. That last point matters: the container gives you the agent files, not nmap, not Ghidra, not Sliver. To find out what is actually on your machine, the project ships db/doctor.sh, which audits installed CLI tools grouped by agent and prints a tick or cross per tool with install hints. Findings storage is a SQLite database. The v3.2 notes describe Findings DB v2 adding a vulns.tool_used column so findings can be filtered by the tool that produced them, plus new indexes on cve and tool_used, with existing engagements migrated forward by db/migrate.sh. A typical workflow is: run db/doctor.sh, install what is missing, open Claude Code, use /recommend with your task, work the engagement, and write findings into the database so report-generator has structured input.
The scope guard is the load-bearing component
The _scope-guard.md file is what separates this from a prompt pack. The v3.2 notes describe a tightened scope guard with an explicit hard-refusal list covering denial of service, mass scanning, unattended worms, false-flag operations and safety-of-life systems. The v3.3 notes state that every Bash-capable Tier 2 agent is required to carry the scope-guard block, and that a SHA-pinned, least-privilege CI workflow validates each agent's frontmatter, enforces that requirement, checks the plugin manifests and smoke-tests the installer. The same release notes admit that cicd-redteam was Bash-capable but missing the block, and that the new CI check would have caught it. Two things follow. First, the enforcement is a static check on markdown, not a runtime sandbox. An agent without the block can still be invoked; nothing in the described material prevents it. Second, the gap existed in a released version, which tells you the check is new and the agent set is large enough that manual review had already failed once. Treat the CI validator as a regression net, not a guarantee, and read the frontmatter of any Bash-capable agent before you enable it on live infrastructure. The README also carries a Legal section and the project is MIT licensed.
Where the agent-file approach breaks down
The agents are instruction files. They do not execute anything themselves, and the README's coverage section tracks 80-plus tools that the agents reference rather than bundle. If a tool is absent, the agent's suggested command line fails at the shell, which is exactly the failure db/doctor.sh exists to surface. A second limitation is context cost. The README has a Token Optimization section, and the existence of that section is itself a signal: fifty agents with domain knowledge consume context, and the routing layer has to pick correctly from a large catalog. A misroute sends you to an agent whose instructions do not match your target class. Third, the project is Shell and markdown. There is no test suite for agent behaviour in the material provided, only frontmatter validation and an installer smoke test. Whether an agent gives good advice on your specific target is not something the repository can verify for you. Finally, the whole design assumes you are comfortable sending engagement context to a hosted model. The README lists a Local Models section, but the material here does not describe which local runtimes are supported or how routing behaves against them, so that path is unverified from what is available.
How this differs from a scanner or a bare prompt library
The nearest comparison in kind is Nuclei. Nuclei is a scanner: you point it at a target, it runs signed YAML templates and returns matches. It finds things without a model in the loop, and its output is deterministic and reproducible. pentest-ai-agents does none of that. It does not scan. It routes a request to an agent that knows which command to suggest, how to interpret the output, and what to write down. The two are complementary rather than competing: an agent may well suggest running a scanner, and the v3.2 findings schema has a tool_used column precisely because findings come from tools the agents invoke. The other comparison is a plain Claude Code setup with a hand-written system prompt. The difference there is structure. A single prompt has no Tier 1 and Tier 2 boundary, no per-agent frontmatter to validate, no Mermaid map showing which agent feeds which, and no SQLite schema with a migration script. Whether that structure earns its keep depends on whether you run enough engagements to benefit from a repeatable phase order. For a one-off assessment, a prompt and a notes file are cheaper.
Maintenance, releases and what the MIT licence does not cover
The release cadence visible in the material is roughly quarterly: v3.2.0 in May 2026 added c2-operator, container-breakout, opsec-anonymizer and llm-redteam; v3.4.0 in August 2026 added fix-verifier and supply-chain-auditor; the README's own What's New section is still headed v3.3, which added fifteen agents and the plugin packaging. The last push recorded is 2026-08-16, so the repository is active. Upgrade cost is low by construction, because the artifacts are text files plus an installer and a database migration script. The real maintenance burden is external: the agents reference tool command lines, and those tools change their flags. Nothing in the material describes a process for tracking upstream tool changes, so a stale agent suggestion is a plausible failure mode between releases. On licensing, the repository is MIT, which permits commercial use and modification with attribution and no warranty. That covers the agent files. It does not cover the tools the agents tell you to run, which carry their own licences, and several offensive security tools have terms that restrict commercial or non-authorized use. The README has a Legal section; read it, and treat the MIT grant as covering this repository only. This is not legal advice.
Editorial conclusion
Adopt it if you already run Claude Code on authorized engagements and want a routing layer plus a findings database, and check that your target host has the underlying binaries that db/doctor.sh reports as missing before you trust any agent's suggested command line. Skip it if you want a scanner that finds things on its own, or if your engagement cannot tolerate prompt content leaving your machine. Verify first that the scope-guard block is present in every Bash-capable agent you plan to enable.
Community notes