Security Overview

• Per-firm tenancy. Every customer firm is its own workspace. All data is scoped by workspace_id at the database level.
• Postgres row-level security (RLS). Every table has RLS enabled. RLS policies are tested as a non-privileged user (not via the SQL editor) so that cross-tenant access is impossible from the application layer.
• Server / client separation. The Postgres service-role key is server-only. The build pipeline scans the client bundle for it before every deploy and refuses to ship if it appears.

• In transit. All traffic to the application and APIs uses TLS 1.2+. HTTP requests are 301-redirected to HTTPS by the edge.
• At rest. Postgres data and Storage objects are encrypted at rest by our hosting provider.
• OAuth refresh tokens. Gmail and other integration refresh tokens are encrypted before they are written to Postgres using authenticated AES-256-GCM (12-byte IV, 16-byte tag, sealed with a separate key held in our secret store). Plaintext tokens never appear in logs and never cross a function boundary that returns to a client.
• Backups. Daily automatic database backups, encrypted at rest.

• Operator authentication. Email + password with passkey (WebAuthn) support and optional TOTP for sensitive accounts. Sessions use secure HttpOnly cookies.
• OAuth integrations. Gmail integration uses Google's OAuth 2.0 authorization-code flow with PKCE-equivalent state validation. We never request a password and never store one.
• Role hierarchy.Within a firm: owner > workspace_admin > licensed_pa > adjuster_in_training. Role gates are enforced both in the database (RLS) and in the application's data-access layer.
• Contractor access. Contractors (roofers, restoration vendors) get per-claim grants, never workspace-wide access. They never see fee math or settlement breakdowns by default; firm admins must explicitly enable each visibility toggle.

• Privileged content never enters the AI scanner. A hard-coded filter drops messages from attorney domains and family-court / custody-app domains before they reach the AI classifier. The decision is logged but the body is not retained.
• Zero-data-retention LLM tier. We use Anthropic's enterprise tier with zero-data-retention. Prompts and completions are not used to train models.
• System never auto-sends. Every outbound email, every e-signature request, and every phase change requires an explicit human click in the operator's UI. The AI drafts; the operator commits.

Every claim mutation, every privileged action, every contractor data event, and every admin action writes an append-only audit row recording who did what and when. The audit table is server-only (no UPDATE / DELETE policies). Operators and firm admins can review the relevant audit history in-product.

• ClaimStation employees access production data only with named-user, MFA-protected credentials and only when necessary to support a customer ticket, investigate an incident, or comply with legal process. Each access is recorded.
• We do not have a "view-as-user" backdoor that bypasses RLS without writing an audit row.

Suspected security events are triaged within one business day. Confirmed incidents affecting customer data are notified to affected operators within 72 hours, including what occurred, what data was affected, and what we are doing about it. Notification of government regulators is provided where required by law.

To report a suspected vulnerability or incident, email security@claim-station.com. We will respond within one business day.

See our Privacy Policy for the current list of sub-processors, their function, and the region in which they operate.

Operators may delete their account at any time from Settings → Profile. Detailed instructions are at /data-deletion. Deletion is soft for 30 days (recoverable on request), then hard-deleted within 90 days. Backup purges follow the backup-retention schedule.