Your data stays in one place. Here is exactly who and what can touch it.

Each customer gets a dedicated deployment: a virtual machine (Firecracker on Fly.io, Virginia), its own database for bookkeeping, and its own prefix in object storage. No process, database or file is shared with another customer.

Machines and storage are in Virginia. Models run in US regions.

TLS everywhere. Storage, database volumes and backups are encrypted at rest by the providers. Nightly backups go to a second provider.

A connector's API key, a service account's key file, a database password, a webhook's signing secret, a Google sign-in's token: each is encrypted before it is kept, with a data key made for your company by a key management service (KMS) in our cloud account and stored only in its wrapped form beside the value. Opening one is a logged call to that service, and each machine makes it as a login of its own that the service lets open that company's keys and no other company's: a machine that is taken opens one company, never every one. The whole thing can be revoked for every machine at once. Your company's own database and its nightly backups hold only the sealed form; a database password or a backup file alone reads none of them. The form says so where you enter a key, and no key is ever shown again.

Every version of every table is kept. A dropped table is hidden for a week before anything is removed, so a mistake, yours or an agent's, is a restore, not a loss.

An admin asks in Settings. Nothing is removed for seven days: every admin is emailed, everyone in it sees the day across the top of every screen, and any admin can keep the company until then. On the seventh day its machine, its database, its files and its organization in sign-in are deleted, after one last backup, which is kept. Our own tools refuse to delete a company any other way.

Each at Add rows only, Read, or Read and write. A key can be given masked access, which replaces names, emails, phones and addresses with stable stand-ins before the query runs. Revoke a key in one click.

Every statement, from a person or an agent, goes through a guard before it runs: it may read only the datasets the key can read, write only where the key is read-write, and never attach, install, export or change settings. There is no superuser path for the agent.

One switch under Settings. Off means the chat, the source builder and automatic fixes stop; syncs, queries, the inbox and exports keep working. Scoping the agent per person is by key today, not by a switch.

A live link is a secret URL that returns a query's current result as a file, so a spreadsheet can pull it. Anyone with the URL can fetch it. It reads with the access of the person who made it, every fetch is counted, and an admin or its maker can revoke it at once. The app says this where the link is made.

Who, when, the SQL or the tool, rows, time, and for a model call the model and its cost. Admin actions too: keys, people and groups, sharing, plan changes, sources, tables deleted, a deletion asked or cancelled, and every company setting changed. Those are kept 90 days; queries and agent steps are kept for now, with no end set yet. An admin exports any of it at any time: Export on Settings, Activity, or ovs actions for CSV or Excel. Failed runs and quiet sources become cards you review; a fix runs only when you say so.

There is no admin screen that opens a customer's data. Operations run through provisioning commands and logs. A two-person rule for any hands-on access is on the list below, not yet built.

No model maker may train on what passes through; that is our contract with each one, and the model sees only what a tool returned (above).

A company can ask that every model call for it go through one provider only. We set it at our desk, and the record of each call names the model that answered, so you can see it held.

A script runs in an empty network of its own, with one door: a proxy that allows only the hosts listed on that source. Anything else gets a refusal, and the run log shows every host it talked to. Private and internal addresses are refused everywhere, at save time and at every connection.

A model reaches nothing outside unless an admin lists the hosts it may reach, and then only those, through the same proxy, with every run's log saying what went where. Keys for those services are pasted once and never shown again. An agent's key can change a model's script, never its list.

The script runs as an unprivileged user of its own for that run (two runs at the same moment are two users, so neither reads the other's environment or folder), with only its own secrets in its environment, none of ours. It is stopped at your plan's time limit. What it landed before that stays landed.

A script cannot write a table directly. It hands rows to us and they are appended, raw, to a table only your key controls. It can never touch our bookkeeping.

We will do these when a customer needs them. Ask and we will tell you where we are.

Today sign-in is through Clerk with email or a social account.

The model layer can take a customer's own provider key, but there is no screen for it yet. Ask.

Written into our own rules; the tooling that enforces it is not built.

The keys you give us are sealed under a KMS key of ours (above); your data files and database are encrypted at rest with the providers' keys. A key of your own, in your account, is not offered yet.

A deleted company's last backup, and the record of queries and agent steps, are kept with no end date yet. When each goes is not decided; this page will say it when it is.