Trust & Security

Trust & Security at Filtrate

The compliance layer marketplaces use — built to be auditable from day one. This page documents how we handle data, who our sub-processors are, and what we do to keep your pipeline secure.

Last updated: 2026-05-27

Data Handling

Filtrate is designed to minimize data exposure at every step. The architecture is intentionally simple: image bytes arrive, get processed in-memory, and the processed result goes to storage. The original never does.

Image Lifecycle

1. Image received in-memory only
Uploaded bytes land in Node.js process memory (multer memoryStorage). Nothing is written to disk. Render's ephemeral filesystem is never touched for image data.
2. EXIF/metadata stripped
Sharp processes the input buffer with .webp({ quality }) — no .withMetadata() call, so all EXIF, IPTC, XMP, and GPS tags are stripped before any downstream step.
3. MD5 hash computed hash only — no image bytes
An MD5 of the original input is used as a cache key for AI moderation verdicts. The hash is stored in verdict_cache. No image bytes are stored alongside it.
4. Processed WebP uploaded to R2 EXIF-clean
Only the processed, metadata-free WebP output is stored — via Cloudflare R2 (Polsia proxy). The original input bytes are never written anywhere. Original bytes leave memory when the request ends.
5. Compliance verdict returned
AI moderation runs on the processed WebP (after EXIF strip). Result is returned to the caller and optionally cached by MD5. No PII leaves this step.

Retention

Original image bytes
Never persisted
In-memory only. Discarded when request completes.
Processed WebP output
Stored in R2
EXIF-clean WebP, CDN-delivered. Accessible via the URL returned in the API response.
Usage logs
18 months
API key ID, timestamp, endpoint. Used for billing. No image content.
Verdict cache
Indefinite
MD5 hash → moderation verdict. No PII, no image bytes.
Processing records
Indefinite
Timing metrics, sizes, verdict label. No image content.
Processing region
AWS us-east-1
Render + Neon hosted in US East. EU residency on roadmap.

Sub-Processors

We use a small, stable set of third-party processors. All are SOC 2 certified or equivalent. If a new processor is added, we will update this page and notify enterprise customers.

Processor Purpose Data Shared Region DPA / Security Docs
Render Application hosting — runs the Express API server All inbound API traffic; no data stored by Render beyond logs us-east-1 (AWS) render.com/dpa
Neon PostgreSQL database — stores usage logs, API keys (hashed), invoices, and verdict cache API key hashes, usage metadata, billing records. No image bytes. us-east-1 (AWS) neon.tech/privacy
Cloudflare R2 Object storage — stores processed (EXIF-stripped) WebP output images Processed WebP bytes only. Original input never reaches R2. Global (Cloudflare network) cloudflare.com/trust-hub
OpenAI AI content moderation — GPT-4o-mini vision evaluates the processed WebP for compliance flags Processed WebP bytes (post-EXIF-strip). No original input, no PII from your users. US (OpenAI API) openai.com/policies
Stripe Payment processing — Stripe-hosted Checkout for invoice payment; Billing Portal for self-serve management Customer billing contact (email), payment method. No image data. US (Stripe servers) stripe.com/privacy
Postmark Transactional email — invoices, API key notifications, billing receipts Recipient email address, email body content (invoice data). No image data. US (Postmark servers) postmarkapp.com/privacy-policy

Compliance Posture

Filtrate operates as a data processor — we process images on behalf of marketplace operators (the controllers). Our DPA is available on request.

GDPR
Yes
Filtrate is a processor under GDPR Art. 28. We process image data per your instructions and do not use it for any other purpose. DPA available on request — email security@filtrate.polsia.app.
CCPA
Yes
We do not sell or share personal information as defined by CCPA. API usage metadata is used solely for billing. Processed image content is not linked to end-user identity.
SOC 2
Roadmap
SOC 2 Type I is targeted for Q4 2026 — currently in scoping. We have not yet initiated a formal audit engagement. We will update this page when the audit is underway.
ISO 27001
Roadmap
ISO 27001 certification is on the security roadmap. Currently implementing ISMS controls as part of SOC 2 preparation.
PCI DSS
Not in scope
Filtrate does not process, store, or transmit payment card data. All payments are handled by Stripe's PCI-compliant hosted Checkout. Filtrate is not a payment processor.
EU Residency
Roadmap
Processing currently occurs in AWS us-east-1. EU-resident processing is on the roadmap. EU customers may request dedicated DPA provisions in the interim.

Security Practices

How we protect the API, your keys, and the data in transit and at rest.

🔒
TLS 1.2+ enforced, HSTS
All traffic to filtrate.polsia.app is served over TLS 1.2 or higher. HTTP is not served. HSTS is configured at the CDN/load balancer layer (Render + Cloudflare). Cipher suite selection follows Render's managed TLS defaults.
🔑
API keys: bcrypt-hashed at rest, rotatable
API keys are bcrypt-hashed before storage. The plaintext key is shown only once at generation and is never logged or stored in recoverable form. Keys are rotatable at any time from the dashboard. Compromised keys can be revoked and replaced without changing application logic.
🛡️
Admin endpoints gated by X-Admin-Token
All internal admin routes (/admin/*) require a shared secret passed as the X-Admin-Token header. These endpoints are not accessible from the public API surface and are not documented in the public reference.
📦
Original image bytes never persisted
Uploaded images are held in Node.js process memory only (multer memoryStorage — no temp files). Render's ephemeral disk is never written to for image data. Original bytes are discarded when the request ends. Only the processed, EXIF-stripped WebP is stored.
🔍
Dependency scanning via GitHub Dependabot
Dependabot monitors npm dependencies for known CVEs and opens pull requests automatically. Critical and high-severity advisories are triaged within 48 hours of notification.
🚨
Incident response: 24h initial notification SLA
If a confirmed breach affecting customer data occurs, affected customers will receive initial notification within 24 hours of confirmation. Notifications include the nature of the incident, data affected, and remediation steps. Post-incident review is shared within 30 days.
🔐
Session security
Web sessions are stored in PostgreSQL (connect-pg-simple), not in-process memory. Session cookies are HttpOnly and Secure in production. Session secrets rotate on deployment. Sessions expire after 30 days of inactivity.

Vulnerability Disclosure

We follow a coordinated disclosure model. If you find a security issue, we want to hear from you — and we'll work with you to fix it before public disclosure.

Responsible Disclosure Policy

Report security vulnerabilities to security@filtrate.polsia.app. Please include a description of the issue, steps to reproduce, and your assessment of severity.

Our commitments:

• We will acknowledge your report within 2 business days.
• We will provide a status update within 7 days confirming whether the issue is valid and our intended timeline.
• We operate a 90-day coordinated disclosure window — we ask that you do not publicly disclose the issue during this period while we work on a fix.
• We will credit researchers in our release notes (or maintain anonymity at your request).

We ask that you do not exploit or exfiltrate data, perform denial-of-service attacks, or access accounts that are not your own while researching potential issues.

Need a DPA, security questionnaire, or pen-test summary?

Email us directly at security@filtrate.polsia.app, or use this form and we'll respond within 1 business day.

Evaluating providers head-to-head? See our public latency, accuracy, and cost benchmarks →