Supabase Auth with PKCE
Authentication uses Supabase Auth with PKCE (Proof Key for Code Exchange) — the current standard for secure OAuth flows. Sessions are managed through signed JWTs with short expiry windows and automatic refresh.
Security and data handling
insia is designed for sensitive policy records — health, vehicle, home, business, and life insurance documents. Security controls cover authentication, storage encryption, infrastructure access, AI boundaries, and broker consent at every layer.
Built on Supabase Auth — industry-standard authentication with PKCE, signed JWTs, MFA support, and database-level access enforcement.
Authentication uses Supabase Auth with PKCE (Proof Key for Code Exchange) — the current standard for secure OAuth flows. Sessions are managed through signed JWTs with short expiry windows and automatic refresh.
insia supports TOTP-based multi-factor authentication via Supabase Auth. Users can add a second authentication factor (authenticator app) to their account for an additional layer of access protection.
Every Postgres table in insia uses Supabase Row Level Security (RLS) policies. A user can only read, insert, or update rows that belong to their own account — enforced at the database layer, not just the application layer.
Supabase Edge Functions that process sensitive operations — document extraction, broker actions, email intake — are configured to verify JWT tokens before executing. Unauthenticated calls are rejected at the function boundary.
Production services run on AWS in the Sydney region (ap-southeast-2). Email intake, document processing, and storage use dedicated AWS services with least-privilege IAM controls.
Production infrastructure runs in AWS ap-southeast-2 — the Sydney region. Policy records, documents, and broker data are stored and processed in Australia in compliance with Australian data residency expectations.
Lambda functions, SES email intake, SQS queues, and Dead Letter Queues are monitored with AWS CloudWatch. Alarms fire on error spikes, throttling events, DLQ depth increases, and processing delays.
Policy documents are stored in private AWS S3 buckets. There are no public document URLs. Files are accessed through time-limited signed paths generated by authenticated server-side code only.
AWS IAM roles and policies follow least-privilege principles. Lambda execution roles are scoped to the specific S3 buckets, SES actions, and SQS queues they need — no wildcard permissions.
Documents are stored in private encrypted buckets with no public URLs. Access is always authenticated, scoped, and consent-led.
Policy documents uploaded to insia are not used to train AI models. AI assistance is applied only to explain the content of documents you provide, and only as general factual information.
Supabase Storage encrypts files at rest. All connections use HTTPS with TLS. Data does not travel unencrypted between client, server, storage, or edge functions.
Broker access is designed around explicit relationships. When you share a policy with a broker, only that policy becomes visible — not your full account. Access is revocable and logged with a timestamp.
insia is not a licensed financial, insurance or broker service. The product enforces this boundary in the UI — AI outputs are labelled as general information, and the product never positions itself as making decisions for you.
Document access should stay private, authenticated, and revocable.
Broker sharing should be selected by the policyholder and easy to pause.
AI explanations should stay factual, document-grounded, and checked against original wording.