CS
CSHUBB
Security Whitepaper · v1.0 · 2026

CSHUBB Security
Architecture Overview

A technical overview of CSHUBB's security architecture, data handling practices, compliance alignment, and operational security controls.

Supabase RLSPasswordless AuthAES-256TLS 1.2+HMAC WebhooksSOC 2 AlignedGDPR Aligned
CSHUBB Security Whitepaper · Version 1.0 · June 2026
1. Executive Summary

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.

Key security guarantees
Zero passwords stored · Database-level tenant isolation (RLS) · AI keys never touch our servers · Full audit trail on every action · Passwordless authentication · Encryption at rest and in transit
2. Architecture Overview

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.

LayerProviderRoleCertification
DatabaseSupabase (AWS)PostgreSQL + RLS + Auth + RealtimeSOC 2 Type II
CDN / DDoSCloudflareTLS termination, DDoS mitigation, CDNISO 27001, SOC 2
EmailResendTransactional email + SPF/DKIM/DMARCSOC 2 Type II
Serverless FunctionsSupabase Edge FunctionsPrivileged server-side operationsSOC 2 Type II
FrontendStatic CDNReact SPA served over HTTPSN/A

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.

3. Authentication

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.

No passwords stored or hashed anywhere
Single-use tokens with short expiry
JWTs signed and validated server-side on every request
Session invalidated server-side on logout
Eliminates credential stuffing and brute-force attacks
Email domain verified at authentication time
Access control model
First user to join a workspace is automatically assigned the Admin role. Subsequent users join as Members. Admins can revoke any user instantly from the Admin panel — revocation is enforced at the database level via the is_suspended flag, not just the application layer.
4. Data Isolation

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.

Technical implementation
RLS policies use WITH CHECK on all write operations in addition to USING on reads. This prevents both unauthorised reads and unauthorised writes, including attempts to insert data into another organisation's namespace.
5. Encryption

Encryption at rest and in transit

WhatHowStandard
Data at restSupabase PostgreSQL on AWS RDSAES-256
Data in transitCloudflare TLS termination, HTTPS enforcedTLS 1.2+
Service role keyStored only in Edge Function environment variablesNever client-exposed
User sessionsJWT signed with Supabase Auth secretHS256/RS256
Email deliverySPF, DKIM, DMARC via Resendmail.cshubb.com
Webhook payloadsHMAC-SHA256 signature (Pro/Enterprise)X-CSHUBB-Signature header
6. AI & Data Privacy

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).

ProviderData pathKey storageOffline option
GroqBrowser → Groq APIlocalStorage onlyNo
Anthropic ClaudeBrowser → Anthropic APIlocalStorage onlyNo
Google GeminiBrowser → Google AI APIlocalStorage onlyNo
LM StudioBrowser → localhostNone requiredYes — 100%

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

7. Access Control

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.

No self-service registration
Admin-generated single-use invite codes
Instant user revocation via Admin panel
Revocation enforced at database level (is_suspended flag)
Multi-org access controllable per user (allow_multi_org)
All admin actions logged with full attribution
8. Webhooks & Integrations

Webhook security controls

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

PlanWebhook supportSigningMax endpoints
Trial / StarterNone0
GrowthHTTP POSTSecret token3
ProHTTP POSTHMAC-SHA25610
EnterpriseHTTP POSTHMAC-SHA256Unlimited
9. Audit Logs & Monitoring

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 analytics scripts, no session recording, and no tracking cookies.

User logins and session starts
Account create / edit / delete
AI tool runs (tool + provider + account)
CSV imports and JSON exports
Bulk edit and bulk delete operations
Admin actions (invite codes, role changes)
Webhook create / update / delete
Help requests and feedback submissions
Account deletion requests
10. Compliance Alignment

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.

SOC 2
  • Access controls
  • Audit logging
  • Encryption at rest + transit
  • Availability monitoring
GDPR
  • Data minimization
  • Purpose limitation
  • Right to deletion (built-in)
  • No 3rd-party data sharing
ISO 27001
  • RBAC + role management
  • Encryption controls
  • Multi-tenant isolation
  • Incident response process
11. Shared Responsibility

What CSHUBB owns vs. what you own

CSHUBB is responsible for
RLS policy enforcement and correctness
Secure authentication infrastructure
Server-side key management
Infrastructure security (Supabase/AWS/Cloudflare)
Application security (XSS, CSRF, injection)
Audit log integrity
Your organisation is responsible for
Protecting email accounts used for magic link login
Safeguarding browser sessions on shared devices
Managing invite codes responsibly
Revoking access promptly when staff leave
Protecting AI provider API keys in browsers
GDPR compliance for the data you store in CSHUBB
12. Contact & Reporting

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.

Security Team
Vulnerability reports · Architecture questions · Compliance enquiries
security@cshubb.com →

© 2026 CSHUBB Innovations · Security Whitepaper v1.0 · This document is subject to change as the platform evolves.