Proof of concept
Generate an exploit, edit it, run it in a sandbox, and refactor it until it works.
A finding that ships with an exploit that runs does not get argued about in triage. 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.
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.
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 uses the same generation and sandboxed execution internally — it records a finding only if the proof of concept actually ran. What this page describes is the same capability, driven by you, 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