An exploit can be proof without being harm. That distinction drives the design of Pentrova’s sealed sandbox: to confirm impact, the platform reproduces an exploit with the minimum action needed to demonstrate control — and nothing more.
This post explains the read-only equivalents Pentrova substitutes per vulnerability class, how customer data is protected at the boundary, and why this makes the platform safe to point at live systems.
The principle: demonstrate control, don’t exercise it#
A destructive proof — deleting a record, writing a file, transferring funds — proves a vulnerability is real, but at a cost no customer should have to pay. The insight is that demonstrating control and exercising it destructively are different actions. You can prove you could delete the row by reading a value only the privileged path exposes; you do not have to delete the row.
So Pentrova reproduces each class with the smallest non-destructive action that still constitutes proof.
Read-only equivalents by class#
| Vulnerability class | Destructive proof (avoided) | Read-only equivalent (used) |
|---|---|---|
| Remote code execution | Run arbitrary destructive commands | Read back an identity: id, hostname against a redacted target |
| Local file inclusion | Read sensitive system files | Read a known-safe canary file |
| SSRF | Hit internal mutating endpoints | Fetch an internal canary URL with a fixed response |
| SQL injection | Modify or drop data | Extract a single benign marker value |
None of these mutate the target, and all of them are sufficient to demonstrate the issue is real. The same guardrails apply at every step of an escalation chain, so even multi-step impact is proven without destructive side effects.
Conservative by default#
The commitment is conservative by default: destructive actions — writes, deletes, mutating operations — are held back in favour of read-only equivalents, and customer data is redacted at the boundary before any artifact leaves the sandbox. The exploit runs inside an ephemeral, isolated environment; the resulting evidence bundle is what engineering replays, not the live exploit against production.
Why this matters for production testing#
This is what lets Pentrova run against live systems safely. Because exploitation is read-dominant and bounded, you can scope a conservative run against production and full chains against staging — the pattern recommended for both Web App and API Pentesting. The proof is real; the blast radius is zero.
Key takeaways#
- Demonstrating control and exercising it destructively are different actions; proof needs only the former.
- Each class has a read-only equivalent — RCE reads an identity, LFI reads a canary file, fetches a fixed URL.
- Destructive actions are held back by default and customer data is redacted at the sandbox boundary.
- Read-dominant, bounded exploitation is what makes live-system testing safe.
FAQ#
Does a non-destructive proof actually prove the vulnerability? Yes. Reading back a host identity proves code execution; reading a canary file proves file inclusion. The read-only action exercises the same vulnerable path — it simply stops at proof rather than continuing to damage.
Can I run Pentrova against production safely? Yes, with scoping. Exploitation is read-dominant, runs under sandbox guardrails, and redacts data at the boundary. The recommended pattern is full chains in staging and conservative, scoped runs against production.
What leaves the sandbox? A redacted evidence bundle — the request/response captures, the read-only proof artifact, and a reproducible command. Customer data is redacted at the boundary before anything is exported.
See the sandbox in the platform pipeline, or start a free engagement.