Proof of exploit · authorized pentest

Scanners guess what's exploitable. BreachLens proves it or drops it.

Each candidate finding is put through controlled exploitation against your authorized target, in an isolated environment. It only earns the CONFIRMED badge when it actually reproduces — and it ships with the evidence to reproduce it, including a runnable command and a recorded replay where available.

Runs on your infrastructureNothing leaves your networkYou mark what's in scope
breachlens · pentest
A BreachLens pentest finding marked CONFIRMED and badged Proof of Exploit, with the recorded replay of the exploit playing beside a timestamped action log — navigate, dialog fired, exploit lands.
Proof, not alerts

A finding you can't reproduce is a guess.

Every other scanner ends at a ranked list, and your team spends the week arguing which entries are real. BreachLens ends at evidence — so the debate is about the fix, not whether the bug exists.

Detected

A scanner flags a candidate

A scanner surfaces a possible issue in code, a container, cloud config, or a running app.

Attempted

Controlled exploitation

BreachLens tries to exploit it against your authorized target, in an isolated environment — recording the attempt where it's browser-driven.

Confirmed

Evidence attached

If it works, the finding ships with the evidence URL and the attack — plus a reproducible command and a replay where available. If it doesn't, it's labeled honestly by confidence.

What you get

Evidence a security team can act on — and an auditor will accept.

Proof of exploit

Reproducible evidence, not a score.

  • · A runnable command that replays the attack end to end, wherever one can be generated.
  • · The evidence URL and the exact request that worked.
  • · Run it yourself against a lab target and watch it fire.

Recorded replay

Watch browser-driven exploits happen.

  • · Browser-driven exploitation runs in an isolated browser and is recorded.
  • · A short replay is attached wherever the exploit is browser-driven — a video, not just written steps.
  • · Record an authenticated journey so testing drives the flows that matter.

AI-augmented — on your own model

The attacker's brain is one you own.

  • · AI generates exploitation payloads tuned to your application's context.
  • · It runs on your own model — Anthropic, OpenAI, Gemini, or fully local.
  • · No vendor's AI ever touches your systems, and the proof never leaves your network.

Function-level reachability

Is the vulnerable code actually reached?

  • · Traces the call path from entry point to the vulnerable function.
  • · Across supported language ecosystems.
  • · De-prioritizes what can't be reached, so you fix what's real first.

Kills false positives

CONFIRMED means reproduced.

  • · Only findings BreachLens actually exploited are marked CONFIRMED.
  • · Everything else is labeled by confidence — plainly, no inflation.
  • · Fewer tickets, and a signal your team and your auditors trust.
breachlens · pentest
The evidence behind a confirmed BreachLens exploit — the affected URL, the vulnerable parameter, the payload that worked, and the HTTP response it returned.
The evidence behind the badge — the affected URL, the vulnerable parameter, and the payload that worked. Enough to reproduce it yourself.
Straight answers

The questions a security team asks about pentest access.

Is the “proof of exploit” real, or a dressed-up severity score?
Real. A finding is only marked CONFIRMED when BreachLens actually reproduced the exploit against your authorized target. The evidence includes the evidence URL and the request that worked — plus a runnable command where one can be generated, so you can run it yourself and watch it work. It is not a heuristic confidence number.
Is it safe to grant authenticated / pentest access?
Straight answer: authenticated scan and pentest access is operator-trust — gated by an explicit authorized/controlled flag, RBAC, and license tier, not a cryptographic ownership proof. Exploitation only runs against targets you mark authorized, on infrastructure you host. We'd rather state the limit plainly than let you find it during an eval.
Where does the exploitation actually run?
On your infrastructure. BreachLens stands up the isolated browser inside your own deployment; nothing about the target, the evidence, or the replay leaves your network — and nothing goes to a vendor cloud.
Isn't “AI pentesting” just a vendor's AI poking at my systems?
Not here. BreachLens is AI-augmented — it generates context-aware exploitation payloads for your stack — but it runs on your own model and your own infrastructure. The AI doing the attacking is one you control, and the proof (the runnable command and the recorded replay) never leaves your network. That's the difference between an AI pentester you run and one you rent.
Does it re-test continuously?
Honest answer: today it runs when you trigger it — from CI, a schedule you set, or on demand. Continuous re-validation is on the roadmap, not shipped — we won't imply it's live.
See it on your stack

Watch BreachLens prove an exploit — live.

Book a 30-minute technical demo. We'll run it against your repos, containers, or a domain and show you a CONFIRMED finding with its evidence — a reproducible command and replay where available.

Self-hosted · your data never leaves your network