Skip to content

Security & trust

You are handing us your application. Here is exactly what we do with it.

ReadyForUsers is designed so that the worst case, a full compromise of our systems, still cannot charge your customers or delete your data.

Tenant isolation

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
Environment controls

Classification happens before permission. An unclassified host is treated as production, and production is observation-only by default.

  • Automatic environment detection
  • Typed hostname confirmation
  • Owner or Admin required
Encrypted secrets

Credentials are encrypted at rest with per-tenant keys, decrypted only inside the execution sandbox, and never displayed again after entry.

  • AES-256 at rest
  • Write-only in the UI
  • Rotatable without a re-run
Production protection

Mass creation, destructive fuzzing, live purchasing and heavy load are structurally blocked on production, not merely discouraged by policy.

  • Enforced in the executor
  • Sandbox payment keys only
  • Concurrency hard-capped
Model-data boundaries

Your evidence is never used to train a model, ours or a provider's. Provider calls run with zero-retention agreements in place.

  • Zero-retention provider terms
  • No training on your data
  • Provider list published
Evidence storage

Video, screenshots, HARs and snapshots are stored per incident in your region and are addressable only through your workspace.

  • Region pinned per workspace
  • Signed short-lived URLs
  • Per-incident deletion
Data retention

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.

  • Per-class retention windows
  • Minimum is zero
  • Applies retroactively
Deletion

Deleting an application, a run or a workspace removes the artefacts immediately rather than scheduling a job for later.

  • Immediate, not queued
  • Includes provider-side caches
  • Confirmation receipt issued
Audit logs

Every production run, gate override, credential change and deletion is recorded with the acting user, exportable at any time.

  • Immutable append-only log
  • Exportable as JSON or CSV
  • Retained for the workspace life

The hard boundary

Production is observation-only until you say otherwise, in writing.

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.

Cannot charge

Live payment keys are rejected by the executor even if present in your configuration.

Cannot delete

Destructive verbs are unavailable on production regardless of the credentials supplied.

Cannot overwhelm

Concurrency on production is capped far below your capacity and is not configurable upward.

Retention you control

Session video7 days
Screenshots30 days
Network & logs30 days
Incidents & findings1 year
Audit logWorkspace life

Every value is adjustable down to zero, and deletion is immediate rather than queued.

What we will not claim

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.