Security & trust

Your build is evidence, then it's gone.

You're handing us a build and, sometimes, a test login. Here's exactly what happens to both — and how each claim on this page maps to real behavior in the product, not marketing.

Your build is kept for 14 days, then destroyed

Your build and the run's recordings are kept for 14 days after your report is delivered — for free re-runs and support, nothing else — and are then destroyed automatically. You can have them destroyed sooner at any time, and every destruction produces a signed record you can check. The purpose is the narrow one stated there and nothing else: we do not read your build for anything you did not buy. If a run fails, the build is held for a 72-hour retry window so you can attach a fixed one to the same audit, then destroyed the same way. Your report no longer carries a deletion timestamp, because a document handed to you on day one cannot honestly stamp something that happens on day fourteen — the proof arrives when the deletion does, in the next card.

The deletion is signed, so you can check it rather than believe it

When your build is destroyed — on day 14, or the moment you ask — the server signs a small record: the audit id, the digest of the build itself, the UTC time, why it went, and the version of this policy that governed it. Nothing else is in it: no address, no app name, no file path. The ReadyAudit app shows it, and `readyaudit-package verify-deletion` checks the signature on your own machine against the public key below. It is Ed25519 over a byte string we specify in full, so you can reimplement the check in whatever you already have open.

Your test credentials never touch a log

Use a disposable test account with fake data. Demo credentials live until this run reaches a terminal state — a delivered report or a failed run — and never longer than 72 hours. They are never written to logs or telemetry. Between submission and the run they sit inside the job record, which is encrypted before it reaches the disk under a key belonging to that run alone. The ceiling in that sentence is enforced by the server, not merely stated: a run that reaches no terminal state of its own accord is ended at 72 hours and its credentials are destroyed with it.

Everything we store is encrypted before it reaches the disk

Your build, the job record with your credentials in it, the report and the credit ledger are each encrypted with their own AES-256-GCM key; only that key is wrapped with the host master key, so no two audits share a key. The format authenticates as well as encrypts, so a record that has been altered fails to open rather than opening as something slightly different — and a record we cannot read is reported as unreadable, never as empty. The boundary, stated plainly: the master key lives in the service environment on the same host as the data it unlocks, because there is no hardware security module or key-management service in front of it. That protects you against a lost disk, a stray backup, a snapshot, a decommissioned volume and an operator opening files they have no business opening. It does not protect you against someone who has already taken control of the running host. If your threat model needs the stronger version, ask before buying rather than after.

The evidence lives in your report and nowhere else

Every screenshot and the frame from the moment a task failed are embedded in the report we hand you. The originals — including the screen recording the frame was cut from — are destroyed with your build at the end of the 14-day window, or sooner if you ask. We keep no copy after that, which also means we cannot re-send the evidence later: your report is it.

Your report link is the key to your report

There are no accounts here, so there is nothing to log into and nothing to log out of. Your audit gets an unguessable address — 122 random bits, not a number anyone can count up to — and whoever holds that address can read the report. That is deliberate: it is what lets you forward your findings to a developer or a client without us issuing them credentials. The trade is real and it is yours to make: treat the link like the report itself, because anyone you send it to can read everything in it. We never publish these addresses, and nothing on this service will list your audits to anyone — the only way to reach a report is to already have its link. If you want one taken down, ask and we will erase it.

We keep the findings, not the evidence — and those are different things

What survives an audit is the measurement: the finding rows (rule_id, verdict, severity, layer, module, category, framework, device_variant, environment, wcag_reference, run_timestamp, audit_id), the score and the coverage arithmetic. That record is what lets a second audit tell you which of your findings you actually fixed, and it is what the benchmark clause in the Terms aggregates. It contains none of the following: screenshots, video frames, element text, accessibility labels, credentials, build bytes, and any pointer that could retrieve a destroyed artifact. It is linked to your audit and your Device Token, so it is pseudonymous rather than anonymous; only the benchmark projection is de-identified, and you can have your audit excluded from that or erased entirely by asking.

What leaves the machine, and what does not

Your build never leaves the audit machine. Two things do, and both go to the same commercial API: the screenshots of the screens the crawl recorded, and a text rendering of their accessibility trees. The screenshots are what lets a model group the recordings into screen types — a crawl records one screen many times, and something has to decide which recordings are the same screen. The trees are what the agent layer reads when you have it enabled. Nothing else is sent: not the binary, not your credentials, not the report.

Your build is never used to train a model

Everything we send goes to a commercial API tier whose terms prohibit training on submitted content — never a consumer subscription. That is a deliberate, load-bearing choice: a subscription would void this guarantee, so the constraint was written down before anything shipped rather than after. Your build and its contents are inputs to your audit and nothing else.

The audit runs on an isolated, hardened machine

Audits run on a dedicated macOS user with FileVault on and no inbound network connections — the worker only polls out. Each run happens on a throwaway simulator clone that is erased and destroyed afterward, so nothing from one audit reaches the next.

72hfailed-build retry window

14dbuild retention, then deleted

0credentials in logs

neverused for training

The deletion key

Ed25519, base64. This is what readyaudit-package verify-deletion checks a deletion record against. Save it to readyaudit-deletion-key.txt beside the script, or paste it as the second argument.

ChixFxA9nENYmRrvnycATMif8SPSqu9HPuzHl4Byzl8=

Key id 0a18b117103d9c43. Every record carries the id of the key that signed it, so rotating the key never invalidates a record you already hold — a retired key stays published here for as long as records signed by it exist.

Report a vulnerability

Responsible disclosure is welcome. Email info@readyaudit.dev — we'll acknowledge and work with you on a fix.

Listing not live yet — what a credit costsRead the privacy policy

Technical readiness assessment — not legal advice. Retention config v1.4.0.