Last updated · May 14, 2026

Security

CFO Warren handles the books and bank data of small businesses. Security is operationally important and reputationally non-negotiable. This page describes the controls in place today. It is updated as our posture evolves.

1. How your sensitive data is stored

  • OAuth tokens encrypted at the application layer. Access and refresh tokens for QuickBooks, Plaid, Stripe, and any other connected provider are encrypted with AES-256-GCM before they touch the database. The encryption key is held in environment storage, not in the database.
  • Encryption at rest by default. Our primary database (Supabase / PostgreSQL) and backups encrypt all stored data at rest using AES-256.
  • Row-level security on every customer-scoped table. Each row carries a customer_id and database policies enforce that a customer can read only their own rows. The server-side admin role is used only in code paths that explicitly scope queries by customer.
  • We do not store your provider passwords. Bank credentials are entered directly on Plaid’s hosted Link flow; QuickBooks credentials on Intuit’s OAuth page. We never see them.

2. How data is protected in transit

  • All traffic between your browser or phone and our service is encrypted with TLS 1.2+ and HSTS is preloaded for cfowarren.com.
  • Connections to third-party providers (Anthropic, Google, Plaid, Stripe, Twilio, Intuit) use TLS and provider-issued credentials over private API channels.

3. Webhooks

  • Inbound Twilio webhooks are signature-verified against the configured auth token before any action is taken.
  • Inbound Stripe webhooks are signature-verified against the configured webhook secret.
  • Webhook deduplication is enforced server-side so retried events do not double-process subscription updates or messages.

4. Access controls

  • Production database access is limited to the founder and named operators. Access is logged.
  • Service-role keys are stored in our deployment platform’s encrypted environment storage and are never committed to source control.
  • Customer-support access to identifiable data is on a need-to-know basis and limited to debugging or operating the Service.

5. AI provider boundary

  • Inputs sent to our AI providers (Anthropic, Google) for Warren’s reasoning go through a single application-level chokepoint that scrubs common patterns of sensitive data (SSNs, long digit strings that look like account numbers, key-format strings) before transmission.
  • Every AI call is logged in our database with token counts and cost; we use this to detect anomalous usage and to apply per-customer daily cost caps.

6. Operational practices

  • Database migrations are reviewable and paired with rollbacks where feasible.
  • Error tracking is in place; severe errors page operators.
  • We do not currently hold SOC 2 certification. We plan to begin a SOC 2 Type I observation period within six months of production launch, subject to revenue and traction.

7. Responsible disclosure

If you believe you’ve found a security issue in CFO Warren, please report it to security@cfowarren.com. Include enough detail for us to reproduce and triage. We commit to:

  • Acknowledging your report within two business days.
  • Keeping you updated on remediation progress.
  • Not pursuing legal action against good-faith researchers who respect the limits below.

Please do not:

  • Access accounts that are not your own.
  • Run high-volume automated scans against our production infrastructure.
  • Publicly disclose the issue before we have had a reasonable chance to address it.

8. What we ask of you

  • Use a strong, unique sign-in method (passkey, OTP, or a strong magic-link email).
  • Treat your CFO Warren account like the access path to your books: don’t share credentials.
  • Tell us at security@cfowarren.com if you suspect your account has been compromised.

9. Changes

We update this page as our security posture evolves. Material changes will be noted in the last-updated date at the top.