Security
We don't see your traffic. We can't read your keys.
Driftstack's security posture starts from a single principle: Driftstack should never have a copy of anything that would let us impersonate you, intercept your traffic, or replay your sessions. The architecture below enforces that — not as policy, as code.
01 · Transport
mTLS, end to end.
Every connection between your fleet, the control plane, and our edge terminates mutual TLS. Cloudflare fronts the public edge; client-cert validation runs at our origin. No plaintext HTTP on any path — including health checks, internal control-plane traffic, and metric scrapes.
02 · Egress
Customer-controlled. Always.
Session traffic egresses through proxies you configure — SOCKS5 with UDP, WireGuard, or OpenVPN. We never see your destination URLs, never store response bodies, never act as the egress point. The control plane orchestrates session lifecycle; the session itself is yours.
03 · API keys
scrypt at rest, never in plaintext.
API keys are hashed with scrypt (logN=15) before they touch the database. Plaintext is returned exactly once, on creation; after that there is no path — admin, support, ops — to recover it. A database breach surfaces hashes, not keys. Auth runtime uses a 30-second sha256-keyed cache so verification stays fast without weakening at-rest strength.
04 · Webhooks
HMAC-SHA256, replay-windowed.
Outbound webhook deliveries carry a Driftstack-Signature header
in the form t=<timestamp>,v1=<hex>.
Customers verify with the SDK's
verifyWebhookSignature helper
(constant-time compare). The default 5-minute timestamp
tolerance protects against replay; secrets rotate per-endpoint
without touching the rest of your account.
05 · Team RBAC
Admin / member roles, scope-gated writes.
Team members read the owner's resources but only admin-role
members can write. Sessions, profiles, webhooks, API keys,
email preferences — every write route enforces the role
check at the route layer + audit-logs the actor (member id)
separately from the resource owner. Team owners review who
did what on their account at any time via
/v1/account/audit-log.
06 · No-customer-data-access posture
Driftstack staff cannot read your sessions.
Driftstack's control plane stores license metadata, session metadata (id, lifecycle status, timestamps), and aggregate usage counters. It does not store the session content itself. URLs visited, form data submitted, screenshots captured, DOM snapshots, browser cookies — these never reach our infra. For self-hosted deployments, even the metadata stays inside your network; only license-validity heartbeats reach our servers.
What we don't claim
Honest scope.
- No SOC 2. We're a small team and SOC 2 is a future-quarter goal once revenue justifies the audit cost. We say so plainly rather than implying compliance via vague "enterprise-grade" language.
- No ISO 27001. Same answer. The framework's posture matters; the certificate itself follows when the audit fits the budget.
- Sub-processors are listed. Hetzner, Neon, Upstash, Cloudflare, Postmark, Sentry, Stripe, Anthropic, Moneybird, MacStadium. Full list with purpose + jurisdiction at /trust/sub-processors.
- Data residency is EU-default. Compute, database, object storage all in the EU (Hetzner FSN + Neon EU + Upstash EU + Cloudflare R2 EU). Session execution may run elsewhere under SCCs + EU-US DPF. Detail in the same sub-processors list.
Specific question your security team is asking?
Email security@driftstack.dev with the question. We answer everything in writing — no NDAs to read a one-paragraph answer about scrypt parameters or TLS cipher suites.