Security & Data Handling

Summary

Customer files are uploaded over TLS, stored on a private encrypted volume, sealed with AES-256-GCM at rest, isolated per-job under a cryptographically random identifier, and automatically purged after 30 days. The analysis report — the structured findings, not the original artwork — is retained so customers and their prepress partners keep a permanent audit trail. We do not share files between customers and we do not use customer artwork to train any model.

Transport security

All traffic between your browser and our API is encrypted with TLS 1.2 or higher. Certificate issuance and renewal are managed automatically by our hosting providers (Vercel for the frontend, Railway for the backend). Each request is also protected by industry-standard HTTP security headers (helmet middleware) and a strict CORS policy that limits which origins can call the API.

Encryption at rest

After extraction completes, your uploaded file is sealed with AES-256-GCM — a NIST-approved authenticated encryption algorithm. We use envelope encryption: each file gets its own random 256-bit data key, the file is encrypted with that key, and the key itself is encrypted under a master key kept in our deployment platform's environment variables, separate from the disk.

Practically, this means:

• If someone obtained a copy of our storage volume, they would see ciphertext only — there is no plaintext customer artwork at rest.
• The master key is never written to the same disk that holds the encrypted files.
• Every file uses a unique key, so cryptanalysis of one file does not weaken the others.
• The GCM authentication tag detects any tampering — a single bit-flip in the ciphertext causes decryption to fail rather than return corrupted output.
• Keys can be rotated without re-encrypting every file (we keep accepting the previous key during a rotation window).

The very short window between upload and the start of extraction is the only time the file exists in plaintext on disk; the underlying cloud volume is itself encrypted at the provider level during that window.

Access control

Every job has a cryptographically random UUIDv4 identifier (122 bits of entropy — not enumerable). For jobs uploaded by signed-in users, all download endpoints additionally enforce ownership: a valid session is required AND the session's user ID must match the job's owner. A third party who somehow obtained the URL cannot use it without a matching session.

Anonymous test-tier uploads (no account) use a capability-URL model: knowing the UUIDv4 grants access, in the same way a Dropbox share link does. This is intentional — the uploader has no account to bind the job to. The link is unguessable, but treat it like any other one-time share link: don't post it publicly.

One active session per account. When you sign in on a new device, prior sessions on other devices are revoked. Password resets immediately invalidate all active sessions.

File retention & deletion

We delete what we don't need and keep only what you'd want to look up later.

• Original artwork file — retained for 30 days after upload, then automatically and irreversibly deleted by a daily cleanup process. We do not back up these files; once they're gone, they're gone.
• Thumbnail preview — same 30-day retention as the artwork.
• Analysis report — the structured findings (verdict, dimensions, spot colors, bleed status, etc.) are retained for the life of your account so you can pull up history.
• Account information — your email, hashed password, and Stripe customer ID are kept while your account is active.

If you delete your account (write to us — full self-service delete is on the near-term roadmap), all of the above is purged from active storage. Database backups roll off within standard windows.

Audit logging

We record security-relevant events to a tamper-evident audit log: successful and failed logins, signups, password resets, file uploads, source-file downloads, report downloads, and denied access attempts. Each event captures the actor (account ID where applicable), IP address, browser user-agent, and the resource that was touched. We do not log file contents.

Audit events are retained for 365 days. If you have a compliance request — for example "show me every download of our files in Q1" — we can respond from this log.

Use of AI providers

Our analysis pipeline uses Anthropic's Claude models for several extraction and validation steps. We use Anthropic's API under their commercial terms, which means submitted content is not used to train or improve their foundation models. Anthropic processes API requests in the United States. The artwork file itself is not sent to the model — only structured extraction snapshots (dimensions, color lists, text) and, for the visual-audit pass, rendered preview images.

We do not use customer artwork to train any models of our own. Confirmed-correct golden-set entries are saved only with explicit user opt-in, in a separate workflow.

Where your data lives

Application servers and database run on Railway (US region, Google Cloud Platform infrastructure). The frontend is served from Vercel's global edge network. Cloud-provider disks are encrypted at the storage layer by default. Stripe handles all payment data — we never see your card number; we store only the Stripe customer ID associated with your account.

Application logging & PII

Application logs (kept by Railway for 30 days) record request metadata — endpoint, response code, job IDs, timing — but never file contents. Customer email addresses appear in logs only where necessary (for example, in a record of a verification-email dispatch). Stripe customer IDs may appear. We do not log passwords, password hashes, JWT tokens, or session tokens.

On the roadmap

We are deliberate about not over-claiming. The following are not in place today and will be rolled out as we move into enterprise-tier deployments:

• Customer-initiated data export (download all of your reports as a zip) soon
• Self-service account deletion endpoint soon
• Signed, short-lived download URLs that tighten thumbnail-preview access soon
• Bring-your-own-key encryption with per-tenant KMS for enterprise customers on request
• SOC 2 Type II report

If a specific control is a blocker for you adopting Preflight, write to us — we'd rather build it for a real customer than speculatively.

Incident response

If we identify a security incident that affects your data, we will notify affected accounts by email within 72 hours of confirmation, describing the nature of the incident, the data classes involved, and the steps we have taken. We may need to invalidate sessions or rotate keys as part of response, which will sign you out and require a re-login.

Reporting a vulnerability

If you discover a security issue, please email michael@preflight.art with the subject line "Security vulnerability report." We will acknowledge within 2 business days. Please give us reasonable time to remediate before public disclosure. We will not pursue legal action against good-faith security research that follows standard responsible-disclosure practices.

Contact

Security and compliance questions, NDAs, DPAs, and procurement security questionnaires: michael@preflight.art. We typically respond within one business day.