Ryvx

Docs / Authorization & Approval

Authorization & Approval

Prove you own it. Then approve the exploit.

Two separate checks sit in front of any live exploitation, and they answer different questions. The first: does whoever is running this scan actually control the target? The second, later, per exploit: did a human actually 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-authorizedis 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 pass this check before any exploit fires. --skip-verification-i-own-thisexists as an explicit escape hatch for trusted local/dev targets you haven't run that dance for yet — it's loud and audited (it writes a verification_skipped entry to the audit log), not a quiet way around the policy in a hosted or multi-tenant deployment.

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.