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 a finding's validation details you can generate a proof of concept, read it, change it, run it, and hand it back to the model to improve.
Before you start
- The finding has validation details: its Validation column shows a chip you can click. A finding marked Unvalidated — added by hand, or from a scanner that does not validate — has no Generate PoC button; prove it with an AI Pentest engagement instead.
- AI is set up for the team, and the PoC generation task has a model that answers; see AI providers and cost.
- Generating, saving and refactoring need the Vulnerability manager, Operator or Team admin role. Running a proof of concept needs Operator or Team admin.
Generate
On the Vulnerabilities page, click the chip in the finding's Validation column.
Check: the Finding Validation window opens.
Click Generate PoC. The model builds an exploit from the finding's details and its reachability analysis, with progress shown as it works.
Check: an Exploitation PoC section appears, with Generated and the time.
The result is Python you can read, a Usage Example (the command that runs it) and the Success Condition it checks.
| Control | What it does |
|---|---|
| Copy PoC code | Copies the exploit code. |
| Save (under the code) | Stores your edits to the code with the finding. |
| Copy usage example | Copies the command. |
| Save (under the usage example) | Stores your edits to the command, for example a different target or arguments. |
| Run PoC | Runs the usage example and shows the Execution Result. |
| Success Condition | Collapsed; expand it to read what counts as a successful exploit. |
| Refactor PoC | Under the execution result: hands the code, the command, the success condition and the last result back to the model to revise. |
Edit and save
The code and the usage example are editable in place. Adjust the payload in the code, or the target and arguments in the usage example, and click Save under each to store it with the finding.
Run
Running a proof of concept sends real exploit code to the target.
A person who is authorised to test that target decides to run it; an agent never clicks Run PoC on its own.
Click Run PoC to execute the usage example against the target, and read the exit code, stdout and stderr under Execution Result.
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.
A proof of concept runs isolated from the rest of the installation, with a 60-second time limit and limits on memory, processes and files. If it fails with a ModuleNotFoundError rather than a target error, the generated code reached for a library that is not available there: read the stderr, and either change the code to use what is available or ask an administrator to add the library.
Refactor
If the proof of concept does not work, click Refactor PoC under the execution result. The model revises the code and the usage example using the last result. This is usually faster than debugging a generated exploit by hand.
Where this fits
The AI Pentest proves its findings the same way, on its own. This page is about doing it yourself for a finding in Vulnerability Management.
Look the product and version up in the exploitable vulnerabilities database, open the referenced exploit, and use it to shape the proof of concept. A real published exploit is a much better starting point than a description.
Last reviewed 2026-10-19