AI Pentest
An agent that plans an engagement, runs the tools, and proves what it finds.
Give the agent a scope and a sentence of instruction. It plans the engagement, runs the tools, improvises when the plan stalls, and comes back with findings it has proved.
Starting an engagement
AI Pentest is selectable from both scan pages, each validating targets for its own domain:
| Page | Targets |
|---|---|
| Dynamic Analysis page | URL targets. Tick AI Pentest and fill in the Instructions field. |
| Infrastructure page | IP, CIDR or host targets. Tick AI Pentest under the Vulnerability Scan type and fill in Instructions. |
On the Infrastructure page, run AI Pentest under the default Vulnerability Scan type. Selecting a dropdown scan type such as Network Discovery, OSINT, Patching or Docker Image restricts the run to that single scanner.
When AI Pentest is selected it supersedes any other engine you have checked. The agent runs those scanners itself, as tools, when it decides they are useful.
The instructions field
There is no scan profile to tune and no attack tree to pre-build. Scope, credentials if you have them, and what you care about:
Enumerate services, prioritize SMB and web, and verify exploitable findings with a PoC.How the engagement runs
The agent follows a real engagement workflow rather than a flat loop. Each phase reads a durable engagement journal, so nothing is re-run and nothing is forgotten between phases.
- 01Plan
The model returns an ordered plan: steps with rationale, the tools each needs, the targets it touches, the outcome it expects, and what depends on what.
- 02Execute
A bounded tool-calling loop runs one plan step at a time. Every call and every result is recorded to the journal.
- 03Analyze
The step's raw output becomes structured observations, candidate findings, proof-of-concept opportunities and a shortlist of tools worth trying next.
- 04Ideate
A dedicated phase brainstorms attacks the plan missed, working from an attack-technique cheat sheet, and records them as leads on the attack tree.
- 05Replan
Completed steps are marked done, dead ends skipped, and high-value leads promoted into new plan steps. The plan is amended, not restarted.
- 06Report
Confirmed findings are written up as markdown and XLSX with their evidence, chained where one finding enabled another, and persisted through the same pipeline as every classic scanner.
What the agent can reach for
Forty-four tools, from a full OSINT bundle down to a single crafted HTTP request.
| Family | Tools |
|---|---|
| Recon bundles | Subdomain and OSINT enumeration, host discovery, technology fingerprinting, certificate-transparency origin discovery, DNS recon, Shodan lookups, and endpoint and secret extraction from JavaScript. |
| Web scan bundles | Quick, balanced, API and deep web scans, each threaded with the engagement authentication so post-login surface is actually tested. |
| Enterprise scanners | Nessus, OpenVAS and Acunetix driven by API — submitted, polled and parsed — with findings returned into the agent context rather than a separate report. |
| Improvisation | An allow-listed command runner (nmap with NSE, httpx, gobuster, naabu, nuclei and more) with arguments the model chooses, plus Nuclei templates written on the fly. |
| Interactive HTTP | Session-persistent login, parameter fuzzing with response diffing, request comparison for access-control and IDOR gaps, and credential-reuse pivoting. |
| Exploit research | Look a product and version up in the exploitable-CVE database, fetch the referenced exploit, generate a Python proof of concept, run it in a sandbox — and record the finding only if it worked. |
Safety rails
These are enforced in code, not asked for in a prompt:
- Scope lock. Every tool call is checked against an allow-list of hostnames, IPs, CIDRs and URLs before a container or HTTP request is issued. A scope violation is returned to the model as a tool error, never executed.
- No shell. The command runner accepts only allow-listed binaries, with shell-metacharacter and out-of-scope-host tokens rejected.
- Exploit pages only from the database. The page fetcher will only retrieve URLs that a prior database lookup returned, so it cannot be turned into an arbitrary-URL fetcher.
- Sandboxed execution. Generated proofs of concept run in a sandbox.
- Budgets. Maximum cycles, maximum execution rounds per step, and a wall clock limit bound every engagement.
This is an active penetration test that generates and runs exploit code. Only point it at systems you are authorised to test, and prefer an environment where an unexpected side effect is survivable. The budgets are safety rails against runaway cost, not a guarantee of non-disruption.
Requirements
- An AI provider configured — see AI providers and cost.
- For the enterprise scanner tools, Nessus, OpenVAS or Acunetix credentials in Settings.
- For Shodan lookups, a Shodan API key.
Where the results go
Findings are persisted through the same pipeline as every other engine, so they appear in Vulnerability Management alongside the rest. The markdown and XLSX engagement reports are available from the Report button in Scan History.
Last reviewed 2026-08-16