Status
In private development. Early access by invitation.
This page says exactly what leaves your machine when you use Emolysis, and when. The security page has the same list in short form.
What leaves your machine
How Emolysis handles your data:
- Your platform credentials stay on your machine, in its credential store.
- Deployed pipelines and queries against your platform run there, under your account; local tests run on your machine.
- To write code, the agent sends prompts to the AI model provider you choose. A prompt can include table and column names, schemas and sample values from your data.
- A dashboard leaves your machine when you publish it, and only then.
- Samples you pull from your platform are stored on your machine, in the project's local lakehouse. Parts of them can appear in prompts, as item 3 says.
- With your own model key, prompts go to that provider under your key and its terms. With a paid plan's included usage or usage credits (on Enterprise, metered usage), prompts and responses pass through Emolysis's metering service on the way to the model provider. That service is designed not to store or log their content; it records token counts for billing.
- When you sign in, Emolysis receives your account identity from the provider you choose: GitHub, Microsoft or Google. Emolysis's services keep your account, organization, plan and usage records. They are designed never to connect to your data platform and never to receive your platform credentials. Data from your tables reaches them only in prompts that pass through the metering service, which is designed not to store or log them, and in dashboards you publish.
- If you install the GitHub App (planned), it reads the contents of the repositories you choose, to run its checks, and writes check results and comments on their pull requests.
The same list, by moment
| When you... | What is sent, and to whom |
|---|---|
| Ask the agent for anything | A prompt to the model provider you choose, which can include schemas and sample values; with a paid plan's model usage, it passes through Emolysis's metering service |
| Sign in | Your account identity, from GitHub, Microsoft or Google, to Emolysis |
| Connect a platform | Your platform's own sign-in; credentials stay in your credential store, not with Emolysis |
| Read the catalog | A metadata query on your platform; the result is stored on your machine, and names and schemas from it can appear in prompts (item 3) |
| Pull a sample | A query on your platform; the rows are stored on your machine |
| Run lint, a dry run or golden tests | Nothing; these run on your machine on DuckDB |
| Deploy | The pipeline to your platform, with your credentials, under your account |
| Publish a dashboard | The charts and the data behind them to Emolysis, for the audience you choose |
| Use the GitHub App (planned) on a repository | The app reads the repository contents you chose and writes check results and comments |
What local-first does not mean
Local-first does not mean nothing leaves your machine. The prompts in item 3 are the largest channel, and they go to a third party you choose, under that party's terms. If a table name, a column name or a sample value is too sensitive to appear in a prompt, do not point the agent at that table. See Model keys and credits.
Practical advice
- Connect a development workspace or a role with narrow permissions while you evaluate.
- Sample from tables that hold no sensitive values, or pull only the columns you need.
- Keep golden test fixtures synthetic; they are committed and run in CI.
- Publish dashboards with organization or only-me visibility unless a public link is intended, set an expiry date on snapshot links you share outside your company, and revoke a stable link once it is no longer needed.
- Read your model provider's data terms; they govern what happens to prompts there.
- If you use an editor or coding agent that supports MCP, remember that it sends tool results to its own provider. See The MCP server.
Session log
The app keeps a log of what the agent does on your machine: requests, files changed, tests run and deploys. Exporting it is planned; you decide whether to export it.
Related
Sharing dashboards, GitHub checks and Connecting Databricks describe the individual flows. The security page summarizes this one.