AI Use Policy

Ryvx is built on language models, and this page states plainly what they do, what they don't get to decide on their own, where your data reaches them, and how long the record of what they saw is kept. It exists to answer the questions a buyer's security or procurement questionnaire asks, in one place, checked against our own code rather than written from memory. It summarises and points at our Security and Privacy Policy pages rather than duplicating them; where this page and either of those disagree, treat Security and Privacy as correct.

What the models are used for

A language model does two jobs in Ryvx: it drives the scan agent, deciding what tool to run next while recon, vulnerability hunting, or exploitation is in progress, and it writes up what a scan produced into a finding and a report. That's the extent of it. It is not the thing deciding a vulnerability is real, and it is not the thing deciding whether an exploit against a production target is allowed to fire. Both of those are enforced in code, not left to the model's judgement, and both are described below.

Where your data goes

A hosted scan's tool output, HTTP traffic, recon results, and whatever else the agent gathers becomes part of what gets sent to a language model to produce a finding and a report. The model provider sees that data. The sub-processor it reaches is named in full on our Security page, under “Sub-processors: where your prompts and transcripts go”: OpenRouter, routing each request to GLM 5.3 Flash on a zero-retention endpoint, pinned to an allowlist of US-headquartered providers. That section is canonical for exactly what's disclosed, which providers can end up serving a request, and how the container's credentials are scoped; this page only points at it rather than repeating it, so it can't drift out of date in two places at once.

Self-hosted (CLI or desktop app, run outside our infrastructure): which model runs is entirely yours to set, down to a model running on your own machine with nothing sent to any third party at all.

Retention: transcripts are kept, not silently discarded

A transcript is what the model actually saw and said while it worked, not just what it filed as a finding. On the hosted platform, a scan's transcript is retained for the same 90-day window as its findings and evidence, and deleted on the same schedule: it's treated as evidence, on the same retention path as everything else in that list, not a separate store with its own rules. Locally (CLI, desktop app), a scan's transcript is written into the same run directory as its findings and passes through the same at-rest encryption path they do, off by default until you turn it on, exactly as described in Security's “Your scan data on your own machine” section. Full detail on both windows, including how backups age out, is on Security.

Model output is never trusted as fact

The honest answer to “how do you stop the AI making things up” is that a model's say-so is not sufficient to file a finding, and this is enforced in code, not by policy alone. Every finding requires a working proof-of-concept script before it's recorded: REQUIRED_FIELDS in report.py includes poc_script_code alongside evidence and a CVSS vector, and the function that files a finding hard-rejects anything missing one of those, unconditionally. A model can propose a finding; it can't make one real by asserting it.

Human oversight before anything fires

Exploitation against a production-tagged target requires a live human approval before it runs. On a hosted scan that pause is on by default no matter which preset or plan you pick, and only lifts when the person submitting the scan explicitly ticks “Auto-approve exploitation” on the scan form itself. A request that times out, hits a network error, or is never answered resolves to a denial, the same as an explicit no: there is no path where the model's own silence, or ours, becomes an approval. Full detail, including the CLI presets that behave differently and say so in their own --help text, is on Security.

Asking what a finding was based on

Because a scan's transcript is retained for the same window as its findings, you can ask us what a specific finding was based on, and we can trace it back to what the model was actually given and what it actually produced, not just to what got filed. Ask through security@ryvx.dev, naming the finding and the scan it came from.

What this policy doesn't claim

We hold no SOC 2, ISO 27001, or Cyber Essentials certification today, none is currently in progress, and we don't offer a signed Data Processing Agreement template. We'd rather say that plainly than let this document imply otherwise. “GDPR compliance” isn't a certification to hold in the first place; our Privacy Policy states the legal basis we rely on under UK GDPR. What we have instead is the proof-of-concept gate and the human-approval gate described above, plus the retention and access-control detail on Security.

Questions

Questions about this policy, or about how a specific scan or finding was handled: security@ryvx.dev. Questions about your data specifically: privacy@ryvx.dev.