Security and compliance

This section is for the person who reviews Beetl before your company uses it, and for the admins who run it afterwards. This page covers what Beetl guarantees, sign-in, API keys and what the assistant can change.

What Beetl guarantees

Guarantee	What it means for you
Tenant data stays separate	Everything you build lives in one tenant, and nothing in Beetl crosses from one tenant to another.
Scope comes from who is calling	Beetl never takes a tenant from a request. Every call is scoped by your signed-in session or by the API key an MCP client presents.
Queries cannot change data	SQL run from Query, chat, automations or MCP cannot insert, update, delete or create anything, whatever the SQL says.
Beetl does not write to your source systems	No Beetl feature writes back to a system you connected, and datasets Beetl reads in place can never be a pipeline destination.
Integration code runs in an isolated sandbox	Each build, sync and connection check runs in its own sandbox, which can reach only public internet hosts over HTTPS.
Secrets are stored encrypted and never shown again	Connection credentials, storage keys, AI provider keys and the dashboards API key are encrypted. Once saved, Beetl shows their names, never their values. MCP API keys are shown once and stored only as a hash.

All traffic to Beetl uses HTTPS.

How tenants are kept apart

A tenant is one customer workspace. Your connections, datasets, pipelines, automations and query results belong to exactly one tenant, and each user belongs to exactly one tenant.

Because scope comes from the session or the key, a user cannot reach another tenant by changing an ID in a request. This holds on every surface: Query, chat, MCP, dashboards and the sandboxes that run integration code.

Within a tenant, most of what you build is shared by every user. Query results, chat sessions and API keys belong to the person who created them. Tenants and roles lists both.

You sign in through Beetl's identity provider. The login page has a single Sign In button, and Beetl stores no passwords. Signing out also ends your session with the identity provider.

Browser sessions use a secure, HTTP-only cookie and end after a period of inactivity. Every request that changes something must also carry a token tied to your session, so another website cannot act in Beetl on your behalf.

Beetl creates user accounts and assigns their roles, and there is no self-serve invite. To add a colleague, change a role or remove someone, contact Beetl. When Beetl deactivates a user or a tenant, their API keys stop working immediately.

There are 2 roles:

Role	What it can do
TenantAdmin	Everything a TenantUser can do, plus the tenant's configuration: object storage, external sources, AI settings and assistant instructions, dashboards setup, Connect packages, and deleting saved connection credentials.
TenantUser	Create and run connections and syncs, upload files, register datasets, build and deploy pipelines, create automations, query, chat and create API keys.

Every user can build and deploy, so give tenant access only to people who should be able to change your pipelines and automations. Tenants and roles has the full list.

API keys for MCP

MCP clients such as Claude or Cursor connect with an API key. Each key belongs to 1 user in 1 tenant, and every call it makes runs as that user. Any user can create keys under Settings → User.

A key has one of 2 scopes, checked on every call:

Scope	What the client can do
`read`	Query data, list datasets and pipelines, inspect runs, preview pipeline drafts, read automations.
`write`	Everything in `read`, plus create, change and deploy pipelines, manage automations, and create and render reports. App changes are not available over MCP.

Beetl shows a key once, when you create it. If you lose it, delete it and create a new one. Deleting a key revokes it at once, and the key list shows when each key was last used.

Good practice:

Use a read key unless the client needs to change things.
Treat a write key like a deploy credential. Over MCP it deploys a pipeline and deletes an automation without the confirmation that chat asks for.
Create 1 key per client and machine, label it so you recognize it, and keep keys out of shared config and repositories.
To replace a key, create the new one, update the client, then delete the old one.
Delete keys you no longer use.

Setup steps are in MCP setup.

The assistant and AI

The assistant in Chat and in the sidebar can read your data and change things inside Beetl: the page you have open, pipeline drafts and deployments, automations, reports and apps. It cannot change data in your source systems, and its queries cannot change data anywhere. A deploy, an app change or deleting an automation from chat pauses until you choose Allow or Deny. Report runs write PDFs to your storage without asking. Automations can only read.

Beetl treats everything the assistant reads through its tools, including your data, as data and never as instructions. The only tenant text it follows as guidance is the assistant instructions a TenantAdmin writes in Settings. No tool returns credentials or keys to the assistant.

The agent trust boundary lists each change the assistant and MCP clients can make, and how each one is gated.

While answering, the assistant and automations send what they read, query results included, to the tenant's AI provider. Where your data lives explains where those requests go.

Dashboards

Dashboards are an optional add-on. The Superset instance behind them reads only your tenant's data and cannot change it. Every user in the tenant sees every dashboard Beetl lists, so publish and embed a dashboard only when the whole tenant may see it. See Dashboards and BI.

Where data lives and how it is deleted

Beetl hosts your data in Germany by default, and other locations are available on request. See Where your data lives.

For how long each kind of data is kept, and what deleting a connection, dataset or credential removes, see Retention and deletion.

What you are responsible for

Review a Connect package before you install it. Its own code decides which endpoints it calls, including endpoints that write. See Sandbox.
Keep tenant membership to the people who need it, and tell Beetl when someone leaves.
If you register your own bucket, its access policy and encryption at rest are set in your cloud account.

In this section

Page	What it covers
Where your data lives	Hosting location, storage, and where AI requests go.
Retention and deletion	How long each kind of data is kept, and what deleting removes.

Security and compliance

On this page