Security overview
Security-by-default at Zumik, tenant isolation, secret hygiene, encryption, and honest retention and purge, treated as baseline rather than a premium add-on.
Security at Zumik is baseline, not an upsell. Tenant isolation, secret hygiene, supply-chain integrity, and incident response are mandatory across every execution profile, including the managed-provider default.
Posture
The platform is strong by default. You do not opt into the protections below; you would have to be an enterprise tier to get more (such as customer-managed keys), but the floor is the same for everyone.
Tenant isolation
Every reusable object is namespaced by tenant, public IDs are opaque, and cross-tenant access is tested destructively in CI.
Data privacy and retention
Metadata-only tracing by default, no raw prompt logs, and explicit trace and retention modes.
GDPR and CCPA
Data residency, subject-rights flows, a signed DPA, a published sub-processor list, and Do-Not-Sell handling.
Vulnerability checklist
The vulnerability classes continuously verified as absent across services, deployments, and dependencies.
What is on by default
- Encryption in transit and at rest. TLS 1.2 minimum (TLS 1.3 preferred) everywhere; data at rest encrypted with AES-256-GCM or equivalent.
- Opaque public identities. Customer-facing handles are random opaque IDs, never raw content hashes, so they cannot leak equality relationships across tenants. See handles and fingerprints.
- Tenant-scoped fingerprint keys. Internal deduplication uses HMAC-SHA256 with a per-tenant key; rotating the key intentionally breaks equality linkage.
- Project-scoped authorization. Every API endpoint enforces the caller's project and tenant permissions. No cross-tenant read by manipulating an ID.
- Secret hygiene. API keys are stored only as a salted hash plus a masked prefix; the raw value is shown once. BYOK provider keys are sealed with AES-256-GCM and opened only at execution time. Secrets never reach a log or an error response.
- Least-privilege provider keys, short-lived service credentials, and centralized secret storage with rotation and revocation.
- No raw prompt logs. Tracing is metadata-only unless you explicitly opt into a richer mode.
- Audit logs for authentication, authorization decisions, key usage, billing changes, and purge operations.
How secrets are handled
Three classes of secret, three different treatments, none of which keeps a usable plaintext at rest:
| Secret | Treatment | Why |
|---|---|---|
| API key | SHA-256 hash plus masked prefix | Auth only needs to compare a hash; a leaked snapshot is not replayable |
| Session token | SHA-256 hash; raw token lives only in the cookie | Same reason, for the human login plane |
| BYOK provider key | AES-256-GCM sealed, opened at execution time | Zumik must use this one to call your provider, so it is reversible but never logged |
Operational controls
Beyond the request path, the platform runs signed builds with provenance, dependency and container scanning with remediation SLAs, a security review for every new provider adapter and runtime profile, routine third-party penetration testing, bastioned break-glass admin access, and a documented incident-response process with customer notification timelines.
The full posture
See the continuously-verified vulnerability checklist for the complete list of controls.
Rate limits
The three layers of rate limiting - Cloudflare edge, Bifrost per-key, and API Core per-project - the 429 with Retry-After, and the stricter limits on auth endpoints.
Tenant isolation
How Zumik namespaces every object by tenant, uses opaque IDs and HMAC fingerprints, and verifies isolation with destructive cross-tenant tests against BOLA and IDOR.