Detection is not proof: inside exploit-verified pentesting

Every security team knows the ritual. You run a scanner, it returns three hundred “potential” issues, and someone spends the next week proving that two hundred and ninety of them aren't real. The tool did the easy part — pattern-matching a response — and handed you the expensive part: proof.

Xalgorix was built around the opposite contract. We don't just find vulnerabilities; we prove them with a working exploit, then independently re-test the exploit before it ever reaches your report. This post walks through how that actually works — the methodology, the verifier, and the guardrails that let it run against production.

The false-positive tax

A detection is a hypothesis: “this parameter might be injectable.” A proof is a fact: “this parameter is injectable, here is the data I extracted, and here is the exact request that did it.” The gap between those two sentences is where security teams lose their time. Triage, re-testing, back-and-forth with engineering, and the slow erosion of trust that happens the third time a “critical” turns out to be noise.

The industry has largely accepted this tax as the cost of automation. We didn't. The design goal for Xalgorix was blunt: if we can't demonstrate impact, we don't call it a vulnerability.

Detect → exploit → report

The engine runs as an autonomous agent that routes across frontier models, picking the best fit for each phase. But the model isn't the product — the discipline around it is. The core rule the agent operates under never changes:

In practice that means the agent has to do the thing. Not observe that a login form lacks a header, but bypass the auth. Not note that a query looks concatenated, but pull a row out of the database. When it reports, it pastes the actual output of the exploit into the finding. A report without that evidence doesn't get downgraded — it gets refused.

The independent verifier

Here is the part that makes the difference. Before a finding is persisted, it's handed to a separate verifier that re-tests the vulnerability from scratch — a fresh attempt, not a re-read of the first agent's notes. The verdict is one of three:

• Confirmed — the verifier independently reproduced the issue. The finding is stamped verified.
• Inconclusive — the verifier couldn't reach a verdict (a transient error, a budget limit). The finding is kept, but explicitly flagged for manual review, never presented as validated.
• Rejected — the verifier actively disproved it. The finding is dropped.

That three-way outcome is deliberate. A finding is never silently discarded because a re-test was flaky, and it's never dressed up as confirmed when it isn't. Every result you see carries its confidence on its sleeve: independently verified, proven by the agent's own exploit, or awaiting a human. You always know which.

A 22-phase methodology, not a checkbox sweep

Real offensive work is sequential — recon feeds discovery, discovery feeds exploitation, exploitation feeds verification. Xalgorix encodes that as 22 phases the agent moves through, from reconnaissance and directory discovery, through injection, SSRF, IDOR/BOLA and broken access control, deserialization and RCE, up to exploit verification and a final branded report. You can scope a scan to specific phases when you only care about a slice of the surface.

The methodology is also where authenticated testing earns its keep. Hand the engine a session — or two, for horizontal access-control proofs — and it exercises post-login surface the way a real tester would: reaching account A's objects with account B's session to prove IDOR with concrete evidence rather than a hunch.

Whitebox: source makes the hard bugs findable

Black-box testing guesses at internals from the outside. When you connect a repository, Xalgorix clones it and exposes it to the agent through a fast source-search tool. The methodology shifts to source → sink → exploit:

• Map the framework, routing, and where user input enters.
• Hunt sinks — dangerous calls for RCE, command and SQL injection, deserialization, SSRF, hardcoded secrets — directly in the code.
• Trace reachability from each sink back to a user-reachable route.
• Exploit on the live target and prove impact.

Source proves a bug exists; the live proof-of-concept proves it's exploitable. Xalgorix wants both. Your token never touches the scan record or the logs — it's used server-side, at dispatch, only to clone.

Safe to point at production

Autonomy without guardrails is how a security tool becomes an incident. Xalgorix ships with a scope guard that keeps the agent on the hosts you authorized and blocks it from reaching your own infrastructure or local network. Testing intensity is configurable — passive when you want read-only checks, active when you want exploitation — and the engine is designed to prove impact without destructive payloads. Authorised testing only, enforced in code.

A report you can hand to an auditor

Each finding lands with a severity mapped to a CVSS score and vector, a technical analysis, a reproducible proof-of-concept, a concrete remediation — ideally a minimal patch — and its verification status. It exports as a branded PDF, streams live over the API as findings are confirmed, and can be shared as a read-only link. Findings deduplicate across runs, so a re-scan shows you what changed, not the same list again.

Try it

There's no install and no LLM keys to manage — pick a target, choose a mode, and watch the phases run live. Scans start at a dollar, and everything the dashboard does is available over the REST API and a GitHub Action, so you can wire Xalgorix into CI and fail a build on exploit-verified findings.

curl -X POST https://www.xalgorix.com/api/public/v1/scans \
  -H "Authorization: Bearer $XALGORIX_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "target": "https://staging.example.com", "mode": "single" }'

Detection is cheap and getting cheaper. Proof is the thing worth paying for — and the thing we built Xalgorix to deliver.