Trust

Security and data protection

You are being asked to connect your books. Here is exactly what happens to them, in plain language, with no marketing in the way.

Read-only

We can read your QuickBooks data. We can never write to it or change it.

Isolated

Three independent layers keep your data separate from every other company.

Encrypted

AES-256 at rest, TLS 1.2+ in transit, enforced by HSTS.

Security & Data Protection at MainStreetCFO

Last updated: April 2026

MainStreetCFO's platform helps small businesses understand their finances through AI-powered dashboards and analysis. We take the responsibility of protecting your financial data seriously. This document describes where your data lives, how it's protected from outside threats, and how we prevent one customer's data from ever being visible to another. We've written it to be honest rather than marketing-polished - if something is a work-in-progress, we say so.


1. Where Your Data Lives

All customer data is stored with industry-standard cloud providers. MainStreetCFO does not operate its own servers or hold customer data on employee devices.

| Data type | Storage provider | Infrastructure | |---|---|---| | Financial records (transactions, invoices, chart of accounts) | Supabase (PostgreSQL) | AWS | | Uploaded files (CSV, Excel, PDF) | Supabase Storage | AWS S3 | | Third-party OAuth tokens (QuickBooks, Plaid, etc.) | Supabase, additionally encrypted at our application layer | AWS | | Account credentials | Supabase Auth | AWS | | Chat history and AI-generated insights | Supabase (PostgreSQL) | AWS | | Backups | Managed point-in-time recovery | Supabase / AWS |

All infrastructure providers we depend on - Supabase, Vercel (our application host), and AWS - are themselves SOC 2 attested. Your data inherits the physical, network, and operational security of their data centers, which is among the best available.

Third parties that process your data

To deliver AI features, specific portions of your data are sent to AI model providers:

  • Anthropic (Claude) - receives chat messages and the context needed to answer your questions
  • Google (Gemini) - receives samples of files during upload processing

These providers are bound by their own enterprise data-handling terms. We do not send data to third-party analytics, advertising, or tracking services. Stripe processes billing information only; Plaid, QuickBooks, Gusto, and Google Drive each see only the data from their own connection that you have explicitly authorized.


2. How We Keep Your Organization's Data Separate From Others

This is the single most important protection we offer: an absolute guarantee that users from one organization cannot see, modify, or access data belonging to another organization. We enforce this through three independent layers of defense, any one of which would prevent a cross-organization data leak on its own.

Layer 1: Database-enforced isolation

Every record in our database carries an organization identifier. Our database engine itself - not just our application code - refuses to return any record whose organization identifier doesn't match the requesting user's memberships. This is called Row Level Security, and it operates at the level of PostgreSQL itself. Even if our application code contained a bug that tried to read another organization's data, the database would return nothing.

Layer 2: Application-level verification

Before any data leaves our servers, our application verifies the user's organization membership against our member database. If a request claims to act on behalf of an organization the user isn't a member of, it is rejected with a 403 Forbidden error. The user's session identity comes from a cryptographically signed cookie that cannot be forged by the browser.

Layer 3: Storage isolation

Uploaded files (statements, exports, receipts) are stored in per-organization folders. Our storage platform enforces that users can only read or write files in folders belonging to organizations they're members of. A file uploaded by Company A is structurally invisible to any user in Company B.

Independent verification

This isolation is not just a claim. Our automated test suite includes dozens of tests that specifically attempt to break cross-organization isolation using malformed queries, injection attempts, parameter spoofing, and other common attack techniques. Every attempt is rejected. We've also subjected the query engine that powers our dashboard widgets to injection testing: no user-provided input (including input provided via AI) is ever interpolated into a database query without being strongly validated against a hardcoded list of allowed fields.

Shared infrastructure, isolated data

Like most modern SaaS products, MainStreetCFO uses a shared database to serve many customers. This is the standard architecture for cloud-native software - companies like Notion, Stripe, Linear, and Vercel all operate this way. The tenant isolation described above is the industry-accepted mechanism for making this architecture safe. If your organization requires physically separate infrastructure (a dedicated database instance with customer-managed encryption keys), that's available on our Enterprise plan.


3. Protection From External Threats

We apply defense-in-depth against external attackers.

Secure connections everywhere. All traffic to our application uses TLS 1.2 or higher. Our domain is pinned to HTTPS-only for a full year via the HSTS header, so a browser that has visited us before cannot be tricked into connecting over an insecure channel.

Session security. Authenticated sessions are stored in HttpOnly cookies that JavaScript cannot read (preventing theft via injected scripts) and Secure-flagged so they never travel over unencrypted connections. Cross-site request forgery is blocked by validating the origin of every state-changing request against an allowlist.

SQL injection is impossible. Every database query is built from parameterized statements; no user input is ever concatenated into SQL. Our newer query engine for AI-generated dashboard widgets goes further: it accepts only strongly-typed query specifications validated against a hardcoded list of allowed fields, then executes them through a read-only database function with a 5-second timeout. Even an AI model that attempted to construct a malicious query would be unable to produce a query specification that gets past our validator.

Input validation on every endpoint. All incoming API requests are validated against strict schemas that enforce length limits, type constraints, and field formats before the request reaches any business logic.

Rate limiting. Authentication attempts, AI calls, and file uploads are rate-limited using a sliding-window algorithm backed by a distributed cache. This protects against credential stuffing, brute force, and abuse of our AI features.

Token encryption. When you connect QuickBooks, Plaid, or another integration, the access tokens we store on your behalf are encrypted with AES-256-GCM at our application layer before they reach the database. This is on top of the database's own at-rest encryption - your tokens sit encrypted inside an encrypted database.

Error handling. Our API returns generic error messages without revealing stack traces, database schemas, or internal system details.

What we're working on

  • Rate limiting on all data-analysis endpoints (currently on auth, AI, and upload endpoints)
  • Automated dependency scanning to catch vulnerabilities in third-party code
  • Third-party penetration testing (planned for the SOC 2 Type I readiness process)
  • OAuth state token expiration (currently signed but non-expiring)

4. Encryption

| Data in transit | TLS 1.2+ on all connections, enforced by HSTS | | Database at rest | AES-256 (managed by Supabase) | | File storage at rest | AES-256 (managed by Supabase Storage) | | OAuth integration tokens | AES-256-GCM at our application layer, in addition to database encryption | | Session cookies | Cryptographically signed by our authentication provider |

Enterprise customers with regulated-industry requirements can request customer-managed encryption keys on a custom contract.


5. Who Inside MainStreetCFO Can Access Your Data

MainStreetCFO is an early-stage company. Like most companies our size, members of our engineering team who hold administrative credentials for our infrastructure (our database and hosting accounts) have the technical ability to query customer data while performing debugging, incident response, or customer support work. This is a standard operational reality for any hosted SaaS product, including ones much larger than ours.

What we do today:

  • The set of people with production access is small (a handful of people, all subject to background checks before being granted access)
  • All production credentials are stored in secrets management, never in source code or personal devices
  • Multi-factor authentication is required for all administrative accounts
  • We do not download customer data to local devices except in rare debugging situations authorized in writing by the customer

What we're building, in order of priority:

  • Complete audit logging of every administrative action - who did what, when, and to which organization's data. A partial version ships this quarter.
  • Customer-visible access records - a log you can see showing when (and why) a MainStreetCFO employee accessed your organization's data. This is not yet available.
  • Just-in-time access - time-limited access grants for debugging, expiring automatically, replacing standing administrator access.
  • Two-person rule for production data queries - any non-routine access requires a second team member's approval.
  • SOC 2 Type I attestation - this includes formal independent verification of our access controls, planned for this year.
  • Dedicated database per customer at scale - as MainStreetCFO grows, we plan to migrate larger customers onto physically isolated database instances. A dedicated database removes the shared-infrastructure concern entirely: your data sits on its own server, with its own backups, and with no possibility of a cross-tenant query even in theory. We haven't made this move yet because our current shared architecture delivers real benefits while we're small: faster product iteration, lower operational overhead, consistent security patches applied to one environment instead of many, and pricing that stays accessible to small businesses. The three-layer isolation described in section 2 is specifically designed to make the shared model safe during this phase, and it's the same architecture used by much larger SaaS companies. Dedicated databases will be available first on our Enterprise plan and, over time, will become the default as our scale justifies the cost.

We will update this section as these controls come online. If you are evaluating MainStreetCFO for a use case where these controls are prerequisite, we're happy to discuss an enterprise agreement that includes contractual commitments covering access logging and notification.


6. Account Lifecycle and Deletion

When a user is removed from an organization, their ability to access the organization's data is revoked immediately.

When a user account is deleted, their personal chat history is cascaded and removed. Business data they contributed (uploaded files, transactions they imported) remains with the organization for continuity, with their personal identity removed from the record.

When an organization is deleted, all of its data - transactions, invoices, files, chat history, widgets, integrations - is cascaded and removed. OAuth tokens are revoked where the provider supports revocation.

Database backups follow our infrastructure provider's retention policy (typically 7-30 days of point-in-time recovery). After that window, deleted data is irrecoverable.

If you need a data export or a deletion request under GDPR, CCPA, or another regulation, contact us at admin@mainstreetcfo.ai. We aim to respond within 5 business days and complete requests within 30.


7. What This Means For You

If you're evaluating us for standard small-business use: the cross-organization isolation, encryption, session security, and input validation we have in place are consistent with industry practice for reputable SaaS products. Your data is protected against external attackers by a layered defense that compares favorably to most tools of our size.

If you're evaluating us against strict enterprise or regulated-industry requirements: we are not yet SOC 2 attested and do not yet offer customer-managed encryption keys, customer-visible internal access logs, or a formally documented incident response program. These are on our roadmap. If you need those controls as a condition of adoption, we can discuss an enterprise contract that commits us to specific delivery timelines and provides interim protections (contractual access notification, data-processing agreements, etc.).

What we won't do: claim certifications we don't have, hide gaps in our controls, or make security promises we can't verify. We'd rather win your business with an honest "we're working toward that" than a glossy overstatement that falls apart under diligence.


8. Reporting a Security Concern

If you believe you've discovered a security vulnerability in MainStreetCFO, we want to hear from you before anyone else does. Please email admin@mainstreetcfo.ai with the details. We commit to acknowledging your report within 48 hours and keeping you informed of our progress toward remediation. We ask that you do not publicly disclose the issue until we've had a reasonable opportunity to fix it.


Questions about security, compliance, or enterprise requirements? Contact admin@mainstreetcfo.ai.

Security question not answered here? Email us.