Not a scanner. Not a pentest firm.
Where the difference is, and where it isn't.
“How is this different from Burp, from Nessus, from Nuclei, or from just hiring a firm?” is the first question anyone evaluating a security tool asks, and it deserves a straight answer instead of a features list. This page gives one, built the same way the rest of this site tries to: every claim below traces to a specific file, and if a claim couldn't be pointed at code, it was cut rather than kept for effect. No invented percentages, no fabricated head-to-head runs: the same standard that made us withdraw our own recall numbers rather than publish something we couldn't stand behind applies here too.
What a scanner gets right
Burp, Nessus, and Nuclei-style template scanners are excellent at what they're built for: systematically sweeping a huge, maintained rule or template corpus across a target, fast, repeatably, and integrated into a workflow a security team already runs daily. That breadth and maturity is real, and nothing below is a claim that Ryvx covers more ground than tools with years of accumulated signatures behind them. No such benchmark exists, so this page doesn't invent one.
Where Ryvx differs from a scanner
A scanner reports what might be wrong and hands you a queue to triage. Ryvx refuses to file a finding it couldn't back up. create_finding hard-rejects anything missing a working poc_script_code, along with title, description, technical_analysis, poc_description, remediation_steps, evidence, cvss_vector, and cwe (REQUIRED_FIELDS, ryvx/report.py:96–109). It separately refuses to file anything at all unless the agent's own transcript shows at least one real investigative tool call behind it (ryvx/tools.py:3250–3270). A rule matching a response header is a lead. Ryvx's bar is proof.
It also chains rather than sweeping flat. A root orchestrator spawns and steers purpose-built subagents (recon, OSINT, one or more vuln-hunters, an exploiter, a fixer) that build on what the others already found, instead of running one rule against one target in isolation (ryvx/agent.py / ryvx/coordinator.py). The root agent's own system prompt states the boundary directly: “You never scan, exploit, grep code, or send HTTP requests to the target yourself… ALL work that touches the target is delegated to a subagent” (ryvx/prompts.py:604–609). The one tool that spawns a subagent is hard-gated to the root agent in code, not just by prompt (ryvx/tools.py:4088–4090).
Severity isn't a static label off a rule or a number the model made up about its own finding, either: it's a CVSS 3.1 base score computed by a hand-rolled formula against the finding's reported vector, “so we compute this deterministically instead of trusting the LLM's self-reported number” (ryvx/cvss.py:1–5, 92).
What a pentest firm gets right
A firm brings something Ryvx doesn't claim to have: a person who can connect a business-logic quirk in one system to a stale header in another, decide an odd result is worth ninety minutes of manual poking on a hunch, and put their professional standing behind the report they hand you. That's real creativity and real accountability, and it's the actual thing you're buying when you hire one.
Where Ryvx differs, and where it doesn't try to
The trade is cost and cadence. A firm's engagement runs to thousands of pounds, happens quarterly at best, and produces a PDF that's stale the week after it lands. Ryvx's hosted scans are flat-priced and sellable on demand. You pick a category (OSINT, compliance, or a full pentest) and a strength, and the strength is what sets the price: 20 credits at quick, 50 at standard, 100 at deep (STRENGTH_PRICES, lib/pricing.ts, £1.00/credit at the top-up rate), run again the day after a deploy instead of waiting for next quarter's slot.
Exploitation is opt-in and gated by default, not implicit. Spawning a subagent that runs exploit/PoC actions against a production-tagged target blocks on live human approval first, and auto-denies rather than hangs when nobody's watching (ryvx/tools.py:4095–4102, the gate itself at ryvx/tools.py:3660–3674). That's a per-scan choice, not a per-package one: on hosted, ryvx/worker.py appends --no-auto-approve-exploitation to every scan unless that scan's own spec.auto_approve field was set by ticking “Auto-approve exploitation” on the scan form itself, and that choice is recorded against the scan row, not implied by which preset or plan you bought. On the local CLI, three presets (Compliance-Only, OSINT to Exploit, and Full Pentest) default that same flag on and say so in their own --help text (auto_approve_exploitation, ryvx/config.py:511–595). A live external target also needs to clear an HTTP well-known-file domain-control challenge (the same shape as ACME's http-01 challenge) before a scan runs against it at all (ryvx/authorization.py), and every tool call any agent makes, on every target, is appended to a per-run audit.jsonl for defending what happened afterward (ryvx/audit.py:73–98).
None of that is a substitute for what a firm sells. Ryvx's subagents have fixed roles (recon, OSINT, vuln-hunter, exploiter, fixer), not a person improvising a chain nobody wrote a role for. There's no professional liability behind a finding the way there is behind a signed report; miss something, and what you have is an audit trail showing what ran, not someone accountable for what didn't get tried. And the honesty this site tries to hold itself to cuts against Ryvx here too: differential_verify.py's independent checks can refute a claim (catch a finding that doesn't actually reproduce), but they can never confirm one is genuinely fixed. “Only ever ‘refuted’ or ‘not confirmed’… a reader must not mistake ‘we ran a check’ for ‘we proved it’” (ryvx/report.py:2578–2586). A firm's retest can tell you a fix holds. Ryvx can only tell you when one doesn't.
Side by side
| Scanner | Ryvx | Pentest firm | |
|---|---|---|---|
| What you get | A queue of matches to triage yourself | Findings gated behind a working exploit, or nothing filed | A signed report from a named tester |
| Chains findings across steps | No: one rule, one match | Yes: recon/OSINT feed vuln-hunting and exploit subagents | Yes: this is what a person is good at |
| Severity | Rule-authored or self-reported | Deterministic CVSS 3.1, computed from the reported vector | Human judgment, usually CVSS too |
| Cost & cadence | Subscription, run continuously | 20-100 credits a scan (£20-£100 at the £1.00/credit top-up rate), run whenever you want | Thousands per engagement, typically quarterly |
| Exploitation | Usually off, or a separate paid module | Off by default; gated behind approval on production targets | Explicit, scoped, human-supervised |
| Judgment beyond its own rule set | None | None: subagent roles are fixed, not an improvising human | Yes: the actual product being bought |
| Accountability if something's missed | None | None: an audit trail of what ran, not a liable party | A firm's professional standing and liability |
Every “Ryvx” cell above is one of the file references in the sections it summarizes, not a new claim: this table is a recap, not the evidence.
The honest limits
This site has already withdrawn one set of numbers rather than let a truncated benchmark run stand as a claim: see Withdrawing our benchmark numbers. The same rule applies here: there is no published, audited number for how Ryvx's find rate, false-positive rate, or coverage compares to Burp's, Nessus's, or Nuclei's, and none appears on this page. What you can check instead is one real finding shown in full (the filed record, the PoC that proved it, and the audit-log excerpt that recorded it) on Proof, and the full verification mechanics on Verification.
See what a hosted scan costs on Pricing, or run the CLI and desktop app free on Download.