Security

Hadar runs as a multi-tenant SaaS platform. The most important security property of a multi-tenant CRM is hard tenant isolation — your leads, your conversations, your invoices, and your team must never become visible to another tenant under any sequence of clicks, API calls, or background jobs. We treat that as a non-negotiable invariant and defend it with layered controls: database Row-Level Security, an application-layer tenant assertion, audit logging on every privileged path, and standing test coverage that fails the build if a cross-tenant read becomes possible.

This page summarises the controls available to you as a customer, the controls Hadar runs on the platform, and the split between the two — the “shared-responsibility model”.

Authentication

Email + password with bcrypt at cost=12. Login is rate-limited per account and per IP, and falls closed if the rate-limit backing store is unreachable — better to ask a legitimate user to retry than to let an attacker spray credentials during a Redis incident.
HttpOnly session cookies. Sessions live in HttpOnly, Secure, SameSite=Lax cookies. JavaScript on the page cannot read them, which neutralises the most common XSS-to-session-theft attack chain.
JWT issuer and audience validation. When we issue and validate JWTs (for API keys, webhook signatures, and internal service-to-service calls), every token carries a strict iss and aud claim and we reject any token that does not match the exact expected values for the receiving service. This prevents a token minted for one service being replayed against another.
Single sign-on (SSO). SAML 2.0 and OIDC for Enterprise tenants, with just-in-time provisioning, role mapping from IdP groups, and SCIM 2.0 for lifecycle.
API keys. Per-workspace tokens with role scope, last-four display in the UI, and 90-day rotation reminders for any key that has not been rotated.

Multi-factor authentication (MFA)

Hadar supports TOTP-based MFA for every operator. Enable it from Settings > Security > Two-factor authentication. Workspace admins can enforce MFA workspace-wide; we strongly recommend doing this before connecting production WhatsApp, voice numbers, or payment provider keys. Recovery codes are generated on enrolment and shown once — store them offline. Re-enrolment after losing both the authenticator and the recovery codes requires identity verification by support.

Tenant isolation — defense in depth

Tenant isolation is implemented in two independent layers. Either one alone would be enough to keep data segregated; running both means a developer mistake at one layer cannot leak data on its own.

Database RLS: Postgres Row-Level Security is enabled on every tenant-bearing table. Policies are scoped by tenant_idand the active session's tenant context. Even raw SQL from a Postgres client cannot see another tenant's rows without an explicit, audited break-glass.
Application-layer tenantWhere assertion: our Prisma extension asserts the tenant filter on every read and write. A query that omits the tenant filter throws at runtime rather than executing against the whole table. This catches the rare case where a developer writes a query that bypasses RLS — for example via an admin connection or a future migration script.

Build-time tests assert that the runtime cannot return cross-tenant rows under a long list of edge cases (admin override, batch jobs, background workers, search indexers, analytics-export jobs). A regression here fails CI on the pull request.

CSRF protection

All state-changing endpoints use a double-submit CSRF token: a token issued as a cookie must match a token sent in a header on every POST, PUT, PATCH, and DELETE. The pair is rotated on login, on tenant switch, and on long-lived sessions. CSRF protection runs uniformly across the operator UI and the customer-facing API surface; public webhook receivers use HMAC signatures instead (covered in WhatsApp).

Rate limiting — fail-closed

Rate limits protect authentication, lead-capture, AI inference, voice calling, and payment endpoints. The limiter is fail-closed: if the backing Redis instance is unreachable, requests that would otherwise be rate-limited are rejected with a clear error rather than allowed through unrestricted. This is the right trade-off for a CRM holding contact data — an attacker probing under a degraded limiter is the worst time to fall open.

Encryption

In transit: TLS 1.3 with a strict cipher suite. HSTS preload is enabled on the apex domain.
At rest: AES-256 across Supabase Postgres, Supabase Storage, and the Vercel build cache.
Integration tokens, secrets, and PII columns are envelope-encrypted with a platform key (PLATFORM_ENCRYPTION_KEY). Every ciphertext is stored with a key version; we can rotate the platform key without downtime by issuing a new version, re-wrapping rows during background re-encryption, and retiring the old version once no ciphertext references it. Audit records of every rotation are retained for the life of the workspace.
Webhook payloads for sensitive integrations carry per-tenant HMAC secrets, versioned in webhook_secrets so a leaked secret can be rotated without re-onboarding the integration.

Data residency

Production data resides in the EU by default. Supabase Postgres and Storage are provisioned in eu-central-1 (Frankfurt). Vercel serves the application from EU edges; cache nodes outside the EU do not hold PII. For UAE-resident tenants who require domestic data residency under sector-specific guidance, Hadar can provision into an AWS Bahrain region under an Enterprise order form. See the public residency note linked from /legal/privacy.

Audit logs

Every privileged action — login, role change, integration token rotation, lead deletion, bulk export, RLS break-glass, key rotation — is written to audit_logs with the actor, the target, a trace_id, and a SHA-256 hash of the source IPsalted per workspace. We deliberately store the hash, not the IP itself, so an audit record is useful for detecting repeated abuse from one address without retaining a direct identifier. Logs are retained 12 months by default and downloadable as CSV from Settings > Audit logs.

Sentry and observability — PII scrubbing

Errors and slow requests are reported to Sentry. Before any payload leaves the application, we run a PII scrubber that strips email addresses, phone numbers, names, message bodies, WhatsApp payloads, ID document fields, payment information, and other lead-identifying data from breadcrumbs, request bodies, and stack-frame locals. The same scrubber is applied to logs forwarded to our log pipeline. The result is that an engineer triaging an incident sees the shape of the problem without seeing your customers' data.

Breach notification

Hadar follows two regulatory standards for breach notification, whichever is stricter for your tenancy:

UAE PDPL (Federal Decree-Law 45 of 2021, Art. 13) — controller and data subject notification without undue delay where there is a risk of harm.
GDPR Art. 33 — supervisory authority notification within 72 hours of becoming aware of a personal data breach, and notification to affected data subjects without undue delay where the risk to rights and freedoms is high.

Our incident response runbook treats every confirmed breach as in-scope for both regimes and defaults to the tightest clock. Contracted Enterprise tenants receive direct notification to their security contact in addition to public status-page updates.

Shared-responsibility model

Hadar is responsible for: hosting, encryption (in transit, at rest, and envelope), authentication primitives, tenant isolation, vulnerability management, dependency patching, audit logging, the controls listed above, and the SLA-bound incident response.

The operator is responsible for:

Choosing strong passwords and enabling MFA on every account.
Rotating API keys and integration tokens on a documented cadence.
Reviewing the audit log on at least a monthly cadence.
Granting the minimum role required for each teammate and revoking on departure.
Reporting any suspected incident to security@hadar-ai.com the moment it is suspected, not after it is confirmed.

Reporting a vulnerability

Email security@hadar-ai.com. We acknowledge within one business day and aim to remediate critical vulnerabilities within seven days. Responsible-disclosure researchers are welcome. We do not currently run a paid bounty programme but acknowledge contributions publicly with the researcher's consent.