Trust & Safety

Security Overview

How Verdact protects your documents and account data.

Zero Retention

Documents are never written to disk or database. Ever.

TLS Encrypted

All data in transit encrypted with TLS 1.2 or higher.

Hashed Keys

API keys stored as SHA-256 hashes. Raw keys never persisted.

Zero Document Retention

The most important security property of Verdact is what we don't do: we never store your documents. Every document submitted to /detect or /redact is processed entirely in-memory within the lifetime of the HTTP request. When the request completes, the document is gone. There is no object storage, no S3 bucket, no temporary files, no database rows containing document content.

This architecture means a breach of our database or storage layer could never expose your documents — because they aren't there.

Data Isolation

Each API request is stateless and isolated. There is no cross-customer data sharing. Documents from different API keys are processed in separate request contexts with no shared in-memory state.

Encryption

In Transit

All communication between your client and the Verdact API is encrypted with TLS 1.2+. Railway (our hosting provider) terminates TLS at the edge. HTTP requests are not accepted on the API domain.

At Rest

API keys are hashed with SHA-256 before storage. Only the hash is persisted in our database — we cannot recover or display your original key. Usage logs store a SHA-256 hash of the document ID, not content.

API Security Controls

Security Headers

All responses include:

Sub-processor Security

We select sub-processors based on their security posture. Key providers:

Incident Response

Error monitoring via Sentry provides real-time alerting on anomalous behavior. In the event of a confirmed security incident affecting customer data, we will notify affected customers within 72 hours of becoming aware.

Compliance Posture

Responsible Disclosure

If you discover a security vulnerability, please report it to legal@verdact.app. We will acknowledge within 48 hours and aim to resolve confirmed vulnerabilities within 30 days. We ask that you give us reasonable time to remediate before public disclosure.