Permission is a fact, not a prompt.
Roles, tenancy and data policy resolve from the session that signed in. The agent inherits them. Nothing typed into chat can change them.
Connect a database
Pick the kind of database you have. You will need its address and a read only login.
PostgreSQL
PostgreSQL database
MySQL
MySQL database
ClickHouse
ClickHouse analytics
SQL Server
SQL Server database
Trino
Trino query engine
DuckDB
Local .duckdb file
Snowflake
Coming soon
BigQuery
Coming soon
Databricks
Coming soon
Connect PostgreSQL
Nothing is saved until the connection works. iDash opens it read only and reads the list of tables.
- Name
- Production Postgres
- Host
- db.meridian.internal
- Port
- 5432
- Database
- commerce
- User
- idash_readonly
- Password
- ••••••••••••
Connection tested, read only
42 tables and 17 foreign keys read in 1.8s
The connection can only read.
Every guarantee here starts with the credential. iDash asks for one that can read, then makes sure it cannot do anything else.
Enforced read-only access
Connections to your data sources are strictly read only at the connection level, guaranteeing your data can never be modified or overwritten.
Automatic request safeguards
Every data request is validated before execution and restricted to read-only queries. Modification commands are blocked automatically.
Nothing runs unbounded
Queries execute under a statement timeout. A question that would sit on your replica for an hour is cancelled, and you are told that it was.
Credentials encrypted per field
Host, database, user and password are encrypted field by field with AES-256-GCM at rest, and decrypted only to open a connection.
Why you can trust it
Who you are decides what resolves.
Membership, role and data policy are read from the authenticated session. The agent runs inside that answer and has no way to argue with it.
A ranked role model
Owner outranks admin, admin outranks member, member outranks viewer. Every workspace route resolves the caller's role first, and a workspace can never lose its last owner.
Complete workspace privacy
Workspaces and projects are completely invisible to non-members, ensuring team data and organization structures remain confidential.
Granular data permissions
Restrict specific records or sensitive figures to authorized teams, such as limiting managers to their own region or keeping compensation confidential.
Strict permission enforcement
Access rules are determined by user authentication, not chat input. No conversational phrasing can bypass assigned user permissions.
Question
What was revenue by campaign last quarter?
Ambiguous join path
Both paths are valid and they return different numbers. Rather than pick one and hand you a number that looks fine, the compiler stops.
- ordersattributionscampaigns
last touch
- orderssessionscampaigns
session source
Compiler
ambiguous join path from 'orders' to 'campaigns': 2 equally short paths exist. Query one of them directly as the base model instead.
How to get an answer
- Ask for one of them by name, for example revenue by last touch campaign.
- Mark one relationship as the default in the semantic model.
What the agent never touches.
Some things are kept away from the model and from the code it writes, by construction rather than by instruction.
Isolated calculation environment
Complex calculations run in secure, isolated environments with access only to temporary results, keeping your database credentials fully protected.
Its own database
iDash refuses to connect to the database that runs iDash. The agent is scoped to questions about your data and declines the rest.
Secrets stay server side
Connection details are decrypted inside the API to open a session and go nowhere else. Not into a prompt, a tool result, a chart spec or an export.
Hand it your narrowest credential.
A read-only user on a replica is enough to start, and enough to keep.