The short version

When you connect Gmail, Slack, or any other service to your brain, the data that flows in lives on a computer that runs only your brain — not a shared database, not a machine with other customers on it. That computer is yours until you delete it.

We don’t read your emails. We don’t train AI on your data. We don’t store your messages in our own databases. The AI that powers your brain runs through an API key (Anthropic’s, by default) that talks directly from your machine to the model provider — your data is not an input to anyone else’s training.

That said, we’re not going to oversell this. We’re a small company with access, like every hosting provider, to the computers we operate. Here’s the whole picture.

Where your data lives

Your brain runs inside a Fly Machine — a Firecracker microVM, which is the same isolation technology AWS Lambda uses. It boots when you use it and goes to sleep when you don’t. No other customer runs on the same microVM. You get your own kernel, your own memory, your own process space.

Your data — the notes your brain takes, the cache of messages it’s read — lives on a Fly Volume attached only to that microVM. Volumes are NVMe drives encrypted at rest. No other customer’s Volume is mounted inside your machine, and your Volume is not mounted in anyone else’s.

When your brain is off, the Volume keeps your data. When you delete your brain, the Volume is destroyed.

What we ask for

We ask for the narrowest scope that makes each channel work:

Gmail: gmail.readonly — we can read your mail; we can’t send, delete, or modify anything.
Google Calendar: calendar.readonly — we can see your events; we can’t create or change them.
Slack: depends on the ability. Most abilities only need channels:history for channels you’ve added the app to. We tell you on the connect screen what scopes you’re granting, and why.
Your files: whatever folders you choose to sync — nothing more.
Claude Desktop: read-only access to the MCP endpoint your brain exposes. Claude Desktop never sees your OAuth tokens.

What we do with your data

Your brain reads it. Messages, calendar events, and files are fed to your brain so it can learn what’s relevant to you and answer questions you ask it later.
Your brain stores summaries and notes on your Volume. Not the raw messages — distilled notes the brain wrote about what it read.
When your brain answers a question, it calls an AI model. By default this is Anthropic’s Claude via our API key. You can bring your own key and bypass ours; in either case the model provider’s policy on your data applies to what the model sees in the prompt. (Anthropic’s API does not train on your API traffic by default.)

What we don’t do

We don’t copy your messages into our own database. They live on your Volume, full stop.
We don’t train AI on your data. We don’t have a training pipeline at all.
We don’t sell, share, or syndicate your data to anyone.
We don’t read through your emails for fun, to improve our product, or to build aggregate insights.
We don’t have a “customer data” table with your inbox in it. There is no such thing.

Who can access your machine

Honesty about the limits:

You can access it, through the web UI and — if you want — by connecting Claude Desktop to the MCP endpoint the brain exposes.
We can access it, in the sense that anyone who operates hosted infrastructure can access the machines they operate. If you open a support ticket and we need to reproduce a bug, we will tell you before we connect to your machine. We don’t browse around otherwise.
Fly.io can access it, in the sense that any cloud provider can access the hardware customer workloads run on. Fly publishes their own security documentation — we rely on it and don’t try to out-promise it.
Your OAuth providers can see what you’ve granted, because those are their APIs. Disconnecting a channel revokes the token on our side; you can also revoke it from the provider (Google, Slack) at any time.

We are not end-to-end encrypted. We are not zero-knowledge. Anyone who tells you a hosted product is zero-knowledge while also summarizing your email is misleading you.

What we store on our side

Our control plane (a separate Postgres database, not your Volume) stores only what we need to manage your account:

Your email and name (from the OAuth provider you signed up with).
The channels you’ve connected and their OAuth tokens, encrypted at rest.
Your subscription state (a Stripe customer id, the brain tier you’re on).
A minimal audit log of administrative actions (who signed in, when a brain was provisioned, when a token was refreshed).

We do not store your messages, calendar events, or files in the control plane.

Deleting your brain

You can delete your brain from the dashboard. When you do:

The Fly Machine is destroyed.
The Fly Volume is destroyed — every note your brain took, every cached message, gone.
OAuth tokens in the control plane are revoked with the provider and removed from our database.
Your account record is marked deleted; we retain billing records as long as tax law requires us to (typically 7 years) and nothing more.

This is a one-way door. We don’t keep a hidden backup “just in case.”

Backups

Fly snapshots Volumes daily for disaster recovery. Snapshots are encrypted and tied to your Volume. When you delete your brain, the snapshots are purged on Fly’s schedule (we do not separately archive them).

Legal requests

If we receive a subpoena or court order for your data:

We will tell you, unless we are legally prohibited from doing so.
We will push back on requests that look overbroad.
We will only produce what we actually have. See the list above — we don’t have your email inbox; we have your account record and your connected-channel metadata.

Fly.io’s role

We run on Fly.io. Fly operates the hardware and the network. We operate the microVMs and Volumes on top of it. Fly has their own incident reporting and their own compliance posture (SOC 2); we rely on it rather than claiming our own certifications we don’t have.

Changes to this page

This page lives in our git repository. Any revision is a public commit. If we ever change how we handle your data, this page changes with it and the updated_at date moves.

If the changes are material — for example, if we ever started doing something new with your data — we would tell you by email before the change takes effect.

How we handle your data.