AUDTTrust CenterSign in

Security Architecture

AUDT is built as a multi-tenant SaaS platform with defense-in-depth — every layer is independently secured so a failure at one layer does not compromise the platform.

Multi-Tenant Isolation

Every table in the AUDT database has Row-Level Security (RLS) enforced at the PostgreSQL layer. Tenant boundaries are enforced by the database engine, not application code, so there is no code path that can return data across organization boundaries.

RLS coverageAll 259+ tables — enforced at PostgreSQL layer
Auth helpersis_org_member(), has_org_role() — custom PL/pgSQL functions
Tenant keyorganization_id — every row linked to a single org
Cross-org accessArchitecturally impossible — no bypass paths

India Data Residency

All customer data is stored and processed within India. AUDT was architected for India-first data residency to support DPDP Act 2023 compliance requirements out of the box.

DatabaseSupabase Postgres — ap-south-1 (Mumbai, India)
ComputeVercel — bom1 region (Mumbai, India)
File storageSupabase Storage — ap-south-1 (Mumbai)
AI processingGoogle Gemini API — requests do not persist customer data
Regulatory alignmentDPDP Act 2023, RBI CSF, SEBI CSCRF

Layered Architecture

AUDT uses a strict layered monolith where each layer has a single responsibility and zero upward dependencies. Business logic never lives in transport layers.

Transport layer

Next.js App Router pages, server actions, REST handlers

Auth layer

requireUser() for pages — validateApiKey() for API v1

Business logic layer

lib/services/* — zero next/* imports, framework-agnostic TypeScript

Data access layer

lib/repositories/* — Drizzle ORM, optional transaction executor

Infrastructure layer

lib/providers/* — only place SDK imports are allowed

Zero-Trust Authentication

Authentication is layered — Supabase Auth manages identity, AUDT adds session records, device trust, and enterprise enforcement on top.

Identity providerSupabase Auth (email + magic link + OAuth ready)
RBAC7 roles: owner · admin · member · viewer · compliance_manager · security_manager · procurement_manager
MFATOTP (RFC 6238) — enrollment, recovery codes, org-level enforcement
Session recordsAUDT user_sessions table — idle timeout, absolute timeout, concurrent session limits
Device trustdjb2 device fingerprint — 30-day trusted device registry
Enterprise SSOEntra ID, Okta, Google Workspace, SAML 2.0, OIDC — JIT provisioning

Session Management

Every authenticated request is validated against an AUDT session record, not just the Supabase JWT. This enables fine-grained session control independent of the auth provider.

Session cookieaudt-sid — httpOnly, 8-hour max age, SameSite=Lax
MFA cookieaudt-mfa — httpOnly, set after TOTP verification
Idle timeoutConfigurable per org (default 60 minutes)
Absolute timeoutConfigurable per org (default 8 hours)
Max concurrentConfigurable per org (default 5 sessions)
IP enforcementCIDR-based IP allowlists per resource type

API Security

The AUDT REST API uses Bearer token authentication with bcrypt-hashed keys, scoped permissions, and in-process rate limiting.

API key formatCryptographically random — stored as bcrypt hash, shown once
Permissionsread_only or read_write — enforced per endpoint
Rate limitingIn-memory sliding window — 100 / 300 / 1000 req per 60 seconds
Auth validationbcrypt compare on every request — intentionally ~100 ms
TLS enforcementssl:"require" — all DB connections, all API calls
HSTSmax-age=31536000; includeSubDomains; preload
Encryption detailsData protection