Security and data handling

Insurance documents deserve careful defaults.

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.

Private by default
Auth
RLS
Storage
Audit
AuthenticatedEncryptedScoped
Authenticate
Enforce RLS
Encrypt documents
Scope access
Log sharing

Authentication and access control

Built on Supabase Auth — industry-standard authentication with PKCE, signed JWTs, MFA support, and database-level access enforcement.

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.

Multi-factor authentication (MFA)

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.

Row Level Security on every table

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.

JWT-verified Edge Functions

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.

AWS infrastructure

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.

AWS ap-southeast-2 (Sydney)

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.

AWS CloudWatch monitoring and alarms

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.

Private S3 storage with signed URLs

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.

IAM least-privilege access

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.

Document storage and data handling

Documents are stored in private encrypted buckets with no public URLs. Access is always authenticated, scoped, and consent-led.

No AI training on your documents

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.

Encryption at rest and in transit

Supabase Storage encrypts files at rest. All connections use HTTPS with TLS. Data does not travel unencrypted between client, server, storage, or edge functions.

Scoped broker access — not full account access

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.

Advice boundary enforced in product

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.

Core security principles

Private by default

Document access should stay private, authenticated, and revocable.

Policyholder control

Broker sharing should be selected by the policyholder and easy to pause.

Advice boundary

AI explanations should stay factual, document-grounded, and checked against original wording.

Important boundary

Read the Privacy PolicySecurity FAQ