Plain answers about your data
What we store, where it runs, how accounts are protected, and what we have not built yet. If you need more, write to hello@failure.fail.
Where a request goes
Edge
Your request lands on Cloudflare Workers at api.failure.fail over TLS.
Key check
The key is matched against its stored hash. Accounts live in Cloudflare D1.
Router
The model router runs on the lab's own server and calls the upstream providers.
Providers
Upstream providers process prompts under their own terms.
What we keep, and for how long
| Data | Kept | Why |
|---|---|---|
| Face templates, encrypted (only if you turn on face check) — never photos or video | Until you remove face check | Second factor, or face-only sign-in on a device you trusted |
| Request metadata: model, token counts, cost, timing | Billing records | To bill you and enforce spend caps |
| Response cache | 1 hour | Serve exact repeats at cached rates |
| Conversation-prefix hashes | 1 hour | Bill resent earlier turns at the cached-input rate |
| Pre-answer briefs | 24 hours | Avoid re-briefing the same task |
| Request content beyond those caches | Not stored | — |
| API traffic for training | Never used | — |
Send x-tempest-cache: off to bypass the response cache on any request.
Failure ID, locked down
Hashed passwords
Passwords are stored as PBKDF2 hashes, never in plain text.
Two-factor
TOTP authenticator codes with one-time recovery codes for when you lose the phone.
Passkeys
WebAuthn passkeys. We store only the public key.
Revocable sessions
Every signed-in session is listed in the console, with its device, and can be revoked in one click.
Audit log
Sign-ins, factor changes and key events are recorded in your account audit log.
Invite-only accounts
Nobody can create a Failure ID without an invite key the lab issued. Keys can be single-use, expire, and be revoked; every account records which key created it.
GitHub and Google sign-in are available once they are configured. Staff mail at mail.failure.fail requires two-factor.
Shown once. Stored hashed.
A key is displayed a single time when you create it, then kept only as a hash. If you lose it, revoke it and make another. Give every key a monthly spend cap so a leaked key has a ceiling.
Key hygiene
- One key per service and environment.
- Keep keys in a secret manager or environment variable, never in client code.
- Set a spend cap on every key.
- Revoke keys you no longer use.
What we do not have
We are a small lab. We do not hold a SOC 2 report, and we do not offer SAML SSO or SCIM; all three are on the roadmap. We do not offer an uptime SLA. We would rather tell you this here than in the middle of a review.
Found something?
Write to us with the details and steps to reproduce. Please give us a fair chance to fix it before you publish.