Trust

Security & access model

SlashPeak is built around one rule: we should never need to see your table data to tell you what's driving your bill.

Illustration of metadata passing through a protective barrier while raw table data stays sealed behind it

What SlashPeak is granted

bigquery.jobs.create
Run INFORMATION_SCHEMA queries
bigquery.jobs.listAll
Read every user's job history
bigquery.datasets.get
Read dataset metadata
bigquery.tables.get
Read table metadata
bigquery.tables.list
List tables in a dataset
bigquery.reservations.list
List slot reservations
resourcemanager.projects.get
Read this project's metadata
bigquery.readsessions.create
Open a Storage Read session
bigquery.readsessions.getData
Stream rows from a Storage Read session

What SlashPeak never asks for

roles/bigquery.dataViewer

The role that would grant access to table contents.

Without it, no query the SlashPeak scanner issues can return a single row of your data — the access model enforces the promise rather than relying on policy. Optional features you turn on yourself, such as a billing export dataset or Cognis AI DBA fixes that need dry runs, are granted separately.

Access model

How metadata-only access works

Read-only IAM, nothing more

The service account needs bigquery.jobs.create, bigquery.jobs.listAll, bigquery.datasets.get, bigquery.tables.get, bigquery.tables.list, bigquery.reservations.list, resourcemanager.projects.get, bigquery.readsessions.create, bigquery.readsessions.getData. Storage Read sessions are used only for INFORMATION_SCHEMA jobs, jobs timeline, and table storage results. SlashPeak never asks for roles/bigquery.dataViewer on your projects. The one optional exception is a linked Cloud Billing export, where you grant it on that single dataset of cost rows.

INFORMATION_SCHEMA only

Every scan query reads from INFORMATION_SCHEMA views — job history, table DDL, storage sizes, dataset billing model, and reservation timelines. SlashPeak never issues a SELECT against your actual tables. The only other read is the optional Cloud Billing export dataset, if you link one.

Encrypted at rest

Service account keys, Cognis AI DBA operator keys and dbt Cloud service tokens are encrypted with AES-256-GCM before being written to Postgres, and are never returned to the browser after initial submission.

Server-side only

The BigQuery client and decrypted credentials are used exclusively inside server-side API route handlers — never shipped to the browser bundle.

PII masked inside BigQuery

The scan masks emails, phone numbers, IPs and your own regex patterns in query text inside BigQuery, before SlashPeak reads it. Those values are never sent to us or stored.

AI query rewrites only on click

The Cognis AI query optimizer runs only when someone clicks "Optimize with Cognis AI" on a query. That click sends the query text to Google Gemini with string literals and large numbers masked and comments removed, plus table schemas — never table contents. The answer shows in Cognis chat. It only recommends: nothing runs in your warehouse, and dry runs use the optional operator key only if you granted it.

Scoped by design

We scan the datasets the service account can see, in the regions you leave on. You can turn a region off at any time. Scanner-issued queries (and the optional Cognis AI DBA operator key's) are excluded from job history via user_email exclusion, so SlashPeak's own queries never appear in your findings.

Repo access without a clone

For Cognis AI DBA pull requests, the GitHub App sees only the repos you select. We read the files a fix needs through GitHub's API, with short-lived tokens scoped to one repo. A repo copy used to find a query's code stays in memory and is discarded after the step. We never clone or keep your repo, and the app can write only its own slashpeak/ai-dba/ branches.

Login controls

Every user sees the devices signed in to their login and can sign them out. On Enterprise, owners set a login policy: a device limit per person (down to one device only) and an idle timeout that signs people out.

Waitlist

Waitlist warehouse access models

Every scanner follows the same contract: catalog and query-history metadata only. Table contents stay in the warehouse.

Snowflake

IMPORTED PRIVILEGES on the SNOWFLAKE database for ACCOUNT_USAGE — QUERY_HISTORY, WAREHOUSE_METERING_HISTORY, TABLE_STORAGE_METRICS, clustering depth. Never SELECT on user databases.

Databricks

SELECT on system.query.history and system.compute.warehouses for bytes read, DBU-hours, and warehouse auto-stop. Never SELECT on user catalogs.

How this compares

Several competitors in this category use continuous agents with broad write access to autonomously resize warehouses or rewrite queries. SlashPeak scans with a read-only, metadata-only key. The optional Cognis AI DBA never uses that key: writes need a second operator key you create with only the permissions you pick, a policy you set (it starts paused and off), and an owner's approval for anything outside it. Every write is logged with its exact request, and almost all can be rolled back. dbt and code fixes arrive as pull requests from a GitHub App that can only push its own slashpeak/ai-dba/ branches — a person on your team always merges.

Security questions?

Reach out before connecting a production project — we're happy to walk through the exact IAM policy and data flow.

Talk to us

Take control of your warehouse bill

Understand, reduce and govern your cloud data spend with SlashPeak — starting today.

Start for free Get a demo

30-day free trial
No credit card
Read-only access
Set up in minutes