Using ScanSuite

Proof of concept

Generate an exploit, edit it, run it in a sandbox, and refactor it until it works.

An exploit that runs settles the severity question directly. From the finding view you can generate a proof of concept, read it, change it, run it, and hand it back to the model to improve.

Generate

Click Generate PoC on a finding. The model builds an exploit from the finding's details, with progress streamed as it works.

The result is Python you can read. That matters: an AI verdict you cannot audit is just a different kind of false positive.

Generated proof-of-concept code
A generated proof of concept, editable in place, with a usage example below

Edit and save

The generated code is editable in place. Adjust the target, the payload or the success condition, then save it to the finding.

Run

Execute the proof of concept against the target from the finding view and read the exit code and output.

This runs real exploit code against the target. Only do it against systems you are authorised to test, and understand that a working exploit may change state on the target even when it is only trying to prove access.

Proof-of-concept execution result
The execution result: the command, exit code, stdout and stderr, with Refactor PoC to hand it back to the model

Execution happens in a sandboxed container. If a proof of concept fails with a ModuleNotFoundError rather than a target error, the sandbox is missing a library the generated exploit reached for — read the stderr, and either constrain the code to what the sandbox provides or ask an administrator to extend the sandbox image.

Refactor

If the proof of concept does not work, hand it back to the model with the success condition and let it revise. This is usually faster than debugging a generated exploit by hand, because the model has the finding's evidence in front of it.

Where this fits

The AI Pentest agent proves its findings the same way, on its own. This page is about doing it yourself, against any finding in Vulnerability Management.

The exploit research path is worth knowing: look a product and version up in the exploitable vulnerabilities database, fetch the referenced exploit, and generate the proof of concept from that rather than from the finding alone. A real published exploit is a much better starting point than a description.

Last reviewed 2026-08-16