Docs / Authorisation & Approval

Two separate checks sit in front of any live exploitation, and they answer different questions. The first: does whoever is running this scan control the target? The second, later, per exploit: did a human say yes to firing this specific thing at a production system? Both have to pass. This page covers how each one works. For the full responsible-use and disclosure policy behind them, see the Security Policy.

Proving you own the target

--i-am-authorized is required on every run against anything other than a local or loopback target. Passing it is an assertion (recorded in the run's own arguments) that you own the target or hold explicit written permission to test it. It is not, by itself, proof.

Real verification sits on top of that assertion: an HTTP well-known-file domain-control challenge, the same shape as ACME's http-01 challenge Let's Encrypt uses for domain validation:

python -m ryvx authorize <target-url>

It prints a token and a /.well-known/ path to place it at on the target, then confirms ownership on re-run once that file is live. A live external target must either pass this check or have you explicitly assert ownership instead. On the CLI that's --skip-verification-i-own-this: loud and audited, it writes a verification_skipped entry to the audit log. The hosted scan form offers the same choice as an explicit checkbox, “Skip domain verification: I own this target and accept responsibility,” recorded against the scan row itself. Neither is a technical proof of ownership; both are you accepting legal responsibility for the claim in place of proving it.

The human approval gate

Separately, every run is tagged with an environment: --environment {production,staging,dev}, defaulting to production, fail-safe. Spawning a vuln_hunter, exploiter, or generalist subagent against a production-tagged target blocks on a live y/N prompt first. Run non-interactively (CI, a scheduled scan) it auto-denies rather than hanging or silently proceeding, unless --auto-approve-exploitation is passed explicitly.

The example CI workflow shows the intended shape of that opt-out: its production scan job isn't just handed --auto-approve-exploitation with nothing behind it. It's gated behind a GitHub Environment configured with required reviewers, so the human approval Ryvx would otherwise ask for interactively has already happened at that protection rule before the job even starts. Auto-approve is safe there specifically because something else already provided the "yes." A PR-triggered source scan, by contrast, runs with --environment dev: it only ever touches a checked-out copy of source in the runner, so the production-approval gate correctly doesn't apply to it at all.