Security

What we read

Usage metadata only: Databricks system tables (billing, compute, jobs, query history, serving) and Snowflake's ACCOUNT_USAGE views. We never read the contents of your tables.

SQL statement text is not sent from Databricks unless you turn it on.

User identities — query authors, job owners, cluster creators, and email addresses in tags — are replaced by a salted hash inside your Databricks workspace before anything leaves it. The salt stays in your secret scope; we never receive it, so we cannot reverse the hashes.

How we connect to Databricks

Push (the default): a notebook you import and schedule sends the data to us. It contains no secrets — it reads its upload token from your own secret scope — so you can review exactly what it sends before running it.

Live (optional): we read with a service principal you create and grant read access to. For reading, we only run SELECT statements on the system tables and read your serving endpoint configuration. Every statement appears in your own query history, and the connection card gives you the query that lists them.

By default we never change anything in your workspace. Recommendations come with the commands to apply them, for you to run.

Live connections can opt in to applying a recommendation for you, per connection and off until you turn it on. That needs CAN MANAGE for the service principal on the cluster, SQL warehouse or serving endpoint it changes, and it can make only those three kinds of change. Each change is recorded with the exact command and the one that reverses it, and you can undo it from the Savings screen. Nothing is applied until someone presses Apply on a recommendation.

Credentials

Upload tokens are stored encrypted (AES-256-GCM) and compared in constant time. Generating a new token revokes the old one immediately.

A service principal's OAuth secret is entered once in the app, stored encrypted, and never shown, logged or returned again. The access tokens we get with it are short-lived and kept in memory only. Switching back to push deletes the stored secret.

Uploaded data is filed under the workspace its token belongs to — never one named in the request.

Uploads are limited to 300 requests a minute per workspace.

What we keep, and for how long

An upload is shown only once it has fully arrived and been checked. A partial or refused upload is never used.

We keep the 30 most recent uploads per workspace and delete older ones daily. Uploads that never completed are deleted after 24 hours.

Disconnecting a workspace deletes its connection, tokens and every upload. Deleting your account deletes all of your workspaces the same way.

Where it runs

The application runs on Vercel in Singapore and is served only over HTTPS. Data is stored in a Postgres database run by Neon, also in Singapore. Account emails are sent through Resend. These are the services that process data on our behalf.

Reporting a vulnerability

Email infra@tekspaz.com. Please don't include real credentials or customer data in your report.