Sub-processors
These vendors process data on our behalf. We review each one against the same security standards we apply to our own service.
| Vendor | Purpose | Data | Region | DPA |
|---|---|---|---|---|
| Supabase | Authentication, Postgres database (users, API keys, manifests metadata) | Email, OAuth identity, API key metadata, manifest records | AWS us-east-1 (US) | View ↗ |
| Vercel | Web hosting (hashproof.ai), analytics, edge caching | Anonymized page-view metrics, request logs, static assets | Global edge; primary iad1 (US-East) | View ↗ |
| Cloudflare | DNS for hashproof.ai and api.hashproof.ai | DNS query metadata | Global edge network | View ↗ |
| Upstash | Redis-backed rate limiting and caching | API key identifier, per-minute request counters | AWS us-east-1 (US) | View ↗ |
| Railway | Application container hosting for the Hashproof API | Runtime logs, request metadata | us-west2 (US) | View ↗ |
| Stripe | Payment processing and subscription billing | Billing contact, payment method (held by Stripe), subscription state | Global (US-based) | View ↗ |
| Object storage provider (S3-compatible) | Manifest and asset blob storage | Uploaded asset bytes and extracted manifest bytes | US | On request |
Certifications & attestations
- SOC 2 Type I: in progress, target Q3 2026. Type II planned for 2027.
- ISO 27001: planned Q1 2027.
- GDPR & CCPA: compliant by design. A standard DPA is published for all customers.
We do not display badges for certifications we have not earned. When SOC 2 Type II is issued, this section updates with the report URL.
Data flow
- Client sends a request to
api.hashproof.aiover TLS 1.3; DNS resolves via Cloudflare and TLS terminates at the API. - Request is forwarded to the Hashproof API container on Railway (us-west2). The container validates the API key or Supabase session and consults Upstash for rate-limit state.
- Manifest metadata is stored in Supabase Postgres; uploaded asset bytes and extracted manifest bytes are stored in S3-compatible object storage; a content-address CID is computed for each record.
- On anchoring runs, the Merkle root of new manifests is recorded and inclusion proofs become available via
/v1/manifests/:id/proof. Batch roots are not submitted on-chain.
Encryption
- At rest: AES-256 via the managed database and object-storage providers.
- In transit: TLS 1.3 for client-to-API traffic.
- Signing keys: software-backed ES256 (ECDSA P-256) held by the signing service. HSM-backed and customer-managed key options are not currently offered.
Access control
- User auth: Supabase Auth with Google + GitHub OAuth and email/password. Sessions are managed by Supabase Auth and refreshed automatically.
- API keys: SHA-256 hashed at rest; plain value shown to the user once at creation. Scope-limited; rate-limited per key.
- Internal access: least-privilege RBAC over production systems. Production access is logged and audit-reviewed weekly.
Audit logs
API activity is logged with per-request metering records in the primary database. Self-service audit-log export is not currently offered.
Vulnerability disclosure
Report security issues to security@hashproof.ai. We acknowledge reports within 2 business days and commit to a status update every 5 business days until resolution.
PGP fingerprint (placeholder; replace before public launch)
C2PA 2026 HPRF PGPKEY XXXX XXXX XXXX XXXX XXXX XXXX XXXX XXXX XXXX XXXXMachine-readable policy: /.well-known/security.txt
Backups & DR
- Database: managed backups provided by the database provider.
- Object storage: durability per the storage provider.
GDPR & DPA
Our standard DPA is published at /legal/dpa; drop a line to legal@hashproof.ai for countersigned copies.
See also: Privacy Policy · Terms of Service
Recent disclosures
No security incidents disclosed to date. When we have one, it appears here and on the status page.