Point it at Snowflake.
Walk away with insights.
DecisionBox connects to your Snowflake account in a few minutes — no schema migration, no pipeline to build. The agent reads your tables in place, runs read-only queries on the warehouse you choose, and surfaces validated insights from what is already in your account.
Three things to know on day one.
Read-only, scoped by Snowflake role
The agent connects with a Snowflake role you choose — typically a read-only role with USAGE on the warehouse and SELECT on the schemas you want it to see. Snowflake's RBAC is the access boundary; the agent cannot reach anything the role does not grant.
Runs on the warehouse you choose
Pick the warehouse name in the project config (for example COMPUTE_WH). The agent runs all of its queries on that warehouse — the size, auto-suspend, and resource monitor you have already set are the cost control. No new compute, no second cluster to manage.
Reads your schemas in place
No tables to refactor, no data pipeline to stand up, no warehouse-side changes. Point DecisionBox at a database and a schema, and the agent picks up your tables on its first run — and re-checks them on every run after. Metadata is read from INFORMATION_SCHEMA, not from full table scans.
You pick the warehouse. You keep the cost controls you already trust.
Snowflake bills by warehouse-second on the credit rate of whichever warehouse runs the query. Because the DecisionBox agent runs on the warehouse you point it at, every cost guardrail you have already set up — the size, the auto-suspend, the resource monitor, the spending limit — applies to the agent the same way it applies to your BI tools and dbt jobs.
Want a separate cost line for DecisionBox runs? Create a dedicated warehouse for the agent, attach a resource monitor, and put the warehouse name in the project config. The agent never sees other compute.
Two ways in. Both are Snowflake-native.
Pick the one that matches how the rest of your Snowflake automation already works. Both options end at the same role and warehouse you configured — what changes is how the agent proves it is who it claims to be.
Username / Password
Paste the password for a service user in the project config. Stored encrypted, never written to logs. Good for a first run, a proof of concept, or a developer-only project.
Key Pair (JWT)
Paste a PEM-encoded RSA private key (PKCS8 or PKCS1). DecisionBox signs a short-lived JWT for each session — no long-lived password sits on the agent. This is the same key pair flow Snowflake recommends for any machine-to-machine integration.
Both options end at the same role and warehouse you configured — USAGE on the warehouse, SELECT on the schemas you opted in, and nothing more. If your security team has already approved how the rest of your stack talks to Snowflake, they have already approved DecisionBox.
Open source, and not Snowflake-only.
Open source, AGPL v3
Every line of the Snowflake integration — the role-scoped auth flow, the JWT signing for key pair, the SQL the agent writes — is in the public repo. Anyone can read and audit it before turning it on.
View the Snowflake provider on GitHubNot locked to Snowflake
The same agent runs against any of them. If your warehouse moves, your DecisionBox install moves with it.
Try it on your Snowflake, in two minutes.
Clone the repo, run docker compose up, and point it at a Snowflake account, warehouse, and role. Read-only credentials are all the agent ever needs.