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.