Security & Trust

Last updated: 2026-04-17

Security is a first-class feature of Stride. This page summarises our actual controls. Every claim below is backed by code, configuration, or an internal runbook. For an in-depth discussion, or to request our security questionnaire responses under NDA, email info@newlightai.com.

Encryption

TLS 1.2+ in transit. AES-256 at rest via our managed Postgres (Neon) and infrastructure providers. Passwords hashed with bcrypt (cost 12). OAuth tokens and 2FA secrets are AES-256-GCM encrypted at the application layer.

Access controls

Workspace OWNER/ADMIN role separation. Workspace-level "Require MFA" policy. Platform-admin access is gated by per-action step-up auth (password + TOTP) and recorded in the workspace audit log.

Compliance posture

GDPR-aligned data handling; DPA available on request. SOC 2 Type II is on the 2026 roadmap; we do not currently claim a completed audit. FedRAMP is not in scope today. We are happy to discuss closed-beta arrangements with security-conscious agency buyers.

Data residency

Production currently runs in AWS us-east-1 (via Vercel + Neon). EU-only or US-only deployments are an Enterprise-tier conversation.

Vendor management

All subprocessors reviewed and contractually bound to equivalent protections. Full list at /legal/subprocessors. 30-day notice before any new subprocessor is added.

Resilience

Managed Postgres with point-in-time recovery via Neon. Restore procedure documented in our internal runbook (apps/platform/docs/runbooks/restore-drill.md). Uptime SLAs are contractual at the Enterprise tier.

Infrastructure

  • Application hosting on Vercel (SOC 2 Type II, ISO 27001).
  • Database on Neon (SOC 2 Type II, encrypted at rest with AES-256). Production connection strings use Neon's pooled URL; the application boot-fails if a non-pooled URL is configured.
  • Rate-limit, idempotency-key cache, and platform-admin sudo-token store on Upstash Redis (SOC 2 Type II).
  • Transactional email via Resend with SPF / DKIM / DMARC enforcement on newlightai.com. Bounces and complaints are processed via the Resend webhook into our suppression list.
  • Monorepo + CI/CD on GitHub with branch protection on main.

Application security

  • All inputs validated with Zod schemas server-side.
  • Rich-text content sanitised before storage to prevent stored XSS.
  • Non-safe cookie-authenticated requests require a same-origin signal (Sec-Fetch-Site or matching Origin). Cross-site POSTs are rejected with CSRF_ORIGIN_MISMATCH.
  • Rate limiting on all authentication endpoints; per-session read/write budgets via Upstash; per-API-key custom override caps; per-IP login lockout with reset-on-success.
  • POST routes handling money or external side effects honour anIdempotency-Key header backed by Upstash for 24 h.
  • Dependency vulnerability scanning via GitHub Dependabot (.github/dependabot.yml) with weekly grouped updates.
  • Secret-scanning on every commit via Gitleaks (.github/workflows/gitleaks.yml).
  • Content Security Policy and full security-headers suite via Next.js (HSTS 2-year preload, COOP, CORP, Permissions-Policy, X-Frame-Options).

Tenant isolation

  • Every API route runs through a single withAuthchokepoint that re-verifies workspace membership on every request (closes the “removed-user JWT-still-valid” window).
  • Workspace IDs are server-derived from the session JWT; never read from the request body.
  • Soft-deleted rows are filtered out of every Prisma read via a global$extends query extension; only narrowly-scoped restore / purge handlers see them.
  • The AI result cache is keyed per workspace so identical prompts from different tenants never collide.

AI data handling

  • We do not use your content to train shared AI models.
  • Per-workspace AI spend caps and pre-call cost gates prevent runaway usage.
  • Every AI call records the provider, model, prompt key, and resolved cost for auditability.
  • Provider zero-retention configuration depends on the contractual tier of our agreement with each provider. We're happy to walk through the current status by provider under NDA. Contact info@newlightai.com.

Audit logging

  • Privileged actions (logins, role changes, integration connects, plan changes, impersonation, audit-log exports) are recorded in a per-workspace audit log.
  • The audit log is tamper-evident: each row carries a hash of the previous row's content, and a weekly cron walks every workspace's chain and surfaces any mismatch.
  • Workspace OWNERs can export their full audit log as NDJSON or CSV via the Settings > Audit Log page; exports are rate-limited and recorded in the audit log themselves.
  • Audit-log delete paths are forbidden by a CI lint (scripts/verify-audit-log-retention.mjs) so accidental deletions can't ship.

Operational security

  • Sentry captures errors with full PII scrubbing on every runtime tier (client, server, edge). Auth headers, password/token request fields,/api/auth/* bodies, and Bearer / hex / API-key patterns in exception messages are all redacted before send.
  • Founder-led on-call rotation today; SLAs are contractual at the Enterprise tier, best-effort otherwise.
  • Incident response runbooks live inapps/platform/docs/runbooks/.
  • Stripe webhooks are signed, ordering-checked, and idempotent on the event id + per-email-kind dispatch ledger; a daily reconciliation cron diffs against Stripe and corrects drift.

What we don't (yet) claim

We'd rather be specific than aspirational. The items below are common questions; here's where each stands so you can plan your buying decision.

  • SOC 2 Type II: not completed. Roadmap target 2026. Happy to share security questionnaire responses under NDA today.
  • FedRAMP authorisation: not in scope today. We can discuss closed-beta arrangements for security-conscious agency buyers who understand we are pre-ATO.
  • Self-serve SAML / OIDC SSO: not generally available. Enterprise customers can configure SAML on request via a sales-managed path; self-serve SSO is on the 2026 roadmap.
  • Per-workspace customer-managed keys (BYOK): not available. Application-layer encryption keys are derived from a single HKDF-from-JWT_SECRET root today.
  • FIPS 140-2 / FIPS 140-3 validated crypto modules:not enforced. We use Node.js' built-in crypto primitives; formal FIPS validation lands when we move to a FIPS-eligible runtime.

Responsible disclosure

Security researchers welcome

If you believe you've found a security issue, please email info@newlightai.comwith a proof-of-concept. We acknowledge within 24 hours, patch critical issues within 7 days, and publicly credit researchers (if you'd like).

Full policy: security.txt

Contact