Legal
Subprocessors
Version 2026-09-24. Every provider that touches Midfire data, what it receives, and why.
How to read this page
Midfire runs on a deliberately small set of providers. Each one below links to its own privacy documentation, so you can read their commitments first-hand rather than take ours for them. Where a provider has been acquired, we name the parent company, because that is who actually governs the data today.
The short version of this list also appears in our Privacy Policy, and both are generated from the same source so they cannot disagree.
Providers
Receives. Your account (email address and name) and sign-in sessions, and your workspace: its members, folders, decisions, company context, publications, and the event log.
Why. Midfire's database and authentication run there, in the United States, encrypted in transit and at rest, with row-level security enforcing every workspace and folder rule inside the database itself.
Receives. Request traffic to the application, and cookieless page analytics events.
Why. The application runs there.
Receives. The workspace content relevant to a request, at the moment the Service drafts or assesses something for you.
Why. The models behind decision drafting and assessment, the hearing, document checks, and company context analysis. Under keys Midfire owns and manages, and not used to train models on your content.
Receives. The address of any page you add to your company context, and the page it fetches back.
Why. Reading a supplied link through one reader, rather than reaching out to arbitrary hosts directly, is what keeps that path safe.
Receives. Your plan, seats, and payment details.
Why. Billing runs on Stripe's hosted checkout and portal, which is why card numbers never touch Midfire's systems.
Receives. Your email address, and the subject and text of each message the Service sends: invitations, requests for your view, shared decisions, decision notices and digests, folder notes, and review reminders.
Why. The Service's mail leaves from a Midfire mailbox on Google Workspace.
Two things we would rather you hear from us
Both are things a technical reviewer would find on their own, so they belong here rather than in an answer to a follow-up question.
- Model calls are pooled. Everything the Service drafts or assesses for you goes to our model provider under one Midfire account shared across customers, under keys Midfire owns. The provider does not train on it.
- The reader credential is shared. Pages you add to your company context are fetched under one Midfire reader account common to all customers. The pages themselves are public, and the addresses you ask us to read reach that provider under our credentials rather than yours.
When this list changes
We add a provider only when the Service needs one, and this page changes when we do. Because the version above is shared with our Terms and Privacy Policy, a change here also asks you to accept the updated version at your next sign-in, which is our way of making sure a change is something you see rather than something you could have looked up.
Data processing agreement
If your procurement process needs a data processing agreement, ask us at hello@midfire.ai and we will send ours.
Two things worth knowing while you evaluate: any member can export the workspace as plain files from Settings at any time, so leaving needs no request to us; and access is decided by your own admins, who remove a member from their side, without needing us.
Contact
Questions about any provider on this page: hello@midfire.ai.