CSHUBB Security
Architecture Overview

Security-first by architecture, not afterthought

CSHUBB is a private, invite-only Customer Success workspace built for SaaS teams. Customer data is among the most sensitive business assets held by any organisation — it includes renewal dates, health scores, ARR figures, and internal collaboration history. CSHUBB was architected from day one with the assumption that security is non-negotiable.

This whitepaper describes the technical controls, architectural decisions, and operational practices that govern how CSHUBB stores, processes, and protects customer data. It is intended for security teams, compliance officers, and technical buyers evaluating CSHUBB for their organisations.

Infrastructure stack

CSHUBB is built on a serverless, managed infrastructure stack. No custom server infrastructure is maintained. All components are provided by audited, enterprise-grade vendors.

The Supabase service role key (admin-level) is stored exclusively in Edge Functions. It is never included in client-side code, never logged, and never transmitted outside the server-side execution environment.

Passwordless magic link authentication

CSHUBB uses passwordless authentication via Supabase Auth. Users receive a one-time magic link via email. Clicking the link issues a cryptographically signed JWT session. No password is ever stored, transmitted, or managed by CSHUBB or Supabase.

Row-Level Security — the last line of defence

Every workspace in CSHUBB is assigned a unique org_slug. Every table that contains customer data is partitioned by this identifier. Supabase PostgreSQL Row-Level Security (RLS) policies enforce tenant isolation at the storage engine level — not in application code.

This means: even if a bug existed in the application layer — a forgotten WHERE clause, an incorrect API parameter, a logic error — the database itself would still return zero rows from another organisation. RLS operates independently of and cannot be bypassed by application code. Every SELECT, INSERT, UPDATE, and DELETE is automatically scoped to the authenticated user's org via my_org_slug() resolved from the JWT session.

Encryption at rest and in transit

AI key isolation and data flow

When users run AI tools in CSHUBB, prompts are constructed from account data in the browser and sent directly to the configured AI provider API. CSHUBB servers are never in the data path for AI requests. AI provider API keys are stored only in browser localStorage (individual mode) or in the database encrypted at rest scoped by org_slug (org-wide mode).

For maximum data privacy, organisations can use LM Studio — AI inference runs 100% on the user's local device with zero external API calls.

Limited-use OAuth with no email content stored

The Emails module connects each user's Gmail account via Google OAuth 2.0. CSHUBB requests only the minimum OAuth scopes required to read and send email on behalf of the signed-in user. Email content is never stored on CSHUBB's servers — messages are fetched from Gmail at read time and held in browser memory only for the duration of the session.

The Meetings module similarly connects Google Calendar to create, edit, and cancel events with Google Meet links. Calendar access uses the minimum scopes required and follows the same no-server-storage model.

Invite-only access model

CSHUBB has no public signup. Every new user requires a valid invite code generated by a workspace admin. Without a valid code, first-time login is rejected at the application layer before any workspace data is accessed.

Webhook security controls

Webhook payloads contain account-level data only. They never include credentials, session tokens, or API keys. On Growth, payloads are signed with HMAC-SHA256 using a per-webhook secret so receiving systems can verify authenticity.

Growth also supports outgoing Alert Webhooks — pushing alert events to Zapier, Make, n8n, or a custom endpoint, with per-endpoint filters (alert type, CSM, ARR, health, stage) and automatic retry-on-failure.

Complete audit trail

Every action in CSHUBB is logged with full attribution — user, timestamp, event type, and context. Workspace admins can filter by event type and user. There are no third-party advertising or marketing trackers, no ad networks, and no data sold. Product analytics (PostHog, EU instance) only begin firing after a visitor explicitly accepts the cookie consent banner — nothing is tracked by default.

Two-layer backup strategy

CSHUBB runs an independent backup layer on top of Supabase's own platform-level backups, specifically to protect against platform-level incidents rather than just accidental data loss.

Framework alignment

CSHUBB's architecture aligns with the controls and principles of leading compliance frameworks. CSHUBB is currently in active private beta; formal certifications are on the roadmap for post-launch. Infrastructure providers (Supabase, Cloudflare) maintain their own certifications.

What CSHUBB owns vs. what you own

Security contact

Please report security vulnerabilities responsibly. Do not disclose issues publicly until we have had the opportunity to address them. We aim to acknowledge reports within 24 hours and provide a resolution timeline within 72 hours.