Security & Responsible Use Policy

When firing real exploits against a target is acceptable, and what happens when it isn't.

Ryvx fires real, working exploits against real targets. This policy governs when that's acceptable and what happens when it isn't — a hard precondition for using Ryvx against anything you don't personally control, not a nice-to-have.

What "authorized" means

--i-am-authorized is required on every run against anything other than a local/loopback target. Passing it is an assertion that you own the target, or hold explicit written permission from its owner (a signed engagement letter, a bug bounty program's published scope, or equivalent) to test it.

--i-am-authorized alone is that assertion, not proof — recorded in the run's own args, but not independently checked. Real verification sits on top of it: an HTTP well-known-file domain-control challenge, the same shape as ACME's http-01 challenge. A live external target must pass this check before any exploit fires; --skip-verification-i-own-this is a loud, audited escape hatch for trusted local/dev use only — not a way around the policy in a hosted or multi-tenant deployment. Running Ryvx against a target you do not have explicit permission to test is a misuse of the tool and, depending on jurisdiction, may be a criminal offense (e.g. under the US Computer Fraud and Abuse Act or the UK Computer Misuse Act) regardless of what this tool allowed you to type on the command line.

Safeguards already built in

  • Every finding requires a working proof-of-concept before it's recorded — the tool hard-rejects anything without real supporting evidence.
  • Exploitation against a production-tagged target requires a live human approval before it fires, and auto-denies (never silently proceeds) when run non-interactively.
  • Every tool call any agent makes is written to an append-only audit log, giving a full chain-of-custody trail for what actually ran against a target.

None of these substitute for actual authorization — they bound what an already-authorized run can do, they don't establish that authorization exists in the first place.

If you find a vulnerability in Ryvx itself

Report it privately rather than opening a public issue: email ryvx.pentesting@gmail.com (a GitHub security advisory on our repository also works — either way, not a public issue). Include what you found, how to reproduce it, and its impact. We'll acknowledge within 5 business days and aim to ship a fix before any public disclosure.

If Ryvx was run against a target without authorization

If you're the operator of a target that was scanned or exploited by an instance of Ryvx you didn't authorize: that's a misuse of this tool by whoever ran it, not something we can retroactively undo. Contact whoever you believe ran the scan directly. If the run originated from a hosted instance of this project specifically (not a self-hosted copy), report it to the same security contact above — we will investigate, suspend the account responsible pending review, and cooperate with any resulting legal process.

Your scan data on your own machine

Scan findings are sensitive by definition — they describe how to break into something you own. Two things are worth knowing about how the desktop app and CLI treat them locally, stated plainly rather than left for you to discover:

  • Signing out locks them.The desktop app's local API requires a signed-in session, so another person on the same machine can't read your past scans through the app once you sign out. Before August 2026 it couldn't — anything on the machine could read every scan with no session at all.
  • You can encrypt them at rest, and it's off until you turn it on.Settings → Encryption shows you the key before it will let you enable anything, because the key lives only on your machine: lose it and every past scan becomes permanently unreadable, by us as much as by anyone else. Off by default for that exact reason — silently encrypting your history with a key you've never seen is a data-loss bug, not a security feature.
  • It covers scan findings, not every file. report.md and findings.sarif stay plain text on purpose — people read one and CI tools read the other, and encrypting them would break that silently. Your dashboard settings file stays readable too. We'd rather list the exceptions than let “encrypted at rest” imply more than it covers.

Scope of this policy

This covers Ryvx itself and any officially-hosted instance of it. It does not extend authorization to test any third-party system — that authorization has to come from the third-party system's own owner, independent of anything we say here.