Privacy & Security
A trust document for how customer data and evidence are handled.
This page is written as an operational summary, not as decorative legal copy. The goal is to make the product's trust posture easy to understand.
Trust model at a glance
No training on client data
Targets, steps-to-reproduce, and retest results are not used as model training data.
Isolated execution
Each retest runs in an isolated browser environment with no browser context reuse across tenants.
Evidence integrity
Artifacts are tied back to the retest with an HMAC-SHA256 seal so the output stays tamper evident.
Tenant separation
Customer data is separated at the storage and application levels to avoid cross tenant leakage.
The product is designed for bounded retesting, not loose data collection.
Collected inputs
For each retest, RiftX processes the target URL, the pentester's steps-to-reproduce, the reported vulnerability type, and any optional supporting context required to run the retest.
Generated artifacts
The system produces evidence artifacts such as network captures, browser artifacts, and retest reports so the resulting verdict can be reviewed and defended by a pentester.
Isolation and storage
Execution is isolated per retest and customer data remains separated by tenant. Evidence storage and artifact handling are designed around retaining the proof a retest needs while avoiding unnecessary exposure.
Security controls
Target validation, isolated execution, safety limits, and auditable system actions are part of the default trust model. The product is designed to do bounded retest work, not unrestricted exploration.
Model usage
LLM reasoning runs inside hard safety limits on time, actions, and cost, and every verdict is independently rechecked by an always on auditor that can only downgrade to Needs Review, never inflate. Client data is not reused to train the underlying models.
Contact
Security concerns
security@riftx.io
Privacy requests
privacy@riftx.io