Zero Trust Posture: What a SaaS Platform Trusts by Default

The full executive answer

Zero Trust means we assume nothing is safe just because of where it sits — every request must prove who it is, every time. In our stack that's concrete: every API call re-verifies a cryptographically signed session token from Clerk, our identity provider, before touching data (414 API endpoints, all behind the same authentication gate — a CI test, route-auth-coverage, fails the build if a new endpoint forgets it). There is no "trusted internal network"; the app and the database talk over TLS-encrypted connections and the database re-checks tenant identity on every row via Row Level Security, so even our own application isn't trusted with unscoped access.

Least privilege is written down as code, not tribal knowledge. A central policy file defines exactly which of the three roles — viewer, contributor, admin — may perform which of the platform's actions, and a test enforces that a lower role can never accidentally gain more power than a higher one. Machine access follows the same principle: customer API keys are scoped to read-only permissions, rate-limited, and stored only as a salted hash (scrypt) — we literally cannot recover a customer's key, only verify it. Outbound webhooks are HMAC-signed so recipients can verify it's really us, and inbound untrusted text is sanitised before it ever reaches an AI model.

Where we're honest about maturity: Zero Trust for our own corporate operations (device posture checks, hardware keys for every operator, formal privileged-access-management tooling) is thin because the operating team is currently tiny — the compensating control is that production access is limited to a very small number of named people, everything privileged is logged in an append-only audit trail, and MFA is enforced on the accounts that matter. Formalising that into a documented PAM procedure is part of the SOC 2 readiness work in the next two quarters.