For confirmed Critical and High findings in the classes it 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 (private and internal networks are blocked), and captures the result as evidence. Replays are separate: they re-send only GET and HEAD requests from a fresh client, outside the sandbox, and their result is evidence for the AI review, never a verdict on its own. The sandbox’s behaviour is conservative by default.
Proof with safe defaults#
Destructive payloads and methods — writes, deletes, mutating operations — are blocked by default in favour of read-only equivalents, and request rates are limited. Pentrova masks the secrets it recognises (passwords, tokens, API keys and session values) in exports and the live scan view; it does not remove personal data, so treat evidence as sensitive. The aim is real proof an exploit works. Automated testing can still change data or trigger alerts, so test a staging copy where you can, and take backups before testing production.
What the sandbox produces#
When a check retrieves a proof, the captured output and the request behind it are attached to the finding. Your engineers can copy the captured request as cURL and re-send it in staging — without needing Pentrova’s tooling.
Where it applies#
Sandbox checks are attempted for confirmed Critical and High findings in the supported classes, and not every check retrieves a proof. Every other finding carries the evidence captured from your target, such as its request and response.