Trust & security
The agent sees real traffic. Here is what bounds it.
A retest runs a real browser against a live target your client owns, so the questions that matter are what it is permitted to reach, what refuses it, and who can read what it captures. Everything on this page is enforced in the product rather than promised in a policy.
Posture at a glance
No training use
Anthropic’s API, under our account
Reasoning runs there and nowhere else, under published commercial terms that do not train on inputs or outputs.
AES-256
Encrypted, on our own machine in Austria
An encrypted object store we operate, never a hyperscaler bucket. The machines that run retests keep nothing locally.
365 days
Kept for a year, then deleted
A retest's evidence is held for 365 days from the run and then deleted.
API key scoped
Tenant scoped
Keyed to your account from the API key, never the request. One client's evidence cannot be read from another's.
Per retest browser
No state reuse
Each retest's browser is wiped and closed before the next. No cookies or sessions carry over.
HMAC-SHA256
Tamper evident
Every bundle is sealed over its files. Any later edit is detectable.
What it is allowed to touch
Written as refusals rather than as features, because that is what a client's reviewer is reading for.
You name the target, and only that target
A retest runs against the URL submitted with the finding, and against nothing the finding did not name. The consultancy owns the target and authorizes the run.
SSRF guarded by construction
The agent cannot be turned against cloud metadata endpoints, link-local or loopback addresses, or RiftX's own infrastructure. Target validation runs before execution, not as a filter on what comes back. Private ranges are deliberately not blanket-blocked, because a client's internal application is a legitimate target once you authorize one.
Bounded, not exploratory
Hard ceilings on time, actions and spend bound every retest. The product does bounded retest work on a reported finding; it does not discover new ones and there is no crawl step to constrain.
It stops rather than pushing through
When a run hits a ceiling before the evidence separates from baseline, it returns Needs Review and hands the finding back. Nothing is cleared because the clock ran out.
The target's content is hostile input
A retest reads pages the target controls, and anything it reads can try to redirect it.
The agent reads whatever the target serves, and a page can carry text written to redirect an agent reading it. We do not claim the model cannot be steered, and there is no prompt-injection filter in front of it. Reliably separating instructions from content is not a solved problem, and a page claiming otherwise would be making the one promise on it you could not check.
What is bounded is how far a steered run could get. It acts against the URL submitted with the finding, and validation runs before execution rather than on what comes back. There is no discovery step to redirect, because the product retests a reported finding rather than hunting for new ones. Ceilings on actions, time and spend end the run whether or not it is behaving. Each retest’s browser is wiped and closed before the next, so nothing a target plants survives into another client’s run.
And the verdict never rests on the run’s own account of itself. It is re-derived from the sealed evidence by an auditor that does not see the run’s reasoning and can only move a verdict toward Needs Review. A run that was successfully talked into something cannot talk its way to a Fixed.
Data handling
The questions that come back from a client's security review, in the order they usually arrive. The middle three are the ones most vendors leave out.
Can one customer's retest see another's?
Every artifact is keyed to the customer resolved from API key authentication rather than from anything in the request body, so a cross-tenant read is rejected before it reaches storage. Each retest's browser is wiped and closed before the next, so no cookie or session carries across retests or tenants.
Where does evidence live?
On one machine in Austria that we operate, in an encrypted object store under AES-256, never in a hyperscaler bucket. It never rests on the machine that produced it, and that machine retains nothing locally once the upload completes.
How do we know evidence was not altered?
Every bundle carries an HMAC-SHA256 seal over a Merkle root of its files, so any later edit to any file is detectable by your side rather than attested by ours.
A bundle shows masked headers. Is that what was stored?
No. Authorization and cookie headers are masked when a bundle is displayed, and the capture behind it keeps the real value, so handle a downloaded bundle as though it contains live secrets. The same goes for anything you put in the steps to reproduce, which is stored unmasked and is covered in full on the privacy page.
Who at RiftX can read our evidence?
RiftX is a very small team, and the people who operate the platform can reach production, which includes the evidence store. That is the honest answer rather than a control we can point at. There is no formal access review and no customer-visible log of operator access. If your client's engagement requires either, raise it early.
Does a model decide anything about a person?
No. The only thing a run decides is whether a fix held on a system your client owns. There is no scoring of individuals, no automated decision with a legal or similar effect, and nothing here a person could be profiled by.
What a retest hands you, the seal, and what verification actually proves are on Evidence. What is held, on what basis, for how long, and how to have it removed is on Privacy, including what happens to credentials you put in the steps to reproduce.
Who else touches it
Four, and the list is short because the product is. Named here so you can see the path; what specifically reaches each of them is on the register.
Anthropic
Model reasoning
United States
netcup
Hosting
Austria
Cloudflare
Network and access
Global edge
Resend
Transactional email
United States
There is nothing else in the path today, and this list is the whole of it rather than the part we are comfortable naming. If another party is going to touch retest data, it is posted at least 30 days before that happens and account holders are emailed. What each one does, what specifically reaches it, and every change so far are on Subprocessors.
The verdict is rechecked, and the recheck can only be cautious
A system that grades its own work is worth its own opinion of itself, which is nothing.
Every verdict is independently re-derived by an always-on auditor reading the sealed bundle and nothing else. It does not see the run’s own reasoning, and it can only downgrade toward Needs Review. It cannot promote a verdict and it cannot clear one. The failure mode is caution, never a false all-clear.
This matters more than it sounds for a consultancy, because the asymmetry is the wrong way round otherwise: a false Not Fixed costs your team an argument, and a false Fixed costs your client a live vulnerability signed off under your name.
What we do not claim
Certifications, paperwork, operations and liability. Every absence we know of, listed.
We do not currently hold SOC 2, ISO 27001 or PCI DSS attestation, and this page will say so until we do. Everything above is a design property of the product, enforced in code and checkable on a call; none of it has been through a third-party audit yet.
There is no ISO 42001 certification either, and no EU AI Act or NIST AI RMF adherence statement, which are the AI-specific documents this category has started publishing. RiftX has also never had an independent penetration test of its own systems. For a product that retests other people’s, that is worth saying out loud rather than leaving for you to notice.
There is also no data processing agreement ready to sign today, and no choice of storage region to offer you. If your client’s contract requires either before a supplier touches their systems, that is a real blocker rather than a formality, and it is worth raising in the first conversation.
On the operational side there is no SSO or SCIM, no status page or uptime commitment, no formal access review, and no contractual breach-notification window. Access is by API key. The honest summary is that what this page describes are properties of how the product is built, not an operations programme with paperwork behind it.
The absence of a contractual window is not an absence of a practice: how we intend to operate on a breach, and why that is an intention rather than a term, is set out on Privacy.
On liability, the exposure sits with your firm, because your name goes on the finding. There is no professional indemnity position to put beside that yet, and contract stage is the wrong place to learn it.
If your client’s procurement process requires an attestation we do not have, tell us early. We would rather lose the deal on a fact than manage it on a maybe.
Reporting something
Security issues
security@riftx.io. If you have found something in RiftX itself, this reaches the person who built it. Reports are acknowledged within 48 hours, and we aim to have a fix or mitigation within 14 days depending on severity.
Privacy requests
privacy@riftx.io. Deletion, export, and questions about what is held on your account. Answered within 30 days and confirmed back in writing, at no charge.
The data document those requests are answered from is on Privacy.
What changed, and when
Newest first, including the things that did not change. A gap still open is still news.
3 August 2026
Two gaps written down that were previously only true
Operator access to production and the handling of credentials pasted into steps to reproduce are both stated on this page now. Neither changed; both were answers you would previously only have got by asking. The privacy page became a document you can answer a client questionnaire from at the same time.
13 July 2026
Still no SOC 2, ISO 27001, DPA, SSO or independent pentest
None of these moved this quarter. They are listed here with a date rather than left for you to infer from their absence, and they will keep appearing until they close.
This feed covers what this page claims. A change to who touches retest data is a different question with a different answer, and it gets its own dated feed on Subprocessors, posted before the change takes effect rather than after.
See it run
Watch it retest a finding you already know the answer to.
Security posture is easiest to judge by watching what the thing actually does. Bring a target you can authorize and we will run a retest against it while you watch what it reaches for and what it refuses.