Security architecture
Last updated
Encryption in transit
All ZygenTrust endpoints serve traffic exclusively over HTTPS with TLS 1.3 where supported. HSTS is enabled with a one-year max-age and preload submission in progress. HTTP-to-HTTPS redirects are enforced at the edge.
Encryption at rest
Customer data, audit logs, and operational telemetry are stored in Postgres-grade durable storage with encryption at rest enabled at the platform level. Snapshots and backups inherit the same encryption posture.
Secret management
Worker secrets (database service-role keys, third-party tokens) are stored in the runtime's encrypted secret store. Secrets are never present in source control, build outputs, error logs, or response payloads.
- API keys are hashed with SHA-256 before storage; only the prefix is queryable.
- Raw API keys are returned to the user exactly once at issuance.
- Rotated keys invalidate the prior cache entry within seconds.
Access controls
Production access is gated by single sign-on with hardware-key MFA. Database access is least-privilege by default; engineers receive time-bounded access grants for incident response. Every privileged action is logged to the audit trail.
API authentication
Customer-facing API authentication uses bearer API keys with a deterministic
prefix (zt_live_ or zt_test_) followed by 24+ bytes
of entropy. The first 8 bytes after the prefix form a lookup index; the full
key is verified by SHA-256 hash comparison against the stored digest.
- Test keys still consume their own monthly quota; they are not a billing bypass.
- Free self-serve test keys are issued from the dashboard, while paid keys remain manually provisioned.
- Revoked or rotated keys are rejected after cache refresh, with explicit invalid-key responses.
Logging and monitoring
We log per-request usage metadata (route, status, latency bucket, plan, cache
hit) for product analytics and abuse detection. We do not log full request
bodies, raw API keys, or end-user PII. Aggregated metrics are surfaced via
the /v1/health family of endpoints.
Collector failures are treated as soft failures where possible. The API prefers returning partial evidence and reduced confidence over silently hiding instability.
Tenant isolation
Customer data is isolated at the row level via Postgres row-level security. Service-role access is restricted to the API runtime and bypasses RLS only for documented operational paths (e.g. quota enforcement, audit writes). No customer-side query path can read across tenant boundaries.
Supply chain
Production dependencies are pinned to exact versions in the lockfile. Dependabot is enabled for security advisories. We avoid one-letter packages, typosquat-prone names, and binary-fetching install scripts.
All builds are reproducible from the locked dependency graph. The runtime is serverless and stateless; deployment artifacts are signed and verified at publish time.
For incident reporting, vulnerability disclosure, or DPA requests, see the Trust Center.