A finding reaches your queue only when AI review of the evidence captured from your target confirms it. The replay check is one of the inputs to that review. This post walks through what the check does, what it deliberately does not do, and how its result is used.
If you want the design philosophy behind keeping the decision in one gate, read the verifier design notes; this post is the mechanics.
Stage one: a fresh client, read-only requests only#
Where a candidate finding comes with a GET or HEAD request, the replay check re-sends that request once, from a fresh HTTP client with no inherited state, and captures the response.
The fresh client is the point. A result that only shows up with the original session’s warmed state is weaker evidence than one that shows up from scratch. The check is also deliberately limited: state-changing requests (POST, PUT, PATCH, DELETE) are never re-sent, and out-of-band, passive and timing findings skip the check. It runs directly against the target, not inside the sandbox.
Stage two: comparison with a clean baseline#
The response is compared with a clean baseline. The outcome is one of four results: reproduced, not reproduced, inconclusive or skipped (for a request the check does not re-send).
None of these results publishes or drops a finding on its own. A “not reproduced” result is weighed with everything else the agents captured; a “reproduced” result does not bypass the review.
Stage three: the AI review decides#
The replay result joins the rest of the evidence captured from your target — the original request and response, out-of-band callbacks, and any sandbox proof — and the AI review decides. A finding it confirms reaches your queue; a finding it does not confirm never does. A finding can be confirmed without a replay at all, on the evidence the agents captured.
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 yourself against a fix branch.
Why this discipline matters#
The triage tax on most security tooling is the cost of sorting real issues from noise. Pentrova keeps unconfirmed findings out of your queue, and the replay check gives the AI review one more piece of evidence where a read-only re-check is safe. Keeping the check narrow — read-only requests, one re-send, no state changes — is what makes it safe to run against a live target.
Key takeaways#
- The replay check re-sends a GET or HEAD request once from a fresh HTTP client; state-changing requests are never re-sent.
- It compares the response with a clean baseline and reports reproduced, not reproduced, inconclusive or skipped.
- Its result is evidence for the AI review, never a verdict on its own, and it does not run in the sandbox.
- Every finding in your queue was confirmed by AI review of evidence captured from your target.
FAQ#
Why re-send from a fresh client instead of reusing the original session? Because a result that only shows up with the original session’s warmed state is weaker evidence. A fresh client shows whether the behaviour holds from scratch, which the AI review can weigh.
Why only GET and HEAD? Because re-sending a state-changing request could change data on your target. The check re-sends only read-only requests, and only once.
What happens to a candidate that does not reproduce? The “not reproduced” result goes to the AI review with the rest of the evidence. If the review does not confirm the finding, it never reaches your queue.
Read the verifier design notes for the philosophy, or see the platform pipeline.