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.
| Layer | Provider | Role | Certification |
|---|---|---|---|
| Database | Supabase (AWS) | PostgreSQL + RLS + Auth + Realtime | SOC 2 Type II |
| CDN / DDoS | Cloudflare | TLS termination, DDoS mitigation, CDN | ISO 27001, SOC 2 |
| Resend | Transactional email + SPF/DKIM/DMARC | SOC 2 Type II | |
| Serverless Functions | Supabase Edge Functions | Privileged server-side operations | SOC 2 Type II |
| Frontend | Static CDN | React SPA served over HTTPS | N/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.
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.
is_suspended flag, not just the application layer.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.
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.Encryption at rest and in transit
| What | How | Standard |
|---|---|---|
| Data at rest | Supabase PostgreSQL on AWS RDS | AES-256 |
| Data in transit | Cloudflare TLS termination, HTTPS enforced | TLS 1.2+ |
| Service role key | Stored only in Edge Function environment variables | Never client-exposed |
| User sessions | JWT signed with Supabase Auth secret | HS256/RS256 |
| Email delivery | SPF, DKIM, DMARC via Resend | mail.cshubb.com |
| Webhook payloads | HMAC-SHA256 signature (Pro/Enterprise) | X-CSHUBB-Signature header |
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).
| Provider | Data path | Key storage | Offline option |
|---|---|---|---|
| Groq | Browser → Groq API | localStorage only | No |
| Anthropic Claude | Browser → Anthropic API | localStorage only | No |
| Google Gemini | Browser → Google AI API | localStorage only | No |
| LM Studio | Browser → localhost | None required | Yes — 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.
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 Pro and Enterprise plans, payloads are signed with HMAC-SHA256 using a per-webhook secret so receiving systems can verify authenticity.
| Plan | Webhook support | Signing | Max endpoints |
|---|---|---|---|
| Trial / Starter | None | — | 0 |
| Growth | HTTP POST | Secret token | 3 |
| Pro | HTTP POST | HMAC-SHA256 | 10 |
| Enterprise | HTTP POST | HMAC-SHA256 | Unlimited |
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.
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.
- Access controls
- Audit logging
- Encryption at rest + transit
- Availability monitoring
- Data minimization
- Purpose limitation
- Right to deletion (built-in)
- No 3rd-party data sharing
- RBAC + role management
- Encryption controls
- Multi-tenant isolation
- Incident response process
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.
© 2026 CSHUBB Innovations · Security Whitepaper v1.0 · This document is subject to change as the platform evolves.