Security Overview

Brokers trust us with their clients' financial information: revenue, payroll, property values, and loss history. We build as if a compliance reviewer will ask about it on day one. This page describes what is in place today, and is honest about what isn't yet.

• TLS for all traffic between your browser, our servers, and our vendors, including verified TLS to the database.
• Encryption at rest for the database and file storage, provided by our infrastructure vendors.
• OAuth tokens and API keys are additionally encrypted with AES-256-GCM using a dedicated key kept separate from general application configuration.

• Every database query is scoped to the signed-in broker. There is no cross-account read path.
• Every server action and API route checks authorization itself, rather than relying only on page-level redirects.
• Row-level security is enabled on every table with no public policies, so the database provider's auto-generated public API can't read client data.
• Uploaded documents live in a private storage bucket, reachable only with server-side credentials.
• Sign-in is through Microsoft, so your organization's MFA and conditional-access policies apply.

• Outlook access is limited to creating drafts and reading back messages sent from them. We don't request permission to send mail.
• Login tokens and mailbox tokens are separate; sign-in tokens are never used to access mail.
• Production access is limited to the people who need it to operate the Service.

An append-only audit log records sends and other key actions, including a copy of exactly what was sent. The database itself blocks updates and deletions of audit records. It is kept for [7] years to support errors-and-omissions defense.

• Secrets are held in environment configuration, never in source code.
• Client data is kept out of application logs and error reports.
• Email-writing and AI-cost features are off by default in development and staging, so test environments don't touch real mailboxes or send real data to AI providers.

We use established infrastructure vendors and review their security posture and data processing terms. See Subprocessors.

We investigate suspected incidents promptly, contain and remediate them, and notify affected customers without undue delay (within 72 hours of confirming a breach of Customer Data, as set out in the DPA), with the details you need for your own notification obligations.

If you find a vulnerability, email [security@yourdomain.com] with the details and steps to reproduce. Please give us reasonable time to fix it before disclosing it publicly, don't access or change data that isn't yours (use your own test account), and avoid degrading the Service. We won't pursue legal action for good-faith research that follows these guidelines, and we will acknowledge your report within [3] business days.

[Planned: a machine-readable contact at /.well-known/security.txt.]