Every workspace runs in its own execution namespace with separate storage keys. Nothing about your application is used to serve another customer.
- Per-tenant encryption keys
- No shared execution workers
- No cross-customer model training
Security & trust
ReadyForUsers is designed so that the worst case, a full compromise of our systems, still cannot charge your customers or delete your data.
Every workspace runs in its own execution namespace with separate storage keys. Nothing about your application is used to serve another customer.
Classification happens before permission. An unclassified host is treated as production, and production is observation-only by default.
Credentials are encrypted at rest with per-tenant keys, decrypted only inside the execution sandbox, and never displayed again after entry.
Mass creation, destructive fuzzing, live purchasing and heavy load are structurally blocked on production, not merely discouraged by policy.
Your evidence is never used to train a model, ours or a provider's. Provider calls run with zero-retention agreements in place.
Video, screenshots, HARs and snapshots are stored per incident in your region and are addressable only through your workspace.
You set retention per artefact class. Screenshots can go in a day while incidents live for a year. ReadyForUsers does not need the media to keep the finding.
Deleting an application, a run or a workspace removes the artefacts immediately rather than scheduling a job for later.
Every production run, gate override, credential change and deletion is recorded with the acting user, exportable at any time.
The hard boundary
Environment classification happens before any action is permitted, and it defaults to the most restrictive reading. An unclassified host is treated as production. Enabling destructive testing on production requires an Owner or Admin, a typed confirmation of the hostname, and it is written to the audit log with that person's name attached, permanently.
Live payment keys are rejected by the executor even if present in your configuration.
Destructive verbs are unavailable on production regardless of the credentials supplied.
Concurrency on production is capped far below your capacity and is not configurable upward.
Retention you control
Every value is adjustable down to zero, and deletion is immediate rather than queued.
ReadyForUsers is not a penetration test and not a compliance certification. It finds failures a realistic population would cause. Anything else on this page you can verify Ask for the report.
Engineers ask
Do I have to give you a production database or a clone of it?
No. Staging only. Production hosts are refused by policy. We never ask for a clone.
Can the witness modify my data?
No. It holds a read-only connection string and only issues reads. Use a read-only database role and your database enforces it as well.
How do you reset state after a collision?
For our hosted demo apps, the app and its seeded database live inside an ephemeral machine that is destroyed after the run. For your staging, we agree the precondition with you, record before and after state, and you restore from your own seed or snapshot. We do not reset your data for you.
Do synthetic users act as my real users?
No. Each run creates its own test identities with separate sessions.
What if the evidence is incomplete?
The verdict is UNVERIFIABLE. We never present a model's opinion as a fact about your database. Invented evidence is always zero, and the receipt says so.
What happens to my connection string?
Encrypted at rest, decrypted only inside the run, never logged, never shown to a model or an actor, and you can revoke it any time.
Where does a run execute and what can it reach?
In an isolated machine with deny-by-default egress. It can reach your staging target and nothing else. The machine is destroyed when the run ends.