Security & Trust

Security is built into the database layer, not bolted on at the edge. Here are the real controls every system ships with — in plain terms, for the engineer evaluating us and the business trusting us with its data.

The controls

Isolation at the database layer

Security lives in Postgres, not in application discipline. Every product enables Row-Level Security on every table, from day one.

Multi-tenant products (AdminOS) enforce isolation by comparing the JWT tenant_id to the row tenant_id in an RLS policy on every table — tenant_id is always resolved server-side from the authenticated token, never trusted from the client.
The privileged service-role key is confined to server-only paths (webhooks, cron, billing) and never reaches the browser; standard reads/writes run under the user's RLS context.
Published-only public reads, author-only updates, and soft-delete (deleted_at) are the default RLS posture — records are never hard-deleted.

Signed, replay-resistant webhooks

Every inbound webhook is cryptographically verified before it can touch data — with constant-time comparison and, where relevant, a replay guard.

Meta WhatsApp Cloud API: HMAC-SHA256 over the raw body (x-hub-signature-256), compared with a timing-safe equality check; an invalid signature is a 401.
PayFast ITN: MD5 signature plus a source-IP check before any plan or order state changes.
Internal system-to-system calls (store ↔ engine): Bearer key + HMAC-SHA256(body) outbound; signature over timestamp.body inbound, with a five-minute replay window.
Paystack (True Access): HMAC-SHA512 verification on the payment webhook.

Rate limiting & abuse control

Public surfaces are gated before they reach the database or an LLM, so cost and abuse are bounded.

Edge protection (Arcjet) for bot, rate and shield rules on the student-facing product.
Upstash sliding-window limiters on API, webhook, AI and onboarding paths — cached as singletons to avoid re-opening Redis connections.
Per-endpoint AI budgets and per-plan daily token limits, enforced in Redis with a 429 on exhaustion.

Prompt-injection defence

A public WhatsApp number is an open pipe to a language model. Untrusted input is sanitised at ingestion, before it is ever stored.

Inbound messages are run through a sanitiser (16–17 injection patterns + a 2,000-character cap) before any database write — so no malicious payload is persisted or replayable.
Admin-supplied configuration gets a separate, stricter sanitiser to prevent cross-tenant cache poisoning.
System prompts are isolated in the model's system parameter with ephemeral caching, so injected user content can't corrupt a cached prompt.

Secrets, sessions & headers

Tokens stay out of the browser, secrets stay out of the bundle, and every response ships hardened headers.

Sessions use HTTP-only cookies — no auth tokens in localStorage; OAuth runs through PKCE.
Service-role, model and webhook secrets are never exposed as NEXT_PUBLIC and never logged; a documented inventory assigns a rotation owner.
Security headers audited on all routes: HSTS (with preload), X-Frame-Options: DENY, X-Content-Type-Options: nosniff, a Content-Security-Policy, and a restrictive Permissions-Policy.

Append-only audit & integrity

Sensitive systems keep a tamper-evident record of what happened — by construction, not by convention.

The audit log has UPDATE and DELETE privileges revoked at the database level — not even the service role can alter an entry.
Financial records (contributions, payouts, loans) carry unique receipt numbers and a recorded_by reference; an immutable before/after state is captured per change.
Inbound webhook IDs are stored UNIQUE to dedupe provider retries.

Governance — POPIA / PAIA

Compliance as operating practice

Beyond a privacy policy: documented breach response, an annual review cadence, a PAIA manual and a designated Information Officer — the operational governance most studios never write down.

POPIA breach response plan

A documented six-step procedure (detect & contain → assess → notify the Information Regulator within 72 hours → notify data subjects → remediate → post-incident review) with a four-level severity matrix and named third-party processor contacts.

Annual POPIA review

A signed yearly review across governance, lawful-processing conditions, data-subject rights, safeguards, operators, privacy notices and breach readiness — with a documented data-retention schedule.

PAIA manual

A Promotion of Access to Information Act manual establishing the company as a private body with a designated Information Officer and defined record categories (including the operator/responsible-party split for client data).

Data residency

Production data for SA-facing products is hosted in the af-south-1 (Cape Town) region; cross-border processing (e.g. the AI provider) is covered by the provider's data-processing agreement.

Where verification stands

These controls are real and in code. The most recent review was an internal pre-launch security audit (rated good, no critical findings; the medium-severity items found were resolved). Independent penetration testing is on the roadmap and is gated before scaling past 1,000 tenants — we describe what exists, not certifications we don't yet hold.

Every client build inherits these defaults.

RLS, signed webhooks, append-only audit and a documented compliance posture — you own all of it.

← Back to the Handbook Start a project →