Security · Privacy · Compliance

Your face is
not our
training data.

Medusa processes biometric identifiers. That is a responsibility, not a growth hack. Here is how we treat your data — in detail.

01 ·

Biometric data is treated as regulated PII

Your face produces a 512-dimension embedding — a numeric signature, not a reconstructable image. The embedding is what we store, search against, and purge.

Original reference photos and liveness frames live in encrypted object storage, keyed per user, with signed URLs that expire. Nothing is publicly listable.

Illinois BIPA sets the floor for how we handle this data: explicit consent before collection, three-year retention cap, and a purge-on-delete obligation. By policy, we apply it to every user — not only Illinois residents.

02 ·

Consent is explicit, auditable, and revocable

You acknowledge what we collect before you upload a single photo. Your consent is timestamped on your account and tied to a specific copy version — if we revise the disclosure, your original acknowledgement is preserved, not overwritten.

Revoke any time. Deleting your account triggers a synchronous purge of all biometric blobs (references, liveness frames) and their pgvector embeddings. Metadata rows remain for the audit trail; the biometrics do not.

Per BIPA §15(a) we purge within 30 days; in practice the happy-path purge is immediate.

03 ·

Takedowns cannot be filed without a fresh identity check

Marking a match as unauthorized does not by itself file a takedown. A fresh liveness capture must pass within a 15-minute window, immediately before you sign the DMCA statement.

The DMCA perjury statement you sign is versioned. The statement text and version are snapshotted on the filing record. A future revision does not retroactively apply to past filings.

An impersonating admin session (Medusa's internal 'view-as' tool) cannot file takedowns, cannot change billing, cannot view raw faceprints, and cannot delete an account. Those operations are gated server-side, not just hidden in the UI.

04 ·

No open-web crawling

Medusa crawls an admin-curated list of target URLs — not the open web. A URL is added only after operator review; per-target rate limits, robots.txt policy, and crawl depth all live as first-class columns in the admin dashboard.

Every crawled image is content-addressed by SHA-256 and deduplicated across the corpus. Every source URL where the image appeared is logged separately. We never re-download the same image twice.

Known-host chrome (platform logos, UI frames, repeating stock placeholders) is perceptually-hashed and filtered out before face detection runs.

05 ·

Data stays where it needs to be

US-based object storage (Oracle Object Storage, Ashburn) by default. European customers on enterprise plans can request EU-region storage.

Cross-service communication is in-cluster only — no internal service is exposed to the public internet. The only public endpoints are the user-facing dashboards, the API, and the Stripe webhook receiver.

Every database query runs under a per-user scope — our ORM layer (Prisma) makes queries that span users a compile-time mistake, not a runtime risk.

06 ·

Operational transparency

Every state change — upload, verify, match, decision, takedown submit, verify probe, close — is append-only to an audit log.

Request IDs correlate log lines across services; a single page load traces through the API, workers, and downstream providers without ambiguity.

We ship telemetry to an in-house GlitchTip instance. No third-party analytics run on the dashboard; the marketing site uses no trackers that follow you off-site.

Compliance

Frameworks we build against.

BIPA · §15

Biometric consent + retention + purge

DMCA · 17 U.S.C. §512

Notice-and-takedown + perjury statement

GDPR-adjacent

Subject access, rectification, erasure on request

SOC 2

In progress — access logging + change management

Read the legal text