Pentrova decides whether a candidate finding reaches your queue by AI review of the evidence captured from your target. A finding only reaches your queue when that review confirms it; findings that are not confirmed never reach it.
What verification produces#
For every finding in your queue you get the evidence behind the decision:
- Where the finding has one, the HTTP exchange that demonstrates the issue — request headers, body, response headers, and the relevant response excerpt.
- For confirmed Critical and High findings in the classes the sandbox supports (such as RCE, LFI, , , and ), Pentrova attempts a proof-of-concept check from an isolated sandbox that can reach only the hosts you have authorised. When the check retrieves a proof, the captured output is attached to the finding.
- For blind classes (blind , blind , blind ), the out-of-band callback that shows the target reached out.
Where the replay check fits#
Where a finding can be re-checked with a read-only GET or HEAD request, Pentrova re-sends it once from a fresh HTTP client and compares the response with a clean baseline. The result is one piece of evidence the AI review weighs; it never confirms a finding on its own. State-changing requests are never re-sent, out-of-band, passive and timing findings skip this check, and it runs directly, not inside the sandbox.
Findings you can re-check yourself#
Where a finding has a captured HTTP exchange, you can copy it as a cURL command or raw HTTP, or download it as Markdown or HAR, and re-send it in staging before touching the codebase. The point of verification is that the “is this a real bug?” conversation starts from evidence by the time the finding lands.
Passive observations#
Configuration findings — missing security headers, weak TLS, insecure cookies — are direct observations of the response and are reported as-is, with the evidence attached.